A team can agree that a website needs improvement while disagreeing on almost everything else. Should customers choose a package or request a consultation? Should a new tool start with a blank workspace or an example? A design sprint gives one uncertain decision a deadline and a way to investigate it. The useful output is a clearer next move, supported by observations.
Choose a question with a real consequence
Write the decision in a sentence that could receive an uncomfortable answer. For an imaginary furniture workshop: “Can a first-time customer request a fitted shelf without speaking to us first?” That question is more useful than “How can we modernise the website?” It points to a specific journey and a meaningful business risk.
List what you already know, what you assume, and what would change your mind. If customers cannot describe their measurements, the answer may be a guided consultation rather than a more elaborate configurator. Leave room for the evidence to change the scope.
Write one decision as a question that could get an uncomfortable answer.
You leave withA sprint question, plus what would change your mind
About a week from question to decision, and you only build what survived the test.
Prepare the people and material before the session
Bring someone who understands customers, someone who can make the business decision, and someone who can explain technical constraints. Arrange conversations with relevant potential users before reserving the workshop. An internal team can spot inconsistencies, but it cannot substitute for the people who will use the service.
Collect genuine questions, example orders, product restrictions, and existing support issues. Use fictional or anonymised details in the prototype. Decide who will facilitate, who will take notes, and how the final decision will be recorded. These small arrangements stop workshop time disappearing into administration.
Make the uncertain part believable
A conventional sprint moves through understanding, sketching, choosing, prototyping, and testing. The prototype only needs enough detail to expose the question. For the shelf enquiry, that might mean a measurement guide, a photograph upload placeholder, and a realistic summary. It does not require a working payment system.
Give participants a situation rather than a sequence of instructions. Ask them to arrange shelving for a particular room, then observe where they hesitate. Record what happened separately from your interpretation. “Looked for a telephone number twice” is an observation; “does not trust online ordering” is a hypothesis to explore.
Turn the findings into a decision
At the end, separate problems with the idea from problems with its presentation. A confusing label may need another iteration. A service that depends on information customers cannot provide may need a different process. A few sessions can reveal useful issues, but they do not establish market demand or predict a conversion rate.
Write a short decision note: what was tested, who participated, what remains uncertain, and what happens next. Choose to build, revise and retest, or stop. If the question is already answered by a straightforward fix, skip the sprint and make that fix.
Before you build
- Choose one consequential decision.
- Recruit relevant participants before the workshop.
- Prototype only what is needed to answer the question.
- Record observations, limitations, and a named next action.