Design studio 1: from brief to prototype

Design is taught in a studio for reasons beyond having a room. A studio shows unfinished work while it can still change. A design developed in private is defended only once revision is too costly.

The contested question is a sharp one. Are the studio's familiar artefacts, the sketch, the paper prototype and the persona, evidence about users, or only a persuasive way of talking about them? The evidence is thin and uneven. One experiment supports making several candidates before refining one. The comparison studies mostly agree about which problems a test finds. The persona method has critics, defenders and little outcome data. When a designer must defend a decision to someone who does not share their taste, that matters.

A studio is a method for being wrong cheaply

Donald Schon described professional practice as a conversation with the situation. The practitioner acts. The situation answers back in unpredicted ways. The practitioner adjusts the next act. He called this reflection-in-action, and drew it from five professions.

Competent practitioners, Schon argues, know more than they can state, and that knowledge shows in the adjustments they make mid-task. A studio turns the claim into a setting: the designer acts before the problem is understood, with a critic beside the action.

The central case is a review in an architecture studio. The master, Quist, reviews a student named Petra, whose elementary school will not sit on its slope. Quist lays tracing paper over her drawing and draws as he talks. He reframes the problem rather than correcting the drawing. He tells her to begin with a discipline, even an arbitrary one, and break it open later.

The evidence is interpretive. Schon reasons from cases and interviews, not from a comparison, so the studio's advantage is theory, not a measured effect. The case shows the move, not how often it happens, and Schon warns that Quist's speed may hide his reasoning.

A brief is a set of questions, not a specification

A brief arrives as the client's account of what they want. It mixes a goal, a constraint, and a solution the client has already chosen. Separating the three is the first design act. In the invented brief, "reduce missed appointments in the walk-in clinic" is a goal. "There is no budget for more reception staff" is a constraint. "Build a text reminder" is a solution. Treat it as a hypothesis, not an instruction.

Two instruments make the brief testable. A task analysis breaks the work into goals, sub-goals and steps, so you can say which step your design changes. A scenario walks one named person, with a situation and a motive, through those steps as a story. A storyboard draws that story in frames. A scenario belongs between what you found out and what you decided to build, so it can be argued with before it becomes a requirement.

The questions have a shape: who is making the appointment, and what happens when the message never arrives. Answer each with evidence you can gather this term.

Sketching is thinking in a cheap medium

Bill Buxton argues that sketching and prototyping are separate activities with separate jobs, and that confusing them is expensive. His subtitle states the distinction as two aims: getting the design right, and getting the right design. Refinement serves the first. The second needs a range of candidates before any is developed, because the most consequential decision is which idea to pursue.

Buxton claims a sketch is quick, disposable and ambiguous on purpose. Its roughness invites change. A polished rendering invites approval. His own case is a time-trial bicycle for Lance Armstrong. Its designer, Michael Sagan, produced thirty or more sketches a day, each a different concept. The book is a practitioner's case library, not a study.

What follows is a quota: cheap ideas before any expensive one. The clinic team draws twenty thumbnails of one screen, four differing in structure rather than decoration, so the critique stays on structure.

The evidence for many ideas before one

The strongest study here compared two ways of working, not two designs. Dow, Glassco, Kass, Schwarz, Schwartz and Klemmer (2010) ran an experiment in which thirty-three participants designed web banner advertisements. Everyone produced five prototypes and a final advertisement, and everyone received descriptive critique. Only the order differed. The serial group was criticised after each prototype. The parallel group made three prototypes before any feedback, then two more, then a final design.

The parallel prototypes performed better on every measure. They drew more clicks in a live campaign and higher ratings from the client and from advertising professionals. A designer holding several prototypes can see which differences matter. One refining a single prototype cannot. The authors call the failure it corrects fixation: improving one option steadily without examining the others. Nearly half of the serial participants reported negative reactions to critique. No parallel participant did.

The study is the clearest evidence for a habit more often justified by tradition, and its limits belong beside it. The participants were novices, though about half reported design experience. The task was advertising, not a complex system, the sessions were short, and click-through measures attention rather than quality.

This fixation has its own evidence. Jansson and Smith (1991) tested whether seeing an example narrows what a designer produces. Their fixation group received the problem with a sample design. Their control group received it alone. Both produced similar numbers of ideas, but the fixation group copied the example's features more often. They called this design fixation: a blind adherence to a set of ideas that limits conceptual design. Engineering students on short written exercises supplied the evidence, not users.

Fixation has a newer source. Wadinambiarachchi and colleagues (2024) asked sixty people to sketch chatbot avatar ideas with no inspiration, an image search, or an AI image generator. The generator group copied more of the example in the brief, and produced fewer, less varied and less original ideas than the group given no inspiration. The authors name part of the mechanism fixation displacement: attention moves from the example onto whatever the tool returns. One short experiment with novices, so a risk rather than a rule.

What a paper prototype can and cannot tell you

Marc Rettig's account of low-fidelity prototyping remains the plainest. Build the interface from paper and card. Have one team member play the computer. Give real people real tasks. Write one observation per card. Paper is fast, so more iterations fit into the time. Its unfinished look also turns feedback from appearance towards behaviour.

The case he reports is a workshop in which a visiting consultant put the developers into four teams, each building a paper menu for a fast food restaurant. The teams then competed on how quickly their menus could be used unaided. Within about six hours the group had learned the method and measurably improved the design.

The failure it answers opens his column. A team designs in private and codes the result, showing it to users only at the end. A long list of comments then arrives, from the basic metaphor to the background colour, and there is no time left to act on it.

The evidence about fidelity itself is more surprising. Walker, Takayama and Landay tested low-fidelity and high-fidelity website prototypes, in paper and on a computer, with task-based user tests. They found the two equally good at uncovering usability issues. The results did not depend on the medium. On this evidence, fidelity is not what makes a test informative. The tasks and the people are.

Practice has drifted away from the sketch, and the newest evidence says why. Chen and Yoon (2024) interviewed ten designers and design educators in North America. Digital prototypes won on sharing and asynchronous comment. All-in-one tools pulled sketching, wireframing and polished mock-ups into one file, and design systems made a finished-looking screen quicker than a paper one. The authors also read the comparison studies together and find no significant difference between low and high fidelity in the problems a test uncovers. A paper flow can show whether a patient understands what gets confirmed, but not whether the confirmation arrives while they are still looking at the phone.

Personas are a modelling device, and easy to fake

A persona describes an archetypal user built from what was observed. It sits between the research and the scenarios that follow, not at the front of a document, so that a team's decisions stay anchored to one person while the team designs for a population.

The critique is sharp and published. Chapman and Milham argue that it is difficult to determine how many users a given persona represents. Its relevance to the intended users is unknowable. They also argue that a persona cannot be verified or falsified, so it has no demonstrable validity. They add that personas generate political conflict in teams and weaken the researcher's ability to settle questions with data. A persona can be adjusted to support a decision already taken.

Ronkko and colleagues reported that conflict in practice. At UIQ Technology, a Symbian subsidiary, the interaction design team built three personas: a teenager, a young woman and a middle-aged man. The team waited for marketing to choose, and the go-ahead never came. Two clients joined late, the requirements fragmented, and the team closed the work down. The obstacles were commercial, because clients protected launch dates. The new personas also competed with an undocumented inherited persona of the travelling business man.

The dispute is live, and each side is weak on evidence: the critique offers no data, the defenders no outcome evidence. Treat the persona as a mnemonic and a discipline, not a finding. Every detail traces to something observed, and a persona never answers a question a test can answer. The UIQ case does not show that personas are unsound. It shows a method defeated by the organisation before it was used.

Beyond the screen: journeys and blueprints

Bitner, Ostrom and Morgan argue that services are fluid, experiential and produced in real time by customers, employees and technology. They have few static properties, and techniques for prototyping physical products do not transfer well. The authors' technique, service blueprinting, visualises a service process in enough detail to show where it fails, including the parts the customer never sees.

Their worked example runs from the reservation through check-in and room service to check-out, marking beneath each step the on-stage work, the back-stage work and the systems the service depends on.

A journey map follows one person through time and marks where the experience drops. A blueprint lays that journey over the machinery: the points of contact, the work behind the counter and the systems both depend on.

In the clinic project the reminder fails repeatedly, and the interface is not the cause. Messages are sent by a system the reception team cannot see. The patient's reply arrives at a phone nobody answers at lunchtime. Drawn as a screen flow, the design looks finished. Drawn as a blueprint, the dependency becomes visible. The fix is organisational rather than graphical. The article's cases are the authors' own work and measure no outcomes.

Judging work that is not yours, and surviving judgement of your own

Heuristic evaluation needs no users, which makes it easy to misuse. Nielsen and Molich described it as an informal method: several evaluators receive a design and are asked to comment on it. One evaluator found between 20 and 51 per cent of the problems. Aggregating three to five evaluators did rather well.

The method is run against a short list of heuristics. Report a violation with the screen, the action and the consequence, then order the findings by severity.

An expert finds the problems an expert can see. That set differs from the problems users meet, and no study above shows the two lists match. The heuristics are a filter, not a substitute for testing.

Presenting a decision is the same discipline pointed outwards. State the claim and name the rejected alternative. Give the evidence, say what it cost, and say what would change your mind. Receiving critique is harder. Write it down and answer the question that was asked. Separate "I will change this" from "I will test this". The portfolio makes the discipline visible.

Once a prototype exists, some questions are about the machine underneath. How long does a request take? What happens when the network fails? Everything named here is real except the clinic, which is invented. The next stage goes under the prototype, to the systems that decide whether it is usable.