Design Systems with Lightning Decision Jam: From Figma Chaos to Ship-Ready

Most design system projects fail the same way. Six months in, the team has 47 Figma components, three competing button styles, two color systems, no documentation, and a Slack channel full of “should this be a variant or a new component?” debates. Nothing ships.

The problem isn’t tools. The problem isn’t talent. The problem is that design systems get built by opinion ping-pong instead of by decisions. Engineers and designers keep relitigating the same five questions every sprint. The button question. The spacing question. The icon question. The dark-mode question. The handoff question.

We start every design system engagement the same way: a 90-minute Lightning Decision Jam (LDJ) workshop. Not because workshops are trendy. Because LDJ is the only meeting format we’ve found that forces a room of opinionated people into shipped decisions in under two hours.

What Lightning Decision Jam actually is

Lightning Decision Jam is a structured workshop format developed by AJ&Smart, a Berlin-based design sprint studio. It’s a seven-step sequence designed to move a group from “we have problems” to “we have prioritized next steps” without falling into the usual workshop traps: opinion battles, anchoring, charismatic-person-wins, designs-by-committee, “let’s circle back.”

The key mechanics:

• Silent ideation. Everyone writes problems and solutions on stickies independently. No discussion until votes are in.
• Dot voting. Decisions made by aggregated preference, not whoever talks loudest.
• Effort-vs-impact mapping. Every solution gets placed on a 2x2. Only the high-impact, low-effort quadrant moves forward this sprint.
• Strict time-boxing. Each step gets minutes, not hours. The clock forces decisions.

We did not invent LDJ. AJ&Smart published the original method and it’s free to use. What we did is adapt it specifically for design system kickoffs, where the problem space is unusually well-suited to the format: lots of opinions, lots of small decisions, no single right answer for most of them, and a strong need to ship.

Why design systems specifically need this

Design systems are decisions disguised as design work. You’re not really debating whether a button should have 4px or 6px border radius. You’re debating who gets to decide button radius across 12 product surfaces, how that decision propagates, and what happens when a PM wants a one-off.

A design system without alignment is just a Figma file. A design system with alignment is a multiplier on every product surface your team ever builds.

LDJ surfaces the actual disagreements (governance, ownership, scope) instead of letting them hide behind component-level debates that have no answer until governance is set.

The exact 90-minute LDJ agenda for design systems

We’ve run this agenda 30+ times. Here’s the version that works.

Pre-work (the day before)

• Audit screenshot board. 20-50 screenshots of the existing product surfaces. Login screens, dashboards, tables, forms, mobile views. We post all of them on a Miro or FigJam board.
• Participants. 5-8 people max. One PM, two designers, two engineers, one product leader, optionally one CX/support person who hears user pain daily. More than 8 and the format stops working.
• No prep deck. We don’t send a 30-slide pre-read. The point is to surface what’s in people’s heads now.

Step 1 — Start the problems list (7 minutes)

Everyone writes problems on stickies, one per sticky. Silent. “Anything that frustrates you about how design and engineering ship UI today.”

Typical stickies:

• “We have three button components and nobody knows which is current.”
• “Engineers ship one-off CSS because Figma never has the state they need.”
• “Dark mode is 60% done in some places, 0% in others.”
• “Designers can’t tell what’s actually in Storybook vs what’s just a mockup.”

Step 2 — Present problems (5 minutes)

Each person reads their stickies in 30 seconds. No discussion. No defending. Just read.

Step 3 — Vote on the most important problems (5 minutes)

Each participant gets 2 votes (dot stickers on stickies). The 4-5 highest-voted problems become the focus.

Step 4 — Reframe problems as “How might we…” questions (5 minutes)

The top problems get rewritten. “We have three button components” becomes “How might we converge to one button component and prevent the next divergence?”

This step is small but it changes everything. Problems pull people toward complaint. HMW questions pull people toward solution.

Step 5 — Solutions on stickies (10 minutes)

Silent again. Each participant generates as many solutions as they can to the HMW questions. One solution per sticky.

This is the most generative step. With 6 people and 10 minutes you’ll get 60-100 solutions on stickies. The silence is the point — it prevents anchoring on the first idea someone says out loud.

Step 6 — Vote on solutions (10 minutes)

Each person gets 6 votes this time. Vote across all HMW questions.

Step 7 — Map solutions on effort-vs-impact (15 minutes)

The top-voted solutions get placed on a 2x2: low-to-high effort horizontal, low-to-high impact vertical.

Only the top-left quadrant (high impact, low effort) goes into the next-sprint queue. Everything else goes into a backlog with explicit “not now” labels.

Step 8 — Turn decisions into tasks (15 minutes)

For each top-quadrant solution, we assign: owner, deadline, definition-of-done. Without these three things the workshop output is theater.

Step 9 — Wrap and document (10 minutes)

The Miro or FigJam board is the record. We screenshot it, post it in Slack, and link it in the design system README on day one.

What typically surfaces

After 30+ design system LDJs, the same patterns surface in roughly the same order.

Sprint 1 problems (always the top three votes):

1. “Nobody knows which component is canonical.”
2. “Designers and engineers use different names for the same thing.”
3. “There is no governance — anyone can add anything, but nobody can remove.”

Sprint 2 problems (after the obvious ones get fixed):

1. Dark mode and theming are inconsistent.
2. Accessibility is uneven (some components pass WCAG AA, some don’t).
3. The Figma library is out of sync with what’s in production code.

Sprint 3 problems (rarely surface in sprint 1 because they’re hidden by the above):

1. There’s no design token layer; values are hardcoded twice (in Figma styles and in CSS).
2. Multi-brand or white-label support was never planned.
3. There’s no visual regression testing — every PR is a roll of the dice.

Knowing the order matters. Trying to solve sprint 3 problems before sprint 1 problems is how design systems become 18-month projects that never ship.

From workshop to shipped tokens — the 8-week path

LDJ is the kickoff. Here’s what happens after.

Week 1 — LDJ + audit

90-minute workshop, then a thorough audit of every component currently in use across product surfaces. We use a spreadsheet (yes, really) listing every variant of every component, where it appears, who owns it, and whether it should live in v1 of the system.

Week 2-3 — Tokens and primitives

Design tokens come first. Color, typography, spacing, radii, shadows, motion. Defined once in a tokens file (Style Dictionary or a custom JSON-to-Tailwind-config setup), consumed by Figma via Tokens Studio, consumed by code via build step.

Then primitive components: Button, Input, Select, Checkbox, Radio, Toggle, Modal, Tooltip. The 8-12 components every product needs.

Week 4-5 — Composite components and patterns

Cards, tables, forms, navigation, empty states, error states. The components that compose primitives into recognizable UI.

We document patterns alongside components: “form layouts,” “table-with-filters,” “mobile bottom-nav.” Components are the parts; patterns are how they fit together.

Week 6 — Storybook and docs

Every component goes into Storybook with full state coverage, controls, and accessibility annotations. Documentation lives next to the component, not in a separate wiki nobody reads.

For teams using Storybook 8+, we wire up visual regression testing with Chromatic or Loki. Every PR runs visual diffs. The cost of catching a regression now is 1/100th the cost of catching it after launch.

Week 7 — Pilot integration

We pick one product surface — usually the dashboard or the settings page — and migrate it entirely to the new system. This is where you find the gaps. The component you forgot to spec. The token that doesn’t quite fit. The accessibility issue that only surfaces under real use.

Week 8 — Handoff

Documentation, contribution guide, governance doc (who can add components, who reviews PRs, how versions get bumped), and a 30-day support window. Your team owns it from there.

Pricing reality

From $2,500. 4-8 weeks. LDJ workshop included.

The $2,500 floor buys a focused tokens + primitives engagement: design tokens defined, 10-12 core components built in Storybook with accessibility, basic docs. Suitable for early-stage startups that need to stop reinventing buttons.

Larger engagements ($15K-$40K) include composite components, theming/multi-brand support, visual regression, migration of one product surface, governance setup, and 30 days of support.

What it does not buy: a design system that lives in Figma but never makes it to code. We ship to production or we don’t take the work.

When you don’t need a design system yet

We’ve talked teams out of starting:

• Under 3 product surfaces and one designer. You don’t need a system. You need consistent naming.
• Pre-PMF startups. Build the product. The system can come at month 18 when you actually know your UI patterns.
• One-engineer teams. The overhead of maintaining a system at that scale costs more than the duplication it prevents.

A design system is a forcing function for scale. If you’re not at scale yet, you’re forcing the wrong thing.

Ready to stop relitigating button radius?

Book a 30-minute call. We’ll tell you whether a design system is the right next move for your team and what it would actually cost. If LDJ alone is what you need, we offer the workshop standalone too.

Learn more about LDJ workshops or book a design system call. For broader product engineering context, see our services page.