đ Get weekly insights, tools, and templates to help you build and scale design systems. More: Design Tokens Mastery Course / Podcast / My Linkedin
TL;DR:
đ Bring context â share whatâs relevant before the meeting
đ¤ Include cross-functional team â better insights
đ Maintain cadence â build momentum
đ Document decisions â thank me later :)
â Use a review checklist â donât miss the details
Think of design system reviews as design critiquesâbut not just for design. They're a way to keep your design system healthy, relevant, and usable across teams. Thatâs why you should not treat them as another meeting on the calendar.
Design system reviews:
Include engineers, UI developers, and UX specialists
Evaluate components in their live, functional state
Examine implementation details (when there is no code yet)
Consider ecosystem-wide impacts, not just single-user flows
Focus on developer experience alongside user experience
Assess how components will evolve over time
Ensure alignment with existing patterns
Whatâs the process?
Prep the context
Provide goals, background, and what feedback youâre looking for. Share material or Figma links before the meeting so people can try out components and get their opinions.Quick overview (5â10 mins)
Show the component/pattern and explain the rationale.Discussion
Walk through key areasâusability, edge cases, tech feasibility, etc.Team input
Capture observations, questions, and suggestions.Action items
Agree on the next steps and ownership. What are the jobs to be done?Document everything
Keep a record of your decisions.
đ By the way. Don't wait for the next review session if you need urgent feedback. Use async reviews when needed (also via Figma comments, Slack messages, etc.)
How often should you meet?
My suggestion is 1-hour weekly review. Weekly reviews build momentum. It's better to have only 30 minutes consistently than 1 hour bi-weekly.
But it also depends on your:
Team size and velocity
Development cycles
System maturity and roadmap
Current priorities
Who should you invite?
The design system team is fixed, while others can come when the meeting is relevant to them.
Design system designers & engineers
Design System lead or PM
Product designers (from product teams)
Developers (from product teams)
UX researchers
Accessibility experts
Content designers
Format is flexible
Design system reviews arenât always the same. Sometimes, youâre discussing abstract patterns. Other times, youâre deep in Figma or reviewing live code. One week, you solve UX problems; the next, you debate naming conventions or documentation clarity.
Adapt your format based on whatâs most relevant at the time:
Component-focused reviews â When introducing new components or major updates.
Pattern-focused reviews â When refining shared interaction models or layouts.
Code-based reviews â When assessing technical implementation and developer experience.
Documentation reviews â When improving guidelines, usage examples, or naming clarity.
Audit sessions â When scanning for inconsistencies across the system.
User feedback reviews â When evaluating real-world implementation challenges and pain points.
How to prepare Figma files
First, give the proper context by:
Problem statement & goals
Include research findings (add relevant links)
Create all possible component states and sizes
Usage examples (UI screens, mockups)
Show responsive behavior
Accessibility notes
Interaction states (hover, active, disabled, etc.)
Technical annotations
Comparisons to previous patterns
Decision log (what changed, and why)
The next step is to go to the code side and show how things will be implemented. Make sure you are using the same props, names, etc.
đ By the way, you can also use AI tools to help you create the working prototypes. I will share more helpful AI tools next week.
Define Jobs To Be Done
Create your âJTBDâ list and follow it. For example:
â
Validate user needs
â
Evaluate naming conventions and taxonomy clarity
â
Validate developer needs
â
Ensure consistency and brand alignment
â
Spot edge cases and exceptions
â
Confirm technical feasibility
â
Check accessibility standards
â
Ensure legal and compliance readiness
â
Document decisions and rationale
â
Guidelines
â
Ensure responsive behavior across breakpoints
â
Prepare Figma files
â
Capture usage examples and real-world context (provide links)
â
Identify design debt
Thatâs it. đ Itâs easy. âď¸đ
đ Community Gems
Design Tokens Mastery Course
I published my course last week. đĽł
đ Link
CTRL Var: Rename Variables
Figma plugin
đ Link
Design Systemâs Report
by zeroheight
đ Link
My Upcoming Events
UXCEL â Naming design tokens đď¸ 15.4.2025 (Online)
INTO DESIGN SYSTEMS CONFERENCE â My Toolkit: Educating Teams and Demonstrating Design System ROI đď¸ 28-29.5.2025 (Online)
â¤ď¸ People to follow
This week, I would like to introduce you to Daniel Yuschick. He is currently the Lead Design System Developer at Posti Group. He has over 15 years of experience at the intersection of design and development, specializing in creating accessible and resilient design systems. Starting as a designer and transitioning to frontend development, he's taken on Lead Design Systems Developer roles where he thrives on bridging the gaps between design and code while focusing on the aspects of the web he loves most. He contributes technical articles to online publications like Smashing Magazine and CSS Tricks and mentors aspiring developers through the Helsinki-based non-profits Codebar and Hive Helsinki. He will speak at the Into Design Systems conference in May.
đ Follow Daniel on Linkedin