Decider
- Has the authority to choose which solution is prototyped
- Usually the founder, product head or business owner
- Can delegate the call for a day, but not skip the sprint
Design Sprint
Design sprint services
You have a product idea and one big question nobody can answer from a meeting room. Agnotic Technologies runs a design sprint that sets up a strong foundation for your product: one question, a realistic prototype and sessions with real target users, before any production code is written.
Map, sketch, decidePrototypeTested with real usersBacklog ready
Trusted by global innovators
The method
What is a design sprint?
A design sprint is a structured workshop that takes one product question from a mapped problem to a prototype tested with real target users, in five stages: map, sketch, decide, prototype and test. Agnotic Technologies runs design sprints for founders and product teams who need evidence before they commit to building.
The output is not a finished design. It is an answer to a specific question, such as whether new patients understand a sign-up flow or whether finance managers trust an automated match, plus the prototype and notes that produced that answer.
A design sprint is narrower than a full discovery engagement. It tests one risky idea quickly; it does not plan architecture, compliance or a release.
Decision table
Design sprint, discovery sprint or wireframing: which should come first?
Three first steps that are often confused. Pick the one that matches the question you cannot answer yet.
| First step | Question it answers | Who attends | What you leave with | Choose it when |
|---|---|---|---|---|
| Design sprint | Will this idea work for the people we are building it for? | A decider, a domain expert, an engineer, a designer and a facilitator for the whole sprint, plus target users on test day | A tested prototype, recorded findings and backlog items | The concept itself is the biggest risk and you want evidence before scoping a build |
| Product discovery sprint | What exactly should we build first, on which architecture, and what will it take? | Product owner, technical lead and subject experts in scheduled sessions | A scoped first release, an architecture outline and a delivery plan | The concept is settled and you need scope, architecture and a plan you can act on |
| Wireframing | How should each screen and flow be laid out and annotated? | Product owner and designers, with engineering review | Annotated wireframes for every screen in scope | The flows are agreed and the team needs screen-level detail for estimating and building |
Many products use two of these in order: a design sprint to test the concept, then a discovery sprint or wireframing once the answer is known.
The five stages
What happens at each stage of a design sprint?
The standard format gives each stage one day. Every stage produces something the next stage needs.
Map
The team agrees a long-term goal, lists the questions that could stop it, draws the path a user takes from first contact to the outcome and picks one target moment on that map to work on.
Sketch
Each person reviews existing ideas, then works alone to sketch a detailed solution for the target moment. Working alone keeps the loudest voice from setting the direction.
Decide
The team reviews the sketches silently, votes on the strongest parts, and the decider makes the final call. The chosen parts become a storyboard of the screens to prototype.
Prototype
Designers and an engineer build a realistic prototype of the storyboard: clickable screens, believable content and sample data, with only the parts the test needs.
Test
About five people from the target group use the prototype one at a time while the team watches. Patterns across those sessions, not single opinions, answer the sprint question.
Roles
Who needs to be in the room?
A sprint only works when the people who can decide and the people who know the problem are both present.
Domain expert
- Knows the users, the workflow and the rules behind it
- A clinician, a finance lead, an operations manager or a support lead
- Corrects the map before the team builds on a wrong assumption
Engineer
- Checks whether a sketched idea is feasible with your systems and data
- Spots integration and data questions early
- Helps build the prototype and later writes the backlog items
Agnotic facilitator and designer
- Runs the schedule and keeps discussion on the sprint question
- Builds the prototype with the engineer
- Moderates the test sessions and writes up the findings
How do we frame the sprint question?
A good sprint question can be answered by watching a few people use a prototype. "Will people like our app?" cannot. "Will a first-time user complete identity checks without calling support?" can.
We start from the long-term goal and rewrite each worry about it as a question that begins "Can we" or "Will they". The decider picks the one that carries the most risk.
We then pick the moment on the user map where that question is answered. The prototype covers that moment and the few screens around it, nothing more.
If the biggest risk is technical, such as whether a vendor API returns the data you need, a short technical spike answers it better than a design sprint, and we say so on the scoping call.
Test day
How do we test the prototype with real users?
Test day is where the evidence comes from, so we run it with the same care as a research study.
- We recruit about five people who match the target user, not colleagues or friends of the team
- Every session follows the same short script, so differences come from the person, not the moderator
- One moderator runs each session while the rest of the team watches and notes what they see
- Notes record what people did and said, separately from what the team thinks it means
- Findings are written as patterns seen across sessions, with the number of people who showed each one
- We report what happened, including results that go against the idea, and never fill gaps with assumed results
Regulated products
What changes when the product handles health or financial data?
A sprint for a regulated product follows the same stages, with a few rules added.
01
No real patient or customer data
Example: A prototype of a patient intake flow, a claims screen or a banking dashboard
Approach: Every name, record and number in the prototype is invented sample data. Nobody uploads a real record to make the prototype look convincing.
02
Professionals as test users
Example: A clinical documentation tool or a care coordination screen
Approach: Clinicians or other licensed users test the prototype, with sessions planned around shift patterns. Patients test patient-facing flows.
03
Medical device software
Example: Software that may be regulated as a medical device
Approach: Sprint findings are recorded as early design inputs. They do not replace the design controls, risk analysis or formal usability work that follow when the product is built.
04
Accessibility from the start
Example: Any product with a public audience
Approach: We include at least one check of contrast, text size and keyboard use in the prototype, so the test does not hide barriers that would appear later.
What do you leave the design sprint with?
Everything the sprint produced, written up so people who were not in the room can use it.
The user map
The long-term goal, the sprint questions and the user journey with the target moment marked.
The prototype
The clickable prototype exactly as tested, so your team can see what the findings refer to.
Decision record
Which sketches were considered, what the decider chose and why, so the reasoning is not lost.
Test findings
Session notes and the patterns seen across users, linked to the screens where they happened.
Answer to the sprint question
A plain statement of what the evidence says: go ahead, change direction or test again.
Backlog items
User stories and open questions for the next step, whether that is discovery, wireframing or a build.
After the sprint
How do sprint findings become backlog items?
Findings that stay in a slide deck are wasted. We turn them into work your team can plan.
1.
Sort the findings
Each finding is marked as confirmed, rejected or unclear, based on how many test users showed it.
Sort2.
Write user stories
Confirmed parts of the prototype become user stories with acceptance criteria. Rejected parts are recorded so nobody rebuilds them later.
Write3.
List open questions
Unclear results become questions for the next study, a technical spike or the discovery sprint.
Plan4.
Hand over
Your team gets the backlog in its own tool, and a walkthrough of the prototype for anyone who missed the sprint.
HandoverFailure points
Where do design sprints go wrong?
The problems we plan around before a sprint starts.
Challenge
The decider drops in and out, so decisions are reopened later.
Agnotic approach
The decider's time is agreed in advance, and a named delegate decides when they cannot attend.
Challenge
The sprint question is too broad to answer with one prototype.
Agnotic approach
The question is agreed with the decider before day one and narrowed to one target moment on the map.
Challenge
Test users are colleagues or friendly customers.
Agnotic approach
Recruiting against a written profile starts before the sprint, with a backup participant.
Challenge
The prototype is polished in places nobody will test.
Agnotic approach
The storyboard limits the prototype to the screens the test script uses.
Challenge
The team reads too much into one session.
Agnotic approach
Findings are reported as patterns across sessions, with the count for each.
When it fits
When is a design sprint the right first step?
Situations where a few days of focused work save months of building the wrong thing.
Design sprint for startups
Founders who need evidence that the core flow works for real users before they raise money or hire a team.
A new product line
Established companies testing an idea outside their current product before committing a team to it.
A disputed feature
Teams split between two approaches, where a tested prototype settles the argument faster than meetings.
A workflow change for professionals
Tools for clinicians, inspectors or finance staff, where adoption depends on fitting the way they already work.
A redesign with an unclear direction
Products whose users struggle, but where the team does not yet agree on the fix.
Scope and cost
What drives the cost of a design sprint?
There is no fixed price list. The scope below is agreed on the scoping call and written into the proposal.
Format
In person, remote or a mix, and whether the stages run on consecutive days or are split.
Recruiting
How easy the target users are to find. Specialists such as clinicians or finance managers take longer to recruit than consumers.
Prototype depth
Whether the test needs a few screens or a longer flow with realistic data and branching.
Platforms
Web, mobile or both, and whether the prototype must run on the user's own device.
Regulated content
Extra preparation for sample data, consent forms and professional test users.
Follow-on work
Whether the backlog write-up feeds straight into discovery, wireframing or a fixed-scope build.
Standards
Standards behind our design sprints
The design and usability standards our facilitators follow.
ISO 9241-210ISO 9241-11WCAG 2.221 CFR 820
Facts and sources
Facts behind design sprints
Standards and rules that shape how a sprint prototype is built and tested, each linked to its primary source.
ISO 9241-210:2019 gives requirements and recommendations for human-centred design principles and activities throughout the life cycle of computer-based interactive systems.
Source: ISO 9241-210:2019, Human-centred design for interactive systems (ISO)ISO 9241-11:2018 provides a framework for understanding usability in the situations where people use interactive systems, and explains that usability is an outcome of use.
Source: ISO 9241-11:2018, Usability: Definitions and concepts (ISO)Under FDA's Quality Management System Regulation, manufacturers of Class II and Class III devices, and of Class I devices automated with computer software, must comply with the design and development requirements in clause 7.3 of ISO 13485.
Source: 21 CFR 820.10(c) (eCFR)Under the HIPAA Privacy Rule, health information that does not identify an individual, and gives no reasonable basis to identify one, is not individually identifiable health information.
Source: 45 CFR 164.514(a) (eCFR)
Frequently Asked Questions
We do not publish a price. Cost follows the format, how hard the target users are to recruit, how much prototype the test needs, the platforms involved and any regulated content. You get a written proposal after the scoping call.
The method's standard format gives each of the five stages one day, plus preparation beforehand to agree the question and recruit test users. We agree the actual schedule with you on the scoping call, because recruiting specialists can change it.
A design sprint tests whether one idea works for real users. A product discovery sprint assumes the idea is settled and plans what to build first, on which architecture and with which compliance work. Many teams run the design sprint first.
The decider, a domain expert and an engineer should attend the whole sprint. Other people can join for the map stage and watch the test sessions. Our facilitator and designer handle preparation, the prototype and the write-up.
Yes. We use a shared online whiteboard for mapping and sketching, video calls for decisions and remote sessions for testing. Remote sprints make it easier to include domain experts and test users in other locations.
It is when the main risk is whether users want and understand the core flow. A tested prototype gives you evidence to show investors and early hires. If your main risk is technical, a short technical spike is a better first step.
Yes. The backlog items from the sprint are the starting point. Most teams add a discovery sprint or wireframing to cover the screens the sprint did not test, then agree a fixed scope for the first release.