How to run a 60-minute design challenge (and why the timebox is the point)

Most design practice fails for a boring reason: there is no deadline, so there is no forcing function, so the work expands until it is abandoned. The unfinished redesign in your Figma account is not a discipline problem. It is a scoping problem, and a timebox fixes it. It is also why this is the practice that matters now.

Sixty minutes is short enough that you cannot polish and long enough that you have to make real decisions. That combination is the entire value. Under an hour you are forced to choose what matters, and choosing what matters under pressure is the skill that separates designers who are useful on a real team from designers who are useful when given three weeks.

Why one hour and not three

The instinct is that more time produces better work. For deliberate practice the opposite is closer to true, for three reasons.

Repetition beats duration. Twenty one-hour sessions give you twenty complete cycles of decide-make-evaluate. One twenty-hour project gives you one. Skill acquisition tracks the number of feedback cycles far more closely than the total hours spent, which is why a musician practising scales daily improves faster than one who plays for a whole Saturday each month.

A timebox exposes your priorities. When time is abundant you can do everything, so you never have to decide what matters most. When you have sixty minutes you must choose, and reviewing what you chose is the most informative thing about the whole session.

It is sustainable. An hour fits in a real working life. A four-hour practice block does not, and a practice habit you cannot maintain produces nothing regardless of its theoretical quality.

The protocol

Here is a split that works. The specific minutes matter less than the fact that each phase has a hard boundary and you move on when it ends.

Minutes 0 to 10: read the brief and commit to one angle

Read the brief properly — the brand, the business model, the objective, the customer. Then write one sentence, out loud or in a text file: the main thing I am going to change is X, because Y.

This sentence is the whole session. It stops you from drifting into a general tidy-up, which is what most practice sessions collapse into. If you cannot write it in ten minutes, pick the most obvious problem and commit anyway — a decisive answer to the wrong question teaches you more than an hour of hedging.

Minutes 10 to 20: decide the mechanism before you open Figma

This is the phase almost everyone skips, and skipping it is why so much practice work looks competent and persuades nobody.

Ask what you are relying on to change the visitor's behaviour. Are you reducing the effort required, and if so which kind — cognitive, physical, time or cost? Are you raising motivation through anticipation, belonging or sensation? Are you adding evidence through social proof or authority?

If that vocabulary is new, naming the mechanism is the piece to read first. Naming the mechanism in advance does two things. It gives you a criterion for every subsequent decision, so you stop arguing with yourself about taste. And it gives you something to evaluate afterwards that is not "do I like how it looks".

Minutes 20 to 45: build

Twenty-five minutes of making. Two rules.

Do not start from a blank canvas — iterate on top of something. Starting from nothing burns your best thinking on layout scaffolding you have built a hundred times before. Working on top of an existing design forces the harder and more realistic skill of deciding what to keep.

And do not fix everything. Your sentence from minute ten is the scope. Everything else stays as it is, however much it itches. The discipline of leaving a bad thing alone because it is not this session's problem is directly transferable to shipping work.

Minutes 45 to 55: make it real

Turn the static design into something that responds — a click-through prototype, or actual code if you work that way. This phase is not about engineering. It is about the fact that a design you cannot interact with hides its own problems. Transitions that felt obvious turn out to be confusing, the flow you imagined turns out to have a dead end, the copy you liked turns out to be too long to read at speed.

Minutes 55 to 60: write down what you learned

Three sentences. What you changed, what mechanism you were relying on, and what you would do differently. Skipping this converts practice into activity — you did a thing, you learned nothing you can name.

Over twenty sessions these notes become the most valuable artefact you own. They are also, conveniently, the raw material for a case study worth reading. This one came out of a single timed session, and the note under each skill is what got written in these last five minutes.

The four failure modes

Redesigning a product you do not understand. Another Spotify concept redesign teaches nothing, because you do not know the constraints, the business model or what has already been tested and rejected. Without those, every decision is aesthetic. Use a brief with a real business context instead — this is what a complete one looks like.

Polishing instead of deciding. If you spend twenty of your twenty-five build minutes on spacing and type, you practised visual tidying, which you are probably already good at. The scarce skill is judgement under ambiguity, which is also the kind of practice that pays off.

Working with no evaluation criterion. Without a stated mechanism, the only available review is whether you like it, and you always like it — you just made it. State the mechanism up front and the review becomes answerable.

Running over. The moment you allow sixty-five minutes, you have allowed ninety, and the session stops being a forcing function. When the timer ends, stop, even mid-flow. Especially mid-flow.

What to do when the hour is not enough

It will not be enough. That is the design of the exercise, not a flaw in it.

When you run out of time with the work unfinished, do not extend. Write down what you would have done next and why, then stop. That note — the record of what you deprioritised under pressure — is often more revealing than the artefact itself, because it shows what you actually believe matters when you cannot have everything.

Real projects end this way too. The version that ships is always the version time allowed, and getting good at choosing which parts survive is not a compromise on craft. It is the craft.