Part 13 of 14 · · 7 min read
Working as a design system designer: collaboration, portfolio and interviews
How to work with product and engineering, write clearly, structure a design system case study, prepare for interviews, and a 30-day plan to practise it all.
A design system is a product whose users are other designers and engineers, so most of the job is communication. Tokens and components matter, but the system only spreads if people understand why it works the way it does and trust the person who maintains it.
This closing part covers the working side: who you collaborate with and what they need, how to present and disagree in clear English, how to show design system work in a portfolio, what interviews tend to look like, and a month-long plan to practise everything in this series.
Who you work with, and what they need
| Role | Cares about | What helps them |
|---|---|---|
| Product manager | Business goals, scope, timeline | Options with trade-offs, and evidence from users |
| Engineer | Feasibility, edge cases, effort | A clear spec, every state, token names, and being involved early |
| QA | Expected behaviour | Acceptance criteria they can test against |
| Marketing and sales | Brand, customer problems | Consistent visuals and flows that demo well |
| Leadership | Impact and return | Outcomes and the measures behind them |
A handoff that holds up
- Bring engineers in at the wireframe stage, not at the end.
- Mark a “Ready for dev” section in Figma with annotations, the flow and every state.
- Include interaction and motion specs, responsive behaviour and accessibility notes.
- Walk through it in a kickoff, and keep one thread open for questions.
- Run design QA once it is built, as covered in Part 12.
Clear English at work
Many design system roles are remote and written-first. Clear, plain English matters more than a large vocabulary. A few patterns cover most situations:
| Situation | Phrases that work |
|---|---|
| Presenting | “The goal of this flow is to…” · “I explored three directions and I’m recommending B, because…” · “The trade-off here is flexibility versus simplicity.” |
| Asking for feedback | “Today I’d like feedback on the hierarchy, not the colours.” |
| Giving feedback | “This works well because… One thing I’d question is…” · “Have we considered…?” |
| Understanding a concern | “I see what you mean. Could you help me understand the concern behind it?” |
| With engineers | “How much effort would this be? Is there a simpler version that gets most of the value?” · “What happens if the API is slow or returns an error?” · “Could we reuse the existing table component here?” |
| Disagreeing politely | “I understand the reasoning, but I’m concerned that… Could we test it with a few users first?” · “Let’s agree on the goal first, then the solution.” |
| Committing anyway | “I’ll go with this. Let’s track one measure so we know whether it works.” |
In writing, keep the order context → problem → proposal → ask, and put the short version first in any async update. A design doc or RFC usually has the same bones: problem, goals, non-goals, options, recommendation and open questions.
Speaking slowly is not a weakness; it is clarity. Recording yourself explaining a project for a few minutes, then listening back, is one of the quickest ways to cut filler words and find the sentences that don’t land.
A portfolio that shows system thinking
For a design system role, attractive screens are not enough. A reviewer wants to see how you think about parts, rules and the people who use them. Two to four deep case studies beat ten shallow ones. Aim for at least one design system case study, one or two product or UX case studies with research and outcomes, and a small gallery that shows visual craft.
A design system case study template
- Hero. One line on what was built and for whom, plus role, timeline, team and tools.
- Context and problem. What things looked like before: an inconsistency audit, slow delivery, a framework that held the team back.
- Goals. Consistency, speed, theming, accessibility, or whichever applied.
- Foundations. A diagram of the token tiers (primitive → semantic → component), plus colour, type and spacing.
- Components. Two or three in depth: anatomy, variants, states, and the reasoning behind one decision.
- Design and code. How Figma variables map to CSS variables or a framework theme, and how the two stay in sync.
- Governance. How others contribute, how changes are reviewed, versioned and documented.
- Adoption and impact. How many products, how many components, and what changed for the team.
- Challenges and learnings. What went wrong, and what you would do differently.
- What’s next.
Never invent numbers
If you don’t have measured impact, use an honest estimate marked as one (“roughly”, “about”) or a qualitative result, such as “engineers no longer write custom CSS for new pages”. Interviewers ask where numbers came from.
- Recruiters skim quickly, so put the role and the impact on the first screen.
- Show the process through real artefacts: sketches, audits, test notes. A generic process diagram says little.
- Give every image a one-line caption: what it shows and why it matters.
- If the work is under NDA, blur sensitive data or rebuild the example.
- Keep a slide version of your strongest case study for live presentations.
What interviews usually look like
Processes vary by company, but most include some version of these stages:
- Recruiter screen. Background, expectations and availability.
- Hiring manager call. Experience and motivation.
- Portfolio presentation. Usually your deepest case study, with questions.
- Design challenge. A take-home task or a live session in Figma.
- Cross-functional interview. With an engineer or a product manager.
- Values or culture conversation.
Questions to expect, and how to shape an answer
| Question | Outline of a good answer |
|---|---|
| Walk me through a design system you built or worked on. | Problem → token architecture → key components → design–code sync → governance → impact |
| How do you decide whether something belongs in the system? | How often it is reused (several places, not one), how generic it is, and what it costs to maintain |
| How do you handle breaking changes? | Semantic versioning, a deprecation period, a migration guide, a changelog and clear communication |
| How do you measure a design system’s success? | Adoption and coverage, detach rate, time to ship, and how satisfied its users are |
| How would you set up dark mode? | Semantic tokens, Figma modes, a theme attribute in CSS, then recheck elevation and contrast |
| Variants or component properties? | Variants when the structure changes, properties when the content changes; watch for too many variants |
| How do you keep Figma and code in sync? | Shared names, code syntax on variables, a token pipeline, Code Connect and regular audits |
| How do you design for accessibility? | The checklist from Part 9: contrast, focus, keyboard, labels, targets, motion |
| Tell me about a disagreement with an engineer. | Agree on the goal, bring data or a prototype, find a compromise, describe the result |
| How do you handle tight deadlines? | Split the scope, reuse system components, tackle the riskiest part first |
For behavioural questions, the STAR structure keeps answers focused: Situation (the context), Task (what you were responsible for), Action (what you did, the longest part, said with “I” rather than “we”), and Result (what changed, and what you learned).
Approaching a design challenge
- Ask questions first. Who is the user, what is the goal, what are the constraints, what does success look like?
- Set the scope out loud. Say which flow you will focus on and what you are leaving out.
- Sketch flows and wireframes quickly, with more than one option.
- Choose one and explain why, using a principle rather than taste.
- Take it to high fidelity with system components and every state.
- Present goal → process → solution → trade-offs → next steps.
Interviews run both ways. Good questions to ask: How mature is your design system, and who owns it? How do designers and engineers work together on components? What would success look like in this role after six months? What is the design team’s biggest challenge right now?
A 30-day study plan
| Week | Read | Practise |
|---|---|---|
| 1 (days 1–7) | Parts 1–3: what a design system is, tokens, Figma | Build primitive and semantic variable collections with light and dark modes, and a Button with every state |
| 2 (days 8–14) | Parts 4, 5, 8 and 9: components, governance, visual design, accessibility | Input, Select, Badge and Table components with a documentation page, plus a contrast audit |
| 3 (days 15–21) | Parts 6, 7, 10 and 11: UX, flows, motion, code | One user flow as a wireflow, toast and modal prototypes with Smart Animate, and a page of tokens as CSS variables |
| 4 (days 22–30) | Parts 12 and 13: QA, research, collaboration, portfolio, interviews | Write a design system case study, record STAR answers to five questions, and run a mock live Figma challenge |
- Read: one part of this series, or a section of it.
- Practise: the largest block of time, in Figma or CSS.
- Speak: explain your own work out loud in English and record it.
- Study a real system: read one component page from a public system such as Material, Carbon or Polaris.
Try this
Choose the question from the table above you would least like to be asked. Write a STAR answer for it in under 200 words, record yourself saying it, and listen back once. Then cut every sentence that doesn’t help the listener follow the story.
Closing the series
That completes the guide: from what a design system is, through tokens, Figma, components, governance, UX, visual design, accessibility, motion and code, to QA, research and the job itself. Part 14 collects the terms used along the way into a short glossary you can come back to.
See a design system in practice: the AppsCode Design System case study