sharaf/professional-design-system-architect
Design, build, or audit professional UI design systems across strategy, product language, foundations, tokens, components, patterns, accessibility, content, Figma/code libraries, documentation, QA, governance, adoption, measurement, theming, releases, and migration. Use when the user wants to create a design-system blueprint, review an existing design system, fix design-system drift, plan Figma/code parity, define token or component architecture, evaluate accessibility and governance maturity, or sequence design-system adoption and migration work.
100
100%
Does it follow best practices?
Impact
100%
1.75xAverage score across 3 eval scenarios
Passed
No known issues
task.mdevals/scenario-1/
Design System Blueprint for a Fintech Startup
Problem/Feature Description
Vaultly is a personal finance startup building a mobile-first web application that helps consumers track spending, set savings goals, and manage investments across multiple linked accounts. The product is in private beta with roughly 2,000 users, and the team is preparing for a public launch in six months. Currently the engineering team of eight uses a mix of hand-rolled utility CSS, a few ad-hoc React components, and a shared Figma file that different designers edit without strict rules. The result is a product that feels inconsistent — buttons look different between the onboarding flow and the dashboard, error states are absent in half the forms, and spacing feels arbitrary.
The Head of Design has been tasked with creating a design system before the public launch. She wants a coherent foundation so the team can build the next six months of features at speed without accumulating more visual debt. The system needs to support the web application for now, with mobile apps planned on a 12-month horizon. The product handles sensitive financial data, so trust, accessibility, and consistency are non-negotiable. There is no dedicated design-systems team yet — the two designers and two senior engineers will own the system alongside their feature work.
Output Specification
Produce a complete design system blueprint document named design-system-blueprint.md. The document should cover all relevant areas of the system in enough depth to guide the team's work immediately, while being appropriately scoped to the startup's current size and resources. Where information about the business or technical environment was not provided, make reasonable assumptions and clearly label them as such. Do not leave large areas unaddressed — if something is out of scope, state why.
In addition, produce a brief assumptions.md that lists the key assumptions you made and what additional information would change your recommendations, so the team knows where to validate before committing.