tap

role
Product design, AI interaction design, Full-stack engineering
team
Solo
my part
I designed and built the full-stack prototype, including the customer simulator, streamed interfaces, and bounded action system.

overview

Tap asks when an AI should interrupt and what it can do after someone pays attention. Each tap is a small model-written update tied to a simulated customer situation.

I designed and built the full-stack prototype, from the customer simulator and scenario controls to the streamed interfaces and action handlers. I could change the customer’s situation, fire a trigger, and inspect the resulting interaction.

Generated taps on the home screen.
Hey Silas home with five taps: audience clustering in two cities, climbing quarterly royalties, collaborator royalty-split questions, streaming revenue up 40%, and a $6,400 promo window for a release.
Same home, different world. Silas is a musician, so the taps shift to audiences, royalties, collaborators, and release timing.

a reason to interrupt

Cash stress made restraint important: a business owner might need a warning, but an incoming payment could make a loan unnecessary. I wanted to test whether the system could offer help without treating financial pressure as a sales opportunity.

I kept the first tap small: generated copy and a read-only preview, with urgency and interaction controlled by the app. Opening it gives the follow-up room to explain and offer an action.

Dismissing a tap. The rest of the stack stays put.
Tap visual design specs: canvas and ink colors, anomaly through reminder accents, typography, spacing scale, and motion timings for reveal and expand.
The visual rules I set for taps: how they signal urgency, appear, and expand.
Opened Midweek covers tap beside a follow-up proposing a loyalty program, with wait for March and loyalty nudge options.
Opened tap. The card stays on the left; the follow-up gets the rest of the screen.

Scenario flow

01 Situation

  1. Host

    Simulated customer state

    A business has more demand than its team can cover, and a new hire ready to start.

  2. Host

    Context + available actions

    The server supplies customer facts and the scenario, then computes which actions are available.

02 Attention

  1. Model

    A small heads-up

    Generated copy and a read-only preview appear inside the app’s tap card.

  2. Model

    Opened follow-up

    Opening it starts a second generation with the source tap and conversation context. The host checks protocol and action bindings as it streams.

03 Action

  1. Host

    Check + dispatch

    After confirmation, the host checks the requested action and calls its adapter. Here: create a team-member record.

  2. Model

    Result → confirmation

    A successful mock or sandbox result feeds an action-free confirmation. The sandbox action creates a team record, not a payroll enrollment.

next

Tap is still a proof of concept. Customer situations are simulated. Most actions return mock results; selected adapters connect to sandbox APIs. The prototype records acceptance and decline, not whether the interruption helped. That still needs testing in someone’s day.