Velo Blog

Category: Design

  • The three-frame Figma rule

    The three-frame Figma rule

    Every Monday at our design review, someone opens Figma and scrolls. And scrolls. Twenty frames, six alternate flows, a stray Miro embed, three sticky notes with question marks. By frame nine, nobody remembers what the proposal is for.

    We made a rule. Three frames. That is the budget.

    Why three frames

    Three frames force a story: state, action, result. You cannot fake that shape. If you cannot show the current state, the moment of change, and the outcome inside three frames, the idea is not ready. It might be interesting, but it is not buildable yet.

    We use the rule for anything that lands in our Linear “Ready for eng” column. Before a ticket moves out of Design, the linked Figma file needs:

    • Frame 1: the state the user is in when this matters
    • Frame 2: the action or decision point
    • Frame 3: what changes, what breaks, what they see next

    Three frames is not a rule about fidelity. Lo-fi wireframes count. Screenshots with red boxes count. Three annotated hand drawings count. The constraint is narrative, not craft.

    What the rule caught

    The first month we tried this, our design lead pulled six proposals back to discovery. One of them was a payments refactor that had ninety-two frames and no clear before or after. When she asked the designer to pick three, he could not. The empty state was fine. The success state was fine. The middle was a fog of edge cases and dependency guesses. That fog was the real work, and it was invisible under all the surface polish.

    Now, when a designer says they cannot get under three frames, we treat it as a signal, not a failure. It tends to mean one of these:

    1. The problem is two problems glued together, and we should split the ticket
    2. The team has not agreed on which user is being served
    3. We are drawing solutions before we have named the decision

    When we break it

    We break the rule for onboarding flows, migration paths, and anything with a compliance step that legal needs to review verbatim. Those are storyboards, not proposals. The distinction matters. A storyboard documents a sequence. A proposal argues for a change. Three frames is for the arguing.

    We keep the frame counter in the corner of every design review agenda. Nobody enforces it. It sits there, and the room reads it.

  • How we run design reviews without a design lead

    How we run design reviews without a design lead

    We do not have a design lead at Velo. We have four product designers, six engineers, two PMs, and a shared Figma library that grows about eight components per week. For a long time our design reviews were a bottleneck. One person owned the calendar, the queue, and the taste. When they were on PTO, everything stalled for a week.

    Six months ago we scrapped that model. We now run a weekly design review every Thursday at 2pm, rotating facilitator, and we ship through roughly ten designs per hour. Here is how it works.

    The three questions on every draft

    Every design that enters the queue answers three questions before anyone speaks. We put them at the top of the Notion review doc, and the designer fills them in when they submit.

    1. What is the smallest unit of behavior this changes? A button state, a full flow, or a shared component?
    2. What did we consider and reject? We ask for two rejected options with one sentence each.
    3. What are we not sure about? The designer flags the specific decision they want feedback on.

    The last question does the heavy lifting. Before we added it, reviews drifted into whatever the loudest person felt like discussing. Icon choice on a screen whose real question was permissions logic. Copy on a modal whose real question was the empty state upstream. Now the designer sets the target. If someone wants to raise something outside that target, they add a comment in the Figma file and we move on.

    We also cap each entry at 250 words of context and three frames of the design itself. If it needs more, it is two designs, and it splits into two queue entries.

    Who shows up

    The room is small on purpose. Five people, always:

    • The designer whose work is under review
    • A rotating facilitator, drawn from the design pod
    • One engineer from the squad that will build the work
    • One PM, usually the one who wrote the ticket in Linear
    • One outsider from a different squad

    The outsider is the piece we fought about the longest. Early on we ran reviews with only the squad that owned the work, and every review turned into a status meeting. People agreed with each other because they had agreed with each other three days ago. Adding one person who had no context forced the designer to explain the thing they had stopped seeing.

    We rotate the outsider through a Slack workflow. Every Monday morning a bot posts in #design-review with the week’s roster, drawn from a list of eleven people across four squads. If you get tagged and cannot make it, you swap with someone else in the thread. No one has skipped in eight weeks.

    The facilitator’s job is not to have opinions. It is to keep the clock, read the three questions aloud, and cut off tangents. We rotate facilitators every week so that the role does not calcify into a proxy design lead.

    How we hit ten designs per hour

    Six minutes per design, hard cap. The facilitator sets a timer in Slack, visible to everyone. When the timer hits zero, we stop, capture the decision or the follow-up in the Notion doc, and move on.

    Six minutes sounds absurd until you try it. What we found:

    • Most designs need one or two decisions, not twelve. The three questions narrow the surface.
    • The engineer catches feasibility issues in the first ninety seconds. If a design assumes a field we do not have in our GraphQL schema, that comes out fast.
    • The PM catches scope creep. If a design has quietly grown a new setting screen, the PM flags it and we decide whether the ticket needs a split in Linear.
    • The outsider catches the assumptions everyone in the squad shares. This is the highest value input we get, and it usually shows up in the last minute.

    If a design cannot be resolved in six minutes, it goes into a longer 30 minute slot on Friday. About one in six designs ends up there. We track this in a Notion database, and if the ratio climbs above 25 percent for a month, we know something is off in how designs enter the review, and we tune the three questions.

    What we gave up

    We gave up consistency of taste. Without a single lead, our components sometimes drift. We catch this with a monthly audit that anyone on the design pod can run against the Figma library, and we open a GitHub PR to reconcile the drift. It takes about three hours.

    We also gave up the comfort of a single person who says yes or no. Decisions in our reviews are made by the designer, informed by the room. The facilitator will push back if a decision is being avoided, but no one else has veto power. This felt scary for the first month. It stopped feeling scary once we noticed the queue kept moving.