Ship a Design Portfolio Worth Showing

Proof required

Submit a link to your design file (Figma, Sketch, or equivalent) containing all 3 iterations with dates, a screenshot or link demonstrating the feature in the live product, and a 150-word design brief: the problem you were solving, the core decision you made between the low and high fidelity stages, and what you would change if you did it again.

What gets checked

• All 3 iterations are present with distinct fidelity levels — a wireframe that is the same as the final design is one iteration, not three; the progression must show real decision-making
• Edge cases and states are annotated in the final design — 'see engineering' is not annotation; empty state, error state, and loading state must be visible
• The feature is live — a Figma prototype shared with reviewers is not a shipped feature; the product must be accessible to users who would naturally encounter it

Common mistakes

• Portfolio work or 'concept designs' for products you don't have design access to — the learning is in the constraints and trade-offs of a real product, which are entirely absent from speculative redesigns
• A design handed off to engineering but never shipped — the shipping step is where you learn how your design survives contact with implementation; it is not optional
• An annotation style that describes what an element is rather than how it behaves ('blue button' vs 'primary action: submits form and navigates to confirmation screen; disabled when fields are incomplete')

Resources

What a verifier looks for

• Ask the submitter to explain the most significant design decision they changed between wireframe and final — if they cannot name a specific decision, the iterations were cosmetic not substantive
• Ask what was hardest about the edge case documentation — this surfaces whether annotation depth came from discipline or afterthought
• Ask what feedback from engineering (or from real users) changed the design most — genuine shipped features always involve implementation-driven revisions that speculative work never encounters
• Ask what they would design differently now — designers who have shipped features always have a specific answer grounded in user behaviour or implementation friction

Proof required

Submit a link to your design file showing the token set, the 10+ components with states, and the usage guide. Submit evidence that the system was used in at least 2 projects (screenshots of the projects using the components). Submit a 100-word change log entry documenting one revision: what changed, why (what failure in usage prompted it), and what you decided not to change and why.

What gets checked

• 10+ components each show at least 3 states — a button library with 10 buttons in default state is not a component system; each component must have its full interaction state set defined
• Change log revision is causally connected to a usage problem — 'updated colours because I preferred them' is not a maintenance entry; 'changed button disabled opacity from 30% to 50% because the 30% version was causing missed clicks on mobile' is
• Token set is semantically named — 'color-blue-600' is a primitive token; 'color-action-primary' is a semantic token that can be updated globally when the primary brand colour changes

Common mistakes

• A system built speculatively without being used in real projects — a design system that has never been used has not been tested and has no meaningful maintenance history
• Components that are unique per use case rather than truly reusable — a system where 'button-primary-hero-homepage' and 'button-primary-product-card' are separate components has not achieved the abstraction that makes a design system valuable
• No semantic token layer — a system where every colour reference is a hex value rather than a token name cannot be maintained; changing the brand colour requires updating every instance manually

Resources

What a verifier looks for

• Ask the submitter to walk through how a rebrand would affect their system — if changing the primary brand colour requires updating more than 1–2 token values, the semantic layer is incomplete
• Ask what the most-used component is and how many times it was revised — genuine system maintenance always produces a history on the most-used component; a clean 'no revisions' answer is a red flag
• Ask why a specific component has a disabled state and another doesn't — understanding the rules for when each state applies is the design system literacy that distinguishes system thinking from component collection
• Ask what the hardest component to make reusable was and what they compromised on — design system design is full of principled compromises; a submitter who doesn't name one has not built a real system

Proof required

Submit your M1 design file link and M2 system link plus the reviewer's written assessment: the design decision challenge and your response, the system architecture challenge and your response, a description of the novel brief and your 10-minute response approach, and their sign-off confirming their role and a live session.

What gets checked

• Design decision challenge response names the alternative considered and the specific reason it was rejected — 'I went with the current design' is not a response; 'I considered a bottom sheet for this action but rejected it because the gesture conflict with scroll meant it failed the thumb-zone test' is
• System architecture challenge response names specific components or tokens that would need to change for dark mode and a specific gap in the current system
• Novel brief live response covers problem framing, user and constraint assumptions, and at least one design direction — a 10-minute response does not need a finished design, but it must demonstrate structured design thinking

Common mistakes

• Novel brief response that starts with visual solutions before naming the user and the problem — jumping to 'I'd make it dark with a pill button' before asking 'who is the user and what are they trying to do?' is the most common design thinking failure mode
• Design decision challenge response that defends the existing design without engaging with the alternative — the reviewer is testing whether you can evaluate your own work critically, not whether you can justify it
• A reviewer who is primarily a graphic designer or visual designer without product experience — the challenge questions require someone who has made shipping decisions about design trade-offs

Resources

What a verifier looks for

• For the novel brief, pick a brief specific enough to have real constraints but open enough to have multiple valid directions — a good brief is 'design the onboarding experience for a habit tracking app for adults over 65' rather than 'design something interesting'
• In the live brief, ask the submitter to name the user's biggest constraint before proposing a solution — this diagnoses whether they start from the user or from the visual
• Ask the submitter what design decision they are least confident about in the M1 feature — confidence calibration is one of the clearest signals of design maturity
• Reviewer minimum qualification: 5+ years of shipping product features (not graphic or brand design without product); design system architecture experience required for the M2 challenge