A small brief.
A sharper design instinct.
Three exercises you can finish in a sitting. Try your own solution before opening the example; more than one approach can work.
Make a form recover gracefully
A fictional event signup loses the attendee’s message when the email address is invalid.
Your constraints
Keep email and message. Specify labels, error feedback, focus, retained values and success confirmation. Do not collect real details.
What to make
Sketch the initial, invalid, corrected and successful states. Write two observable acceptance criteria.
Review your work
- A person can locate and understand the error without color alone.
- The message survives the failed attempt.
- The success state explains what was submitted and what comes next.
Finished your attempt? Explore one possible approach.
One possible approach: show an error summary linked to Email, keep the message, associate the inline correction with the field, and show a clear confirmation after success. Test announcements and focus in the implementation; a sketch cannot prove them.
Compare the related example ↗Reflect: What did you assume, what did you trade off, and what evidence would change your decision?
Offer an upgrade without pressure
A fictional note-taking app offers a paid plan after someone reaches a free storage limit.
Your constraints
State the actual limit, price and billing period. Provide a clear way to dismiss or manage existing storage. No fake urgency, hidden recurring charges or guilt-based copy.
What to make
Design an upgrade choice and a useful alternative. Explain one business/user tradeoff.
Review your work
- The price and commitment are understandable before purchase.
- Declining is clear and does not prevent access to existing work.
- The screen explains options honestly without implying a false deadline.
Finished your attempt? Explore one possible approach.
One possible approach: “You have used your free storage. Upgrade for [real price and interval], or manage files to free space.” Give both paths readable labels. Test whether participants understand the cost and believe their existing notes remain accessible.
Compare the related example ↗Reflect: What did you assume, what did you trade off, and what evidence would change your decision?
Make the first project feel possible
A fictional collaboration tool shows a blank dashboard to a new workspace owner.
Your constraints
Support the new-owner state, no-permission state and failed-create state. Keep sample data visibly labeled.
What to make
Build a low-fidelity three-state prototype and a neutral task for a usability session.
Review your work
- The empty state explains why it is empty.
- The main action works for the person’s permission level.
- Failure preserves work and offers a safe retry.
Finished your attempt? Explore one possible approach.
One possible approach: a new owner sees “Create first project”; a viewer sees who can grant access; a failed create preserves the name. A fictional example project can demonstrate structure, but should never look like a real saved project.
Compare the related example ↗Reflect: What did you assume, what did you trade off, and what evidence would change your decision?