A design system project usually starts with good intentions and a capable team. A few months later there are three button components in Figma, two color scales, a Storybook nobody trusts and a Slack thread arguing whether the new card is a variant or a separate component. Every sprint reopens the same questions: which button is the real one, what the spacing scale is, who approves a new icon, whether dark mode is in scope.
Each of those is a decision nobody has made yet, and a room full of smart people with opinions is bad at making decisions by talking.
So start with the decisions, before anyone names a token. Book a 90-minute Lightning Decision Jam with the five to nine people who design and build the UI. It ends with the top-voted problems turned into tasks with an owner and a date, and those tasks, usually about governance, set the order of the first weeks of the build.
What is a Lightning Decision Jam?
A Lightning Decision Jam (LDJ) is a short, timed workshop: people write problems in silence, vote on them, reframe the winner as a “How might we” question, write solutions in silence, and prioritize them by effort and impact into tasks with owners. It was created by AJ&Smart, the Berlin design sprint studio. Jonathan Courtney, one of its founders, described it in Lightning Decision Jam: A Workshop to Solve Any Problem, and AJ&Smart keeps resources for it. I didn’t invent any of it. What we do is facilitate it, and adapt the framing for design system kickoffs.
The whole method rests on four rules. People write alone and in silence before anyone speaks. Choices are made by dot voting, so the loudest person or the most senior one doesn’t win by default. Problems get rewritten as “How might we…” questions before anyone proposes a fix. And every step has a timer that nobody extends.
AJ&Smart’s original version has more steps than ours, including an opening round on what’s already working. For design systems we run a compressed six-step version, because the team usually arrives knowing exactly what hurts.
The session
Before the day. We put 20 to 50 screenshots of the real product on a FigJam or Miro board: login, dashboards, tables, forms, mobile views, the settings page nobody has touched in two years. That wall is the shared evidence. We don’t send a slide deck. The goal is to get what’s already in people’s heads onto the board.
Who’s in the room. Five to nine people: a product manager, designers, front-end engineers, whoever leads product, and ideally someone from support who hears user complaints every day. Fewer than five and you’re missing perspectives. More than nine and the timings stop working.
Who runs it. A designer and an engineer co-facilitate. The designer keeps the structure and the clock. The engineer’s job shows up in the last step, when proposed solutions need a quick reality check on what the codebase can absorb.
Then the six steps:
| Step | Minutes | Rule |
|---|---|---|
| 1. Note problems | 4 | Silent. One problem per sticky. |
| 2. Present problems | 4 | Each person reads theirs aloud. No questions, no defending. |
| 3. Vote on problems | 5 | Two votes each. The top one or two move forward. |
| 4. Reframe as a challenge | 3 | Rewrite the winner as a “How might we…?” question. |
| 5. Capture solutions | 7 | Silent. As many as possible, one per sticky. |
| 6. Decide and act | 15 | Vote, place the winners on an effort/impact grid, turn the high-impact, low-effort ones into tasks with an owner and a date. |
The prompt for step 1 is “anything that frustrates you about how we design and ship UI today.” Typical stickies: “we have three buttons and nobody knows which one is current”, “engineers write one-off CSS because Figma never has the state they need”, “I can’t tell what’s in Storybook and what’s only a mockup”.
In step 4, “we have three buttons” becomes “How might we converge on one button and stop the next divergence?” The rewrite sounds small, but it turns a complaint into something you can answer. Silence matters most in step 5, because the first idea said out loud anchors everyone else.
The steps add up to under 40 minutes. The rest of the 90 goes to walking the screenshot wall at the start and running steps 4 to 6 a second time when two problems tie. Plan for a 2.5-hour block in total, with setup before and half an hour after to write the tasks properly.
An action item without an owner and a date is decoration. If the session ends without both, it didn’t work, no matter how good the stickies looked.
What usually comes up first
The first votes usually go to governance:
- Nobody knows which component is the canonical one.
- Design and engineering use different names for the same thing.
- Anyone can add a component and nobody can remove one.
Once those have owners, a second layer shows up: dark mode and theming done halfway, accessibility that passes on some components and not others, and a Figma library that has drifted away from what’s in production.
A third layer tends to stay hidden until the first two are handled: values hardcoded twice (in Figma styles and in CSS) with no token layer, multi-brand support nobody planned for, and no visual regression tests, so every UI change is a gamble.
The order matters. Teams that start with the third layer (building a token pipeline while nobody agrees which button is real) are the ones whose design system turns into an 18-month project.
After the workshop
The workshop is the start. The build that follows usually runs four to eight weeks, and looks roughly like this:
- Audit. A spreadsheet (really) listing every variant of every component, where it appears, and whether it belongs in version one.
- Tokens first. Color, type, spacing, radii, shadows, motion, defined once and consumed by both Figma and code. The Design Tokens Format Module from the W3C Design Tokens Community Group reached its first stable version in October 2025, and tools like Style Dictionary and Tokens Studio support it, so there’s less reason to invent your own JSON shape.
- Primitives. Button, input, select, checkbox, radio, toggle, modal, tooltip. The handful every product needs.
- Composites and patterns. Cards, tables, forms, navigation, empty and error states, plus the patterns that combine them (“table with filters”, “settings form”).
- Storybook and documentation next to each component, with every state covered and visual regression tests on pull requests.
- A pilot screen. One real surface (the dashboard or the settings page) migrated completely. This is where the missing component and the token that doesn’t fit show up.
- Handoff. Contribution guide and a governance document: who can add components, who reviews, how versions get bumped.
The governance document is the output that most directly answers what the team voted for in the workshop.
When you don’t need one yet
I’ve told teams not to start. If you have fewer than three product surfaces and one designer, you need consistent naming, not a system. Before product-market fit, build the product and let the patterns settle first. And a single engineer maintaining a design system alone usually spends more time on upkeep than the system saves.
Running a first one yourself
You don’t need an outside facilitator for a first LDJ. Read AJ&Smart’s write-up, put 30 screenshots of your product on a board, and keep the timer visible the whole session. Then look at the top-voted problem: when it’s about who decides, and not about what a component looks like, that’s the problem your design system project has to solve first.
If you’d rather have someone outside the team run it, in English or Spanish, the workshop page has the details.
Updated September 23, 2026: rewritten, and figures I couldn’t back up were removed.