Stripe.com | Pattern audit to start a design system
Project Type
Personal project, Case study, Skill showcase
Role
Design system designer
Tools
Figma
Chrome web inspection
Mac native screenshot
Chrome web inspection
Mac native screenshot
Overview
This is a personal project to showcase how I do a pattern audit (also called component inventory) to organize existing UI patterns and turn them into a design system component.
Typical usage for the skill is when you initially launched products or websites without a design system, but is considering to optimize scalability post MVP as more repeatable design patterns start to show up.
Deliverables
Image: final design showcase
Design complete on building basic design tokens, 2 components, and 1 utility within 2 workdays.
Components done:
- Button
- Icon button
- Icon box (utility)
- Button
- Icon button
- Icon box (utility)
Button
- 3 variants
- 3 states
- 2 sizes
- 1 boolean property
- 3 variants
- 3 states
- 2 sizes
- 1 boolean property
Icon button
- 4 states
- 4 states
_Icon box
- 2 sizes
- Instance swap property for easy use
- 2 sizes
- Instance swap property for easy use
My Process
Image: my pattern audit process
Capture → cluster → specify → build → hand off
1. Capture — Screenshot and collect repeating UI patterns across pages and states
2. Cluster — Drop collected patterns into Figma and group variations into candidate components
3. Specify — Analyze the properties each component needs and extract styling elements like color, typography, and spacing from web inspection
4. Build — Design, validate, and test the component
5. Hand off — Annotate and spec for engineering
2. Cluster — Drop collected patterns into Figma and group variations into candidate components
3. Specify — Analyze the properties each component needs and extract styling elements like color, typography, and spacing from web inspection
4. Build — Design, validate, and test the component
5. Hand off — Annotate and spec for engineering
Strategic callouts
Although the steps looks sequential, this is not a waterfall process. Make sure to keep validating your own work between Figma and production code to ensure quality of deliverable.
Key step showcase
1. Capture production design
I inspected all button patterns on homepage of stripe.com and took screenshots of each instance. Dumped all screenshots into one Figma file.
2. Analyze and clustering patterns
Looking at all collected screenshots, I started to clustering similar patterns into groups that can lead to a component variation, e.g. filled button, outlined button.
*Tips: the key here is to look for attribute changes, e.g. from filled to outlined button, the fill hex value changes; the outline stoke value changes; the outline stroke color changes.
Image: before and after clustering similar UI patterns.
3. Spec out design tokens (AI + Manual)
The product site already has mature theming system that contains color, typography, spacing and etc. so we will need to collect those specs to ensure consistency with existing branding and production site. This information also helps us set up baseline design tokens.
Before step 1, I kicked off Figma AI agent with the community skill "design-system-generation" to crawl existing stuff on stripe.com and see if anything useful would come out to speed up design.
I also manually inspected and collected css hex code values, font specs, spacing etc. and cross checked with AI output.
The skill was pretty limited and could only work with screenshots of the site rather than reading actual css through the URL so most of the output was junk but still I took the font sizes and basic button states to start my work.
Then I synthesized manually inspected design tokens in to a table mapped with desired token names and modes, asked Figma AI to create those into primitive and semantic tokens in the background.
As AI was doing the busy work, I skipped forward to validate against the production site for any missing token.
Additionally, I analyzed what component properties would be needed in the Figma build, then self-validate against production examples again.Once AI was done, I verified if all created tokens were accurate, applied corrections where needed, and manually linked alias.
*Tips:
- Kick off AI workflows in parallel to human tasks to save time on waiting on AI responses.
- Delegate straightforward busy work to AI while you carry out tasks that need more thinking.
- Always review AI output for accuracy. In cases you can't access source code, asking it to explain its methodology like "how did you get the hex value?"
- Any 6 digit hex codes (i.e. colors with transparency) are only allowed in Figma Fill so make sure to convert to RBGA for Figma variables.
- If you see repeating colors and styles during inspection, you will most likely need a 2-tiered or 3-tiered design token structure.
- Kick off AI workflows in parallel to human tasks to save time on waiting on AI responses.
- Delegate straightforward busy work to AI while you carry out tasks that need more thinking.
- Always review AI output for accuracy. In cases you can't access source code, asking it to explain its methodology like "how did you get the hex value?"
- Any 6 digit hex codes (i.e. colors with transparency) are only allowed in Figma Fill so make sure to convert to RBGA for Figma variables.
- If you see repeating colors and styles during inspection, you will most likely need a 2-tiered or 3-tiered design token structure.
Additional details on the Figma AI skill
Image: AI did output the font size correct and offered some baseline for the enabled and hover states of the button.
Image: AI style guide output that failed to offer accurate specs on color hex, font family or weight, and inferred unnecessary states for the Button.
✅ What worked with AI skill
- Font size and naming are correct.
- Component baseline can be reused:
Enabled and hover state design still offers some template that we can work with.
Dark mode is a good callout to consider.
- Documentation style
The clean documentation style maybe can be reused down the road.
- Font size and naming are correct.
- Component baseline can be reused:
Enabled and hover state design still offers some template that we can work with.
Dark mode is a good callout to consider.
- Documentation style
The clean documentation style maybe can be reused down the road.
❌ What failed with AI skill
- Color hallucination:
All hex codes are wrong given this is only mimicking then rendering via visual recognition not reading the actual css.
- Crucial font specs missing:
Details like font family, font weight are not included.
- Component styling hallucination:
Radius is definitely wrong.
Ghost and destructive buttons might be nice to recommend but may not ever be needed based on Stripe’s use cases in the audit.
Disabled states are inferred but not shown on production examples again.
- Color hallucination:
All hex codes are wrong given this is only mimicking then rendering via visual recognition not reading the actual css.
- Crucial font specs missing:
Details like font family, font weight are not included.
- Component styling hallucination:
Radius is definitely wrong.
Ghost and destructive buttons might be nice to recommend but may not ever be needed based on Stripe’s use cases in the audit.
Disabled states are inferred but not shown on production examples again.
4. Design and validate the Figma components
Image: testing components by checking and inspecting the properties built.
After spec requirements are all set, I applied synthesized properties to the Button, Icon button, and _Icon box components. Then linked Figma variable for fill, outline, text style, border radius, border width, spacing, and dimension.
Once the component draft was done, I tested my own work by:
- checking for any missing Figma component properties
- inserting an instance and play with all properties permutations
- remaking a production example with the Figma draft
- checking for any missing Figma component properties
- inserting an instance and play with all properties permutations
- remaking a production example with the Figma draft
3 issues I found were:
- focus state of the buttons were missing
- the filled buttons were missing the a hover animation on the arrow icon
- button labels were single line text rather than wrapping (so technically the button's sizing dimension token needs to be applied to Height rather than Min-height in Figma)
- focus state of the buttons were missing
- the filled buttons were missing the a hover animation on the arrow icon
- button labels were single line text rather than wrapping (so technically the button's sizing dimension token needs to be applied to Height rather than Min-height in Figma)
After making these iterations, I retested the buttons and repeat this cycle till all observed functional requirements are met in my design matching the production examples.
If you have stakeholders like design system lead or manager who needs to sign off on the design, after the draft is top notch, please take it through the typical design approval loop at your team before handing off.
5. Hand off
During hand off, I usually spec out anatomy, component properties in Figma, spacing and layout, and listing all design tokens. This I ran with a paid version of the Specs Classic plugin by Nathan Curtis. If you are interested, he is working on Specs 2 which is the latest version, it no longer spec individual variants though.
The plugin gets 90% of the job done when I do 1-2 rounds of human review. Typically to fix any mistakes on linking the wrong token or listing out too much repetitive details. This step helps polishing the information so that your developers is only reading accurate and helpful information without getting confused.
The master component and any of its utilities will be spec'ed out in this same format, offering full hand off spec packaged for developers.
I also run Include accessibility annotation plugin from ebay Playbook team to annotate accessibility behavior like reading and tab order. This happens more often to larger components like organisms.
If there isn't an existing Product Requirement Document for the component, I usually will offer some form equivalent to that as well. This functional requirement list sometimes can also happen in the Audit step when I am synthesizing existing UI patterns. The upfront functional requirement drafting is mostly helpful when you have other stakeholders who wants to define component requirements (e.g. design leads, project leads, business and product owners).
Given this is personal case study just to do skill showcase and study other design systems, I did not do a full hand off like what I usually do for work. If you are curious, feel free reach out to chat more.
Design details
1. Recreate custom arrow icon
I was not bale to grab the svg files from web inspection. Additionally, due to the animation, the exact icon size was also hard to inspect. I started with an estimated stroke weight for 2px. This ended up too thick so I went through iterations with close visual comparison to production. Eventually I got it to match production.
Image: diving deeper into pixel details to delivery high quality recreation of the button icon
2. Focus ring position and stroke
The focus ring is 1 px away from the edge f the buttons with 3px stroke weight. In Figma, I zoomed in to make sure it's perfectly in line on all 4 sides. The focus ring was also applied as a show/hide on the all enabled states only because there is not a hover + focus.
Image: zoomed in to check for design details on the focus ring
3. Testing long labels and text wrapping
During testing, I found that the labels also need to be single line text which sets the button as fixed height rather than min height.
Image: long label just overflow to the side but I designed the button labels to wrap so an updated was needed
4. Handling color and text rendering differences
The rendered color and label length were different from the production. The label length is due to my limited access to proprietary font files. The color is due to monitor color profile difference, the token value is correct. So both are acceptable.
Image: rendering difference in label and color
5. Font weight name vs. css numbering
CSS has "bold" font weight in the variable's names but the rendered value is "400" which maps to "regular" only so I deleted the bold token given it was not actually used anywhere.
Image: remove unused tokens
6. Organizing Figma props and default states
Towards end of the design phase, I organized component props with variants first, then top to bottom, left to right for properties like boolean, text value, or instance swap. Additionally, I made sure default states are set to most common use cases for designers.
Reflections & limitations
I actually had fun working through this mini project.
A couple caveats are:
- Simplified scope
Given this is a skill showcase, I only inspected the homepage on stripe.com. For work, I would look at all pages, sites, and cross-platform apps if they need to be covered by the design system as well.
Given this is a skill showcase, I only inspected the homepage on stripe.com. For work, I would look at all pages, sites, and cross-platform apps if they need to be covered by the design system as well.
- Simplified token architecture (2 tiers rather than 3)
Since we are only recreating the buttons, I did not bother to make a 3-tiered design token system. But I actually know Stripe's team does have a tokens file (from their previous conference talk) so in reality, I would ask devs first for the actual css file and synthesize that too rather than infer from web inspection only.
Since we are only recreating the buttons, I did not bother to make a 3-tiered design token system. But I actually know Stripe's team does have a tokens file (from their previous conference talk) so in reality, I would ask devs first for the actual css file and synthesize that too rather than infer from web inspection only.
- Design tokens from Figma rather than Tokens studio
For this exercise I created Figma variables for design tokens, in actual work, I would check or evaluate if Tokens studio + Git repositories setup fits better for the team by holistically considering the end to end workflow of the design system.
For this exercise I created Figma variables for design tokens, in actual work, I would check or evaluate if Tokens studio + Git repositories setup fits better for the team by holistically considering the end to end workflow of the design system.
Additional technical considerations in reality
Questions I would ask the team if I actually work at Stripe:
- Button arrow: what's the actual svg I can use?
- Overall icon size: seems to fluctuate across instances on homepage, do we want a bounding box?
- Outliers during audit: Sign in button on homepage, bookmark button, and the accordion buttons all seem to have a bit more unique features vs. the other buttons, were they custom made or override per business requests? Where else do we use them?
- Existing token files: where I can reused existing design tokens rather than creating new based on the inspection?
- Dark mode: what's existing values for Button, Icon button, and icons are dark mode? (There is a dark mode in code but did not see an example page.)
- Existing icon library: is there existing Figma icon library to use? (I could see they are from w3 but the source seems to be gated by employee access.)
- Padding in decimals: what's the scaling calculation in button padding? (both top and bottom are not integer but xx.5, not sure how we got that from web inspection)
- Button arrow: what's the actual svg I can use?
- Overall icon size: seems to fluctuate across instances on homepage, do we want a bounding box?
- Outliers during audit: Sign in button on homepage, bookmark button, and the accordion buttons all seem to have a bit more unique features vs. the other buttons, were they custom made or override per business requests? Where else do we use them?
- Existing token files: where I can reused existing design tokens rather than creating new based on the inspection?
- Dark mode: what's existing values for Button, Icon button, and icons are dark mode? (There is a dark mode in code but did not see an example page.)
- Existing icon library: is there existing Figma icon library to use? (I could see they are from w3 but the source seems to be gated by employee access.)
- Padding in decimals: what's the scaling calculation in button padding? (both top and bottom are not integer but xx.5, not sure how we got that from web inspection)
Additional non-technical considerations
- Your stakeholder is asking for a design system, but is that the right thing?
Not all teams and products need a design system. Single use micro-sites or landing pages most likely do not use the patterns enough to reap the ROI for building a design system (minimum of 2/3 repetitions is needed). If this is the case, strategic conversation needs to happen for in-house teams to determine next step.
Not all teams and products need a design system. Single use micro-sites or landing pages most likely do not use the patterns enough to reap the ROI for building a design system (minimum of 2/3 repetitions is needed). If this is the case, strategic conversation needs to happen for in-house teams to determine next step.
- Project management and delivery strategy
The products are live and working and design system clean up is just catching up to clean, then you can technically have pattern audits done separately from the design and build phases. How to deliver will be based on your team's capacity, roadmap items for design system as a product, stakeholder dynamic, and politics when applicable.
The products are live and working and design system clean up is just catching up to clean, then you can technically have pattern audits done separately from the design and build phases. How to deliver will be based on your team's capacity, roadmap items for design system as a product, stakeholder dynamic, and politics when applicable.
