Design Sprints

A sprint needs a challenge with room for learning and a decision that the learning can influence.

Can someone understand a new service well enough to choose it? Does the proposed onboarding help them reach a useful first moment? Can a digital interaction prepare someone for the conversation that follows in person?

Those questions can give the work a manageable center. “Design our entire business” rarely provides enough focus. “Make everyone agree with the solution we have already chosen” leaves little room for discovery.

We would begin by understanding what is uncertain, what is already known and what would become possible if the uncertainty were reduced. Existing research, customer questions and the team's experience can help. Sometimes they reveal that a sprint is premature: we need to hear from people first. Sometimes a focused design or technical task is already clear enough to proceed without a sprint.

Choosing the method is itself a design decision.

GV's Design Sprint guide describes a five-day format connecting challenge framing, competing ideas, decisions, a prototype and customer testing. That is an important reference, not a promise that every Abstraction engagement fits into one prescribed week.

We offer facilitated sprints independently and within larger projects, with timing shaped around the challenge and the people involved. Preparation, access to participants and the complexity of what needs to be made all affect the arrangement.

Adapting the format should preserve its purpose. If we have only explored ideas and selected a direction, we should describe that achievement accurately. A workshop without the intended testing is not evidence that the proposed experience works for its audience.

The connection between activities matters: what we understand shapes what we explore; the decision shapes what we prototype; the prototype makes a question possible to investigate. The observations then need a way back into the business decision.

We clarify the question, gather relevant material and agree who needs to contribute. That might include someone who understands customers, someone responsible for the service, a designer, a developer and the person with authority to make the eventual business decision.

Not everyone needs to contribute in the same way. A specialist may help us understand a constraint. A staff member may describe an awkward handoff that the rest of the team rarely sees. People testing the prototype need to reflect the experience we are investigating, rather than simply be the easiest colleagues to recruit.

We also plan how people can take part. Reading ahead, quiet reflection, accessible materials and time to consider a question can make the work more thoughtful. Fast discussion should not become a competition in confidence.

Design Facilitation helps establish those conditions and make decision responsibilities clear. Co-creation does not mean every choice must become a vote. Abstraction can synthesize and recommend; final business authority remains with the client.

An early idea can become difficult to question once everyone has invested in describing it. We want enough room to explore alternatives before that attachment determines the outcome.

How Might We is one Design Thinking exercise that can open a challenge. A question such as “How might we help someone understand what happens after they request an assessment?” allows several responses. “How might we add this exact form?” has already narrowed the answer.

Ideas can take the form of sketches, language, sequences or rough demonstrations. Someone does not need to draw beautifully to contribute a useful observation about what should happen. We can help give that contribution a form others can examine.

When choosing a direction, we return to the question and the evidence available. What does this idea help us learn? What assumptions does it depend on? Which concerns are we intentionally leaving outside this test? A popular idea still needs a reason to be the one we investigate.

With a team shaping a furniture-repair service, we can frame a sprint around the promise customers understand. Submitting photographs, receiving an assessment and deciding whether to arrange work are different moments; the first experience needs to make that relationship clear.

The founders are considering a photo-led website, a guided questionnaire and a conversation-first approach. Before building a complete scheduling and quoting system, they want to understand whether customers can recognize the service's value and interpret the first step correctly.

A focused sprint question might be: can someone request an assessment without mistaking it for a confirmed price or booking?

The team could explore different explanations and sequences, then choose one to make tangible. A Storyboard could connect the moment someone notices damage, the information they need before sending photographs, the request itself and the response they expect afterward.

The prototype might include a service introduction, an example of useful photographs, a few questions and the message shown after submission. It would use clearly controlled demonstration information, not collect real customer requests or imply that repair work had been booked.

During research, we would pay attention to what participants think they have agreed to. What do they expect to hear next? Do they believe the pictured price is a quote? Would they expect someone to arrive, or understand that further assessment is needed?

If a participant interprets a request as a booking, that observation would give the team something specific to reconsider. The response might involve the sequence, a label, the price explanation or the service itself. We would not assume that adding one more disclaimer solves the misunderstanding.

The exercise would also leave questions outside its reach. Can staff assess the photographs dependably? How will unusual repairs be priced? Can the chosen systems exchange the required information? Those questions need appropriate operational and technical investigation, not confidence borrowed from an attractive prototype.

A narrowly framed experience can expose a much larger promise. The sprint helps the team examine that promise before building around it.

A prototype needs enough substance for someone to encounter the idea meaningfully. That does not mean every part needs production-level detail.

If the question concerns trust, vague placeholder language may hide the very thing we need to examine. If it concerns a sequence, a polished opening screen without the next steps may give little useful evidence. If it concerns a human handoff, we may need to represent the conversation or message beyond the website.

We decide which parts should feel realistic and which can be simulated. We explain those boundaries so the prototype does not quietly become a specification for a finished system or a promise that difficult technical work has already been solved.

The medium follows the question. Screens, a staged service encounter, a short narrative or a combination may be appropriate. A sprint can connect a digital experience to the people and processes around it.

It is encouraging when someone likes an idea. We also need to understand what they think it means and what they can actually do with it.

Usability Testing gives that inquiry its own discipline. Tasks, participant selection and the way questions are asked affect what the observations can tell us. We want to notice confusion without teaching people the intended answer and then counting their corrected response as independent understanding.

Google's Design Sprint Kit connects prototype feedback with relevant stakeholder and technical review. These contributions answer different questions. A participant's enthusiasm does not establish commercial viability; a technical review does not establish whether someone cares about the idea.

We keep desirability, technical feasibility and viability in view, alongside accessibility, privacy, operating responsibilities and the limits of the evidence. A small study can inform a decision without settling every question about a future product.

The work should leave more than photographs of an energetic session.

A useful record can connect the challenge, alternatives considered, chosen hypothesis, prototype, observations and remaining questions. It should distinguish what happened from how we interpret it, then explain the recommendation that follows.

Proceeding is one possible recommendation. Others include refining the proposition, testing another approach, narrowing the first release or stopping an idea that no longer deserves the investment. We want the client to understand the reasoning well enough to challenge it and carry it forward.

That knowledge can inform development, content, service design and future research. It also gives later collaborators a better starting point than an unexplained design file.

Within Abstraction's Design Thinking, a sprint contributes to the wider cycle:

Discover → Define → Explore → Design / Develop / Market → Learn → Advance → Discover

It concentrates selected work within that cycle rather than replacing it. Preparation may draw on earlier discovery; findings may return us to definition or guide a useful implementation. We do not need a design sprint before every feature.

A Scrum Sprint organizes product work within a particular delivery framework. A Design Sprint focuses inquiry around a proposed experience. The shared word does not make them the same thing.

If your team has an idea it keeps circling, a decision that feels too consequential to guess at, or an existing experience that needs another direction, we can help determine whether a sprint would be useful. We can facilitate it as a focused engagement or make it part of a larger collaboration.

Bring the question, even if its wording is still changing. We can work out what it deserves to become—and what we need to learn before taking it further.

Contact Us