What the case studies leave out
Judging a design system portfolio
Systems work is easy to present and hard to evaluate, because a screenshot of a component library looks the same whether or not anyone uses it. What to check before the first call.
01 In production, or a Figma file?
Ask whether the components exist as installable code, and how they are distributed. A studio that delivered design libraries and one that shipped a versioned package did two different jobs at two different prices.
02 Did adoption actually happen?
The metric that matters is how much of the product is built from the system a year later. Studios who did this well know the number, or have a story about why adoption stalled. Others show you the documentation site.
03 Who maintained it after handover?
Ask what happened when the engagement ended — whether the client had a named owner, whether the studio stayed on, and whether the system is still current. This separates studios who watched systems survive from those who only launched them.
04 How many teams consumed it?
A system serving one product is a component library with good docs. One serving six teams needed governance, a contribution model, and someone empowered to say no. Very different work, frequently presented identically.
05 What did they inherit?
Building from nothing is straightforward. Consolidating four inconsistent products with entrenched patterns and teams who like their own version is the hard version. Ask which they did.
06 Is accessibility in the components?
Ask to see focus states, keyboard interaction, and ARIA handling in the delivered components rather than a compliance claim in the docs. Systems that bake this in save every downstream product from retrofitting it.
07 Can they show the boring parts?
Versioning, deprecation and migration guidance, release notes, contribution workflow. Studios who maintained systems have all of this. Studios who only built them redirect to visual work.