Skip to content

Design SOP

Role: Designer
Prerequisites: Complete the Meta SOP first
Visual reference: Whimsical Flowchart

You are a code-first designer. You work directly in the codebase, not in Figma. You own Storybook, you own the visual quality of the app, and you fix what you see broken every day. No tickets required to make the app better. No Figma before you've tried Claude. When PM creates a FE PR, you pull the branch locally and refine the UI/UX in code — making the feedback loop drastically faster than any design-to-handoff workflow.

The Figma Rule

Say it out loud before you open Figma:

"Have I genuinely tried to build this with Claude and hit a wall?"

If no — close Figma, open Cursor.
If yes, and it's a net-new component that doesn't exist in Storybook — open Figma, build the spec, add it to Storybook.

The only other exception: you can't achieve the result in Cursor and it's faster to mock it up in Figma and screenshot it in as a reference. That's fine — but the goal is still to build the real thing in code, not to create a Figma deliverable.

Figma is for new Storybook components only. Not for feature flows. Not for redesigns. Not for handoff documents. The component gets built once, lives in Storybook, and is used from there forever.

Track 1 — Daily App Improvement

Every day, use the live app as a real user. Fix what you find broken, awkward, or visually inconsistent. No ticket. No approval. Just fix it and send a PR to Tom.

The Workflow

  1. Open the app and use it properly — navigate as a customer would. Look for:

    • Spacing and alignment inconsistencies
    • Copy that's confusing, wrong, or off-brand
    • Components used in the wrong context
    • Missing or broken loading, empty, or error states
    • Flows that are harder to navigate than they should be
    • Responsiveness issues at standard breakpoints

  2. Branch off develop — one branch per fix:

git checkout develop
git pull
git checkout -b design/fix-[brief-description]
  1. Open Cursor with web-commercial in the workspace and fix the issue:
Plan a fix for the following visual/usability issue in web-commercial: 
[describe]

Use only existing Storybook components. Follow the existing 
design system patterns in this codebase.
Show me the plan before writing any code.

Review the plan, then tell Cursor to implement it.

  1. Test locally — does it look right at standard viewport sizes? Is anything nearby broken?

  2. Wait for regression tests to pass (Rainforest QA green)

  3. Manually verify the fix — walk through the affected flow end-to-end and confirm the original issue is resolved without breaking anything nearby

  4. Open a PR:

    • Title: [Design] Fix [brief description]
    • Description: one or two sentences — what was wrong and what you changed

  5. Merge once tests pass and you've verified it works

  6. Create a Linear ticket after the fact to record what you fixed:

Using the Linear MCP, create a ticket for the design fix I just merged.

Title: [Design] [brief description]
Description: [what was wrong and what was changed]
Status: Done
Link the PR: [PR URL]

In most cases you fix first, ticket after — the work is already done, the ticket is just the record.

What's Fair Game Without a Ticket

  • Visual inconsistencies (spacing, alignment, colour, typography)
  • Confusing, inconsistent, or incorrect copy
  • Components used in the wrong context
  • Missing or broken loading, empty, or error states
  • Unnecessarily confusing navigation
  • Responsiveness issues at standard breakpoints (mobile, tablet, desktop)

What Needs a Conversation with Tom First

  • Changes to how a core user flow fundamentally works
  • Removing or significantly restructuring existing functionality
  • Anything that affects data or API behaviour
  • Net-new pages or features (go through the PM PR process instead)

Track 2 — FE Refinement on Feature PRs

When PM asks, you are responsible for making their FE PRs more beautiful, polished, and consistent with the design system. PM builds the initial scaffolding — your job is to elevate the UI and UX before the engineer locks in the back-end around it.

The Workflow

  1. Pull the branch:
git checkout [branch name]
git pull

  1. Open Cursor with all five repos in the workspace

  2. Walk through the user journey first — before changing anything, understand what PM was trying to achieve. If it's unclear, Slack PM before making structural changes.

  3. Plan improvements in Claude first — let Claude suggest UX improvements and research competitor patterns:

I'm refining the UX and UI for [feature name]. Here's what 
the current flow looks like: [describe the current state].

First, research how competitors handle this type of feature — 
what UX patterns work well in similar B2B SaaS products?

Then suggest improvements to the layout, flow, and visual 
consistency. Focus on user experience, not technical implementation.

Review Claude's suggestions. Use them to inform what you change in Cursor.

  1. Refine with Cursor:
Plan improvements to the UX and UI for [feature name] in 
web-commercial on this branch. Specifically:

- [e.g. The empty state is missing — add one using the existing empty state component]
- [e.g. The spacing between the table rows and the header is inconsistent with the rest of the app]
- [e.g. The flow jumps from step 1 directly to step 3 — add a confirmation step]

Use only existing Storybook components. Follow design system patterns.
Show me the plan before writing any code.

Review the plan, then tell Cursor to implement it.

  1. Test locally — walk the full user journey including edge cases (empty states, error states, mobile viewport)

  2. Push the branch and hand to the Engineer:

git push origin [branch name]

Slack the engineer: brief summary of what you changed and why, and anything you flagged but didn't fix (so they know what to watch for on the BE side).

What You Do and Don't Own Here

You own: the UX flow, component choices, visual consistency, copy, loading/empty/error states, responsiveness.

You do not own: whether the feature is the right thing to build (that's PM), or how the back-end is wired (that's Engineering). If you have concerns about either, raise them — but don't block the PR over them.

Storybook Ownership

You are responsible for Storybook staying accurate and useful. When a net-new component is genuinely needed:

  1. Try to build it with Claude in Cursor first — iterate until it's right or you've hit a genuine wall
  2. If Claude can't achieve it: open Figma, design the component spec
  3. Build the component and add it to Storybook
  4. The component lives in Storybook from now on — everyone uses it from there

Never build one-off styled components in web-commercial directly. If you see one that someone else built: move it to Storybook and replace the one-off with the Storybook component.

Troubleshooting

Problem Fix
Not sure if a change needs a ticket Visual or usability fix: branch and fix it. Changes how a feature fundamentally works: Slack Tom first.
Claude can't achieve the component Document what you tried, open Figma, design the spec, add it to Storybook.
Branch has conflicts Ask Cursor: "Fix these merge conflicts." Never edit manually.
Not sure which Storybook component to use Ask Cursor: "What is the correct Storybook component to use for [describe use case] in this codebase?"