Design token pipeline serving Web, iOS, and Android
This tests cross-platform design system architecture and governance. A strong answer uses W3C JSON tokens in option, decision, component layers, with Style Dictionary generating Web, iOS, and Android outputs. Red flag: using Figma or CSS as source of truth.
What's really being asked
This question evaluates your ability to architect a cross-platform design system pipeline that treats design decisions as data. The interviewer wants to see that you understand how to prevent drift between platforms, how to structure tokens for scalability, and how to automate distribution without losing governance. Senior candidates are expected to discuss layering, source-of-truth immutability, and build-time transforms rather than runtime hacks.
The full answer
First, choose a W3C design token specification compliant JSON file as the single immutable source of truth, not a design tool or CSS. Second, organize tokens into three layers: option tokens that define raw values like color palettes, decision tokens that map those values to semantic meanings like brand-primary, and component tokens that bind styles to specific UI elements like button-background. Third, select a build tool such as Style Dictionary, Tokens Studio, or a custom Node pipeline to read the JSON and generate platform-specific outputs like CSS variables for Web, Swift constants for iOS, and XML or Compose objects for Android. Fourth, address governance by keeping option tokens private to product teams to reduce file size and support non-breaking changes, while exposing only decision and component tokens. Fifth, define the CI/CD flow, including whether the pipeline is fully automated or requires manual approval for token changes to prevent unintended visual regressions.
The mistakes people make
Treating Figma, Sketch, or CSS variables as the source of truth is a red flag because design tools are not version-controlled artifacts and CSS is platform-specific. Proposing runtime API fetching for tokens in mobile apps shows a misunderstanding of build-time optimization and offline reliability. Ignoring token layering and dumping all values into a flat file signals poor scalability. Failing to mention transforms or acting as if hand-copying values into each repo is acceptable will immediately downgrade the answer.
What usually comes next
How do you handle token versioning and breaking changes across platform releases? What is your strategy when a platform needs a token value that does not exist in the global set? How do you keep designers and engineers in sync when the token spec evolves? When would you choose a fully automated pipeline versus one with manual approval gates?
A concrete example
Imagine a z-index token set. The source JSON defines option tokens for raw numbers and decision tokens for layers like navigation, toast, and modal. The build pipeline transforms these into a CSS custom property for Web, a Swift enum for iOS, and an Android resources XML integer for Android. When design needs to add a new spinner layer, they update the JSON, the pull request triggers the pipeline, and all three platforms receive the new value in their native formats without manual copy-paste.
Interview question
Why is a W3C-compliant JSON file preferred over Figma or CSS as the single source of truth in a cross-platform token pipeline?
- a.Figma and CSS are not version-controlled artifacts and CSS is platform-specificCorrect
- b.CSS variables lack support for color values on mobile platforms
- c.Style Dictionary requires JSON input to generate Swift enums for iOS
- d.JSON files can be edited directly by designers without engineering involvement
Why? this is the answer
The correct answer captures the governance requirement that the source of truth must be version-controlled and platform-agnostic, which Figma and CSS cannot guarantee. Distractor D is tempting because Style Dictionary is part of the recommended pipeline, but JSON is chosen for immutability and cross-platform neutrality, not merely because the build tool accepts it.
Just read this? Test yourself on what you have been reading.
Read the original → martinfowler.com
- #design systems
- #design tokens
- #cross-platform
- #architecture
- #build pipeline
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on design systems — each one lists the topics its interview covers.
See open roles