Design Critique and Your Case Study

Steady is designed, systematised, prototyped, checked and handed off. Two skills turn that work into better work and into a job: running a critique where people can improve the design, and telling the story of the design in a case study. Both come down to the habit this course has pushed since Lesson 1.1, giving the because.

What a critique is for

A design critique is a structured conversation about whether a design achieves its goals. It is not a vote on whether people like it, and it is not approval. Sofia runs every critique the same way, in about thirty minutes:

1. Context (3 minutes). The presenter states the goal (“someone checks off a habit in a few seconds”), the stage (“structure is settled; styling is early”) and the feedback they want (“Is the progress block worth its space?”).
2. Silent review (5 minutes). Everyone looks at the design or clicks through the prototype and writes notes. Silence stops the loudest person from setting the agenda.
3. Feedback round (15 minutes). Each person shares their most important points, tied to the goal. A facilitator keeps time and steers away from solving everything live.
4. Wrap-up (5 minutes). The presenter summarises what they heard and what they will look into. Decisions happen after, not in the room.

Giving feedback that helps

Useful feedback has three parts: an observation, its likely effect on the user or goal, and a question or suggestion. Compare:

The useful versions are about the user, not about the critic’s taste, and they leave room for the designer to find the best fix. Phrasing as a question also admits that you might be missing context.

Receiving feedback

When it is your work on the screen, your job is to understand, not to win. Ask clarifying questions (“What did you expect to happen when you tapped Custom?”), write everything down, and say thank you. Do not explain why every point is wrong; if your reasoning is good, it will survive the notes you review afterwards. After the session, sort the notes into act on, investigate and decline, and decline with a reason you could say out loud.

The case study

A portfolio case study is how a hiring manager decides whether you think like a designer. They will spend a few minutes on it, so the structure has to carry them quickly to the thinking.

For Steady, that means:

• Summary: one paragraph and one hero image. “A habit tracker designed so checking off a habit takes under three seconds; includes a themed component kit and a tested check-in flow.”
• Problem and constraints: who it is for, what the Today screen must do, and your role (“solo practice project, designed in Figma over six weeks”).
• Key decisions: three or four, each with before and after images and the reason. Draft one versus draft two of the Today screen from Lesson 1.2 is perfect material, and so is the dark-mode accent that had to change because teal/700 failed on the dark surface.
• The system: the kit page, the semantic variables in both modes, and one component’s properties, showing you can design for reuse.
• Testing: what you tested, with whom, and what changed as a result. Five friends using the prototype counts if you say so plainly.
• Reflection: what you would do differently and what you would test next.

You started this course by asking what someone opening Steady needs in the next five seconds. Keep asking that question, keep giving the because, and every screen you design will be easier to critique, build and explain.