← Rituals

UX for Devs 101

25–30 minutes, every other week. Class notes live here. The ticket lives on GitHub.

For engineers shipping with AI, often without a designer in the room. One principle per session. Practice on a real n2 story. If you missed, read the 5-minute version — do not ask for a 1:1 replay.

TEACH ONCE

What belongs where

Do not teach FigJam or GitHub UI. Teach which thoughts go on which surface.

Where to write user jobs, whiteboards, and reusable lessons
Tool It is for It is not for
GitHub issue Problem, role, job to be done, success, constraints, must / should / not, questions Whiteboarding. Screenshots as the spec.
FigJam Intake, options, critique — always a duplicate of the template The backlog. Decisions with no owner.
Playbook This lesson and the pattern to reuse Ticket status.
PRACTICE

Story kickoff board

This session’s job

When I am about to write a ticket or prompt an agent, I need a short structure that names the user, the job, and success, so I can keep the work on the outcome — not jump to a control.

The four cards are that structure. A ticket named after a control ships the control. A ticket named after a job ships the outcome. If brackets remain, do not build — including with AI.

Type over the blanks. The mad-lib below updates as you go — copy it into GitHub before anyone opens an editor. FigJam is the same frames if the room wants a shared board.

Open FigJam: N2 UX 101 — Story kickoff → Duplicate before writing.

Lesson 1 · 28 Aug · fill these

Problem

Who cannot complete the job, because, that means. Task failure — not a feature request.

Today, cannot because . That means .

User

Toggle every role this story is for. Then who they are in their words — not the seat alone.

Roles

In their words:

*Working label, not a product seat yet.

Job to be done

When I, I need, so I can.

When I , I need , so I can .

Success

User-visible. Not “API 200.” Empty failure borrows the obstacle from Problem.

When this is shipped, they can without .

COPY / PASTE

Story mad-lib

Live preview of the Lesson 1 cards. Unfilled blanks stay in brackets so you can see what is missing. Do not build if brackets remain. Product seats: Admin, Curator, Contributor, Stakeholder. Collaborator is a working label, not a product seat yet.

GitHub title

[Role] outcome they can see

## Problem
Today, [who] cannot [job] because [obstacle].
That means [consequence].

## User
- **Role:** Admin | Curator | Contributor | Stakeholder | Collaborator
- **In their words:** [in their words]

## Job to be done
When I [situation], I need [capability], so I can [outcome].

## Success
When this is shipped, they can [user-visible result] without [the failure in Problem].

Paste the title, then the four headings, into the GitHub issue. Tag Jess with ux-needs-jess when a field is a guess you do not trust.

Lesson 2 · 11 Sep · same board, later

Must

User-visible. Three max.

Should

Will not hold the ship.

Not this time

Scope — not a constraint.

Open questions

One sticky = one question. Owner + date.

Constraints

Wrong even if it looks nice: seat, pattern, LANL, time.

Lesson 3 · 25 Sep · only if a preview exists

Walk the job

The JTBD from row 1. Pass / hesitate / fail at a named step.

Fix now / Ship / Split

One stamp. Do not start a new flow map.

PHASE 4 PILOT

Three lessons

Lesson 1 · late Aug · 30 min

The user is the ticket

Outcome, not control. Problem, role, job, success.

Draft

Lesson 2 · early Sep · 30 min

Requirements live on the issue

Must / should / not. Owned questions. FigJam intake.

Draft

Lesson 3 · mid Sep · 30 min

Do not invent, then walk the job

Playbook reuse. AI-dev notes. First 10-minute critique.

Draft
DRAFT

1 · The user is the ticket

If Problem, Role, Job to be done, and Success are blank (or still have brackets), do not build — including with AI.

5-minute version

People hire a product for an outcome, not a control. A ticket named “add delete” ships a button. A ticket named after the job ships what the user can now do. Before anyone opens an editor or an agent, fill the four cards — they are the reminder to stay on the problem:

  • Problem — today, who cannot complete what job, because, that means.
  • User — who is trying to do this job: role plus in their words — not the seat alone.
  • Job to be done — When I… I need… so I can…
  • Success — what is true in the product, that they can see.

n2 example

The control is “delete form.” The job is: an admin retires a form without silently breaking templates that still depend on it.

In GitHub, do this

Paste Problem, Role, Job to be done, and Success. Title [Role] outcome they can see. Status stays Needs discovery until those four lines have no brackets.

In FigJam, do this

Fill the four Lesson 1 cards above and copy the mad-lib. If the room wants a shared board, duplicate FigJam and fill the same four frames. Paste into GitHub before minute 22.

Playbook to reuse

Rituals — how a story moves. Tenets: accountable, empower.

Last run: not yet · Next: late August · Homework: one other open card gets User / Job / Success.

DRAFT

2 · Requirements live on the issue

Must / should / not is the contract. Open questions have an owner and a date, or they are decoration.

5-minute version

A list of screens is not requirements. Write what must be true, what can wait, and what we will not do. Put unknowns in the questions table with a name and a date. Duplicate FigJam intake to think; paste the decision back onto the issue. Then set status to In FigJam.

n2 example

Form-delete: Must — show templates that use this form before delete completes. Not this time — bulk-delete of unused forms.

In GitHub, do this

Three musts, one not-this-time, one question with owner + date. Link the FigJam duplicate. Status In FigJam.

In FigJam, do this

Same duplicated board. Fill Must, Should, Not this time, Open questions, Constraints. Paste onto the same issue.

Playbook to reuse

UX research — decision first. Behavior over opinion.

Last run: not yet · Next: early September · Homework: every open question on the live card has an owner.

DRAFT

3 · Do not invent, then walk the job

Reuse what we already specified. Then walk the job. Critique starts here, not in lesson 1.

5-minute version

Before an agent writes UI, fill AI-dev notes: what to reuse, what not to invent, which states exist. If a preview is up, spend ten minutes walking the lesson-1 job. Pass, hesitate, or fail at a named step — not “looks fine.”

  • Reuse: list filter chrome, EmptyState, raw MUI Table, status chips.
  • Do not invent: a second nav, a new modal stack, hex colors, “Submit” on a human action.
  • States: empty, loading, error, success, permission denied.

n2 example

Walk form-delete as the admin: can they see dependents, stop, or finish without a silent break? If they hesitate on an unlabeled icon, that is a fail at that step.

In GitHub, do this

Fill AI-dev notes. Link preview. Status Ready for build or In review.

In FigJam, do this

Only if you are critiquing: duplicate Board 3. Ten minutes. Fix now / ship / split. Do not start a new flow map.

Playbook to reuse

Components & Patterns — filters, empty states, overlays.

Last run: not yet · Next: mid–late September · Homework: next PR description names the pattern it reused.