Secret Handshakes for Designers Playbook

Purpose

Design demos need two conflicting qualities: they should look production-real, and they should still let the designer steer scenarios on demand. “Secret handshakes” are hidden, intentional controls that unlock scenario switching without polluting the visible product UI. This playbook standardizes those controls so demos stay elegant, reproducible, and honest.

When to use it

• You demo multiple audience scenarios from one prototype build
• You need rapid context switching during critiques or usability sessions
• Visible debug controls undermine trust in the product story
• Your team repeatedly asks, “How did you get to that state?”

Skip it when: the prototype is public-facing and cannot include hidden controls, or when a static click-through file is enough.

Core framework

Use a collaboration model with three handshakes:

1. Scenario handshake What it does: switch role/capability context (for example: owner, contributor, viewer) How to trigger: keyboard shortcut and optional URL seed

2. Timeline handshake What it does: jump across predefined maturity checkpoints (for example Day 0, 1, 3, 7, 8, 14) How to trigger: compact control in internal demo chrome

3. Reset handshake What it does: clear all ephemeral demo memory and return to first-run behavior How to trigger: explicit reset action only

Operating principles:

• Hidden by default, discoverable by the demo operator
• Persisted only at session scope unless there is a strong reason otherwise
• Reversible in one interaction
• Never changes the core information architecture

Reusable template

# Secret handshakes spec: <prototype name>

## Handshake inventory

| Handshake | Trigger | Stored key | Scope | Reset behavior |
|---|---|---|---|---|
| Scenario | <shortcut + optional query param> | <scenario-key> | session | reset clears |
| Timeline | <control + optional query param> | <timeline-key> | session | reset clears |
| Reset | <explicit action> | n/a | n/a | clears all demo keys |

## Allowed values

- Scenario: <owner | contributor | viewer>
- Timeline: <0 | 1 | 3 | 7 | 8 | 14>

## Guardrails

- Handshake controls are hidden in captures by default
- Any URL seed is consumed once, then removed from the URL
- Reset always restores first-run guidance

AI-assisted workflow

Use AI to draft your handshake contract before implementation.

I need a hidden-control spec for a design prototype with three controls:
1) scenario switch
2) timeline/day switch
3) full reset

Generate:
- trigger strategy (keyboard + optional URL seed)
- persistence strategy (session vs local)
- guardrails to avoid leaking debug controls into screenshots
- failure cases and mitigation

Constraints:
- Keep it tool-agnostic and implementation-neutral.
- Do not include confidential product names or internal terminology.

Use AI again as a QA checklist generator:

Given this handshake spec, create a test checklist for:
- first load behavior
- switching scenario repeatedly
- switching timeline repeatedly
- reset correctness
- keyboard discoverability by the operator
- non-discoverability by normal end users

Collaboration considerations

• For PMs: align on which scenarios must be demoable and which are intentionally excluded
• For developers: centralize handshake state and avoid ad hoc toggles across pages
• For research: decide whether to expose or hide handshakes during moderated sessions
• For accessibility: keyboard triggers must not conflict with assistive-tech critical shortcuts

Common failure patterns

1. Hidden controls that accidentally appear in screenshots or recordings
2. Mixing demo state with production feature flags
3. Non-reversible toggles that require reload gymnastics
4. Timeline toggles that mutate IA instead of only state
5. Reset that clears some keys but leaves stale guidance state behind

Companion artifacts

• Demo Days 0 to 14 Time-Machine Playbook for the timeline model these controls typically operate
• Demo days 0 to 14 reference for a live prototype showing this pattern in use
• Audit Command Center Template for capturing prototype-review findings from handshake testing

Generalized example

A fictional analytics prototype uses:

• Cmd/Ctrl+Shift+P to open a small operator-only scenario panel
• A compact day selector for Day 0/1/3/7/8/14 progression checks
• A “Reset prototype” action that clears all session-scoped demo keys

During review, the designer can answer “What would a new user see?” and “What does this look like two weeks in?” in seconds, without changing visible production-like UI chrome.

---

Public-safe review (verified before publish)

• No employer or client product names, codenames, or org names
• No customer names, segment sizes, or identifiable details
• No internal metrics, thresholds, OKRs, or telemetry numbers
• No roadmap, ship dates, or future plans
• No architecture, service names, API shapes, or schema fields from real systems
• No screenshots showing real chrome, real data, or recognizable surfaces
• No internal-only workflows, tools, or terminology
• Every example is fictional or abstracted; numbers are illustrative
• A peer outside any employer could read this and learn nothing proprietary