Questions I Ask Design System Teams Before Our First Meeting (as a consultant)
I want clients to make the most of the short time we have together on a call, so here’s how I come prepared.
A few days before our call, I compile a few questions into a fresh Google Doc [see survey template below], and ask the client to fill it.
Useful pre-call context includes team and process maturity, adoption, target users, roadmap items, tech stack, and most importantly: where they're stuck.
Note that it’s not meant to be a very detailed account of all things design systems cover, and I kept it short because I don’t want the client to spend more than 30 to 60 minutes on it.
I’ll use the client’s answers to:
- come up with useful and challenging questions
- tailor my advice to their capacity and priorities
- flag topics I should probably research or refresh my memory on
You’re free to use and remix the survey template below 👇
DM me on Twitter (@kaelig) if you found it useful in a project, or if you have any questions / feedback!
Design System Acceleration Call Survey
The main topics we’ll cover during the call:
1. Design token architecture, automation, delivery
2. Design system tooling & automation
3. Design operations & front-end operations in general
Please share some context on your design system prior to our call, so we can maximize the time we spend talking about your needs and challenges.
Feel free to keep your answers high-level, but be very detailed if you feel like it will help improve the quality of our discussion.
Who are the consumers of the design system?
Useful context: teams, their UI stack, OS/platform, design tools they use.
Who contributes to the design system?
Useful context: roles, full-time contributors and part-time ones, team model (see blog post), contributors outside of the core team…
What constitutes your design system?
Examples: UI Kit(s), components, code examples, tutorials, design tokens, content guidelines, color palettes, logos, illustrations, … and where they are hosted: website/wiki/other, repository structure (monorepo, alongside the product, separate repo(s)), design tools, content management system…
What’s on your roadmap?
Examples: more components, onboarding content, content guidelines, performance improvements, dependency updates, automation, accessibility guidelines…
What’s out of scope for the design system that’s useful to mention here?
Examples: complex components that should be built by product teams, accessibility guidelines, iOS, Android, small screens, old browser support, multi-brand support…
What does success look like in 3 months, 6 months, a year?
Examples: adoption by products X and Y, shipping a new design language to production (powered by the design system), one-off variants of components in the product refactored to use existing design system components, all new projects and features use the design system…
How will you know you’re successful?
Examples: metrics, satisfaction surveys, adoption, production JS bundle size…
How are changes to the design system reviewed and published?
Useful context: design reviews, requirement gathering, manual browser/device testing (what kinds?), design and code versioning strategy (SemVer), visual regression & accessibility automated testing, approval process, testing strategy, package hosting (npm…), content publishing workflow, and any other delivery details…
How do people using the design system get help?
Examples: FAQ, Slack, GitHub issues, office hours, Discourse…
Describe a recent win (or two!) for the design system and the team
Describe obstacles that come in the way of the design system and the team’s success
Anything else on your mind you’d like to bring up?
The survey above is in the public domain and licensed as CC0 1.0 Universal (no copyright).