Skip to content

Design sprint in one day?

Project Management

Apr 9, 2019 - 11 minute read

Małgorzata Ciesielska
See all Małgorzata's posts

Finops Stickad Blog430x300


How we used three stages of the design sprint in just one day to create a concept of an application for helping people.


The purpose of the sprint was to build a concept of an application, which would create quick access to professionals that could be able to help people in need (medically), and people from medical facilities looking for staff that could be either redirected to an accident or fill in a short vacancy.

As you may already be aware, even for us, the medical industry as a whole is pretty complex. This, however, means that it can be really tricky to build and keep things simple for both for the customer and the potential users not to mention providing full transparency to make all the parties feel confident and in control.

At the moment of starting the one-day design sprint, we knew we need to create a simple, easy-to-understand experience on requesting and accepting medical help, so we started out with the ambitious but rather vague in nature goal of “make it simple for our users to request and offer help”.

A major goal for the customer, which we learned only during the sprint, was to understand how they could address right people to right places keeping in mind time pressure, legal obligations and their competencies.

We decided that Design Sprint was exactly the sort of methodology for discovering the customer problem and help us solve it. We had only one day with a group of stakeholders, so we wanted to make the most of the time we had and to fully engage people involved in defining business needs, project and product goals as well as learn the pain points.

Sprint preparation

We had only one day before the sprint since the customer changed the arrival date. We took a serious yet hectic set of steps to prepare for the event, and that is:

  • Prepare all the deliverables such as post-it notes, markers, flipcharts, white paper and have them available in the room,
  • Put all the papers on the wall before the meeting so that all participants could see what we would be doing,
  • Prepare and post on the wall templates needed for the exercise,
  • Organize a clock to stay on time with all the planned tasks,
  • Have a round of agenda review with all internal participants to make sure the planned agenda time is doable and meaningful for all parties involved. We wanted to make sure that the potential outcomes of the tasks would not overlap.

Sprint team

Here’s the fantastic crew for the one-day design sprint:

  • Facilitator (UX Specialist)— did the job of running a tightly structured and demanding workshop,
  • UX Specialist - support in the sprint
  • Decider — product owner from the customer side for the, who had a crucial role when it comes to decision making about the project
  • Operation specialist from the customer side, who provided information about the nature of the project since she has been in a close cooperation with the potential target users
  • Lawyer
  • Operation Support Expert
  • Business Analyst
  • Project Manager

Original Agenda

Here is our original tight agenda, which was planned:

  • 9:00 - Introduction
  • 9:30 - Learn & Address Expectations
  • 9:55 - Break
  • 10:00 - Lightning talks
  • 10:45 - Coffee break
  • 11:15 - Long term goal
  • 11:25 - Project Questions
  • 11:35 - User journeys
  • 12:30 - Lunch break
  • 13:00 - Ideation
  • 13:40 - Sketching
  • 14:40 - Prioritization
  • 15:40 - Assumptions + parking lot (Optional)
  • 16:10 – Finish

You can find a short summary of what we managed to achieve from the agenda at the end.

Some warm-up before the sprint

We started off the design sprint with a warm-up exercise with “Hopes & Fears” to learn what participants expected and worried about the sprint. This short exercise let us find out what are the hopes and fears of each of the individual taking part in the workshop to then address them during the event.

Post-it notes on a board during a design sprint

Sprint process

Due to the availability of our stakeholders, we had to condense a 2-day Design Sprint 2.0., and that is: Understand (Learn about and define the problem) Diverge (Create many ideas that might solve the problem) and Converge (Decide on the promising ideas to take forward) into one day. Namely, to get all the juicy bits before we can continue with the project and focus on the design itself.

If you’ve never heard of that, you can learn more here.

We moved from one activity to another and the day went by really fast. Everyone on the sprint was fully committed. Frequent recaps and revisions of each of the task outcomes made it clear to everyone that each and every exercise had its purpose, and everything is connected. Unfortunately, there was no space for “superfluous” warm up tasks, interruptions, phone calls or any “business as usual” things. We went straight to the sprint goal to make the most of the available time.

We kept the time very strictly.

For people like me, who need time to mull over ideas, it would have helped to have prepared in advance or do some discovery phase. Unfortunately, sometimes those things are extravagancy. We did all we could with the time and resources we had.


After deciding on our main goal, we needed to break it down into questions so that we could try to answer in the sprint. After spending some time discussing what ‘make it simple and meaningful’ meant to us, we came up with the following sprint questions, which let us formulate the design sprint problem, which we worked on through the rest of the day, and that is:

  • Find people quickly (bearing in mind technical aspects)
  • Make sure that right people are notified
  • Create more efficient way of reaching professionals
  • Keep trust

In order to achieve that we used the “How might we” exercise.

After that, we moved to the next exercise that was to define the long term goal (“In two years time…”) to learn the ideal situation, where everything went fine. The crucial goal for the customer was to “Be ahead of competitors,  create new competition AND change the market”.

After that, we swimmingly shifted to a task to learn the doomy gloomy reality, what if such long term goal is not achieved – to discuss and think of the worst case scenario, namely what could stop the customer from reaching the set goal.

Once we finished with verbalizing and noting down sprint questions, we started trying to map the customer journey, where we’d focus our efforts for the rest of the day. This helped us create a more tangible outcome of the sprint we could operate and work on.


To stimulate our participants, we involved them in a task called “Crazy eights”, that each team member meant to come up with concepts that could be used with respect to the earlier prepared journey map. This was useful exercise to get creative thoughts flowing and help us consider how these ideas could be exploited in later designing process and how well do they fit into the project goal. Each of the member then presented and explained his/her ideas to others and tried to tag it to the user journey map itinerary.


Once we did that, we then spent a few minutes reviewing the individual solutions, taking notes on things we liked about them and sticking up any questions we had about the solution. This let each solution get an equal voice and reduced bias in selecting our next step. We narrowed down to our best ideas by simply voting. The ideas in these solution sketches would become the foundation of our prototype to be built outside of the design sprint event.

After reviewing and voting on which ideas we thought would best help us answer our sprint questions, we separated our ‘winners’ from our ‘maybe laters in the parking lot’ and began working on needs, wants and desires. This task, let us translate ideas into a tangible list of functionalities required to be present in order to make it workable. It also helped us figure out priorities - when there are a lot of features but there is lack of good sense of what is most important.

Lesson learnt from the one-day design sprint

This was super concise day with a high pace and just few breaks – not much time to take a deep breath and ponder on any of the discussed items. The ones we did not have much time to discuss ended up on the parking lot.

Additionally, the original design sprint task “How might we” puts some mental strain, that is you need to remember to properly phrase all the mentioned problems in the appropriate form “How might we [resolve the problem]” and this unfortunately could slow us down. Therefore, we decided slightly modify the task so that each participant simply put them as notes and we could later on reformulate them.

Normally, all the participants would have enough time to look for some inspirations available online and around us or, what is more, there would be time to set the background for finding concepts to further work on.  Unfortunately, we decided to focus only what is available to us from the experience since again lack of time.

In terms of sketching and voting, even though the heat map given a clear visual indicator of what people were mostly responded to, there is always fear that people voted on what is most familiar to them at a first glance without much pondering on other options which might be potentially more valuable.

There was also not much time for discussion to learn all arguments for and against a given idea. The heated arguments or structured-decision making was resorted to a Decider with all its downsides.  Some of the crucial aspects of the user journey map had to be left undecided for the moment of the sprint such as onboarding, legal aspects, notifications and vested on the designers when working on a prototype offline.

Customer feedback

Even though we had to quickly pace the design sprint since lack of time and customer availability, we still received very positive feedback. The customer appreciated a condense form of the event, pace and time coordination. There was no time for any superfluous activities. The order, good preparation and time management allowed us to reap the fruits of our labour. Not only did we manage to work on a common concept but also had enough time to think of any obstacles, potentials and work ahead of us in terms of the project.

Undoubtedly, there were still some questions once the sprint ended, but we managed to work on them offline with a customer through email exchange or short teleconference meetings since we had already set a common background.


We have some tips we can share with after running one-day design sprint:

  • Keep a finger on the pulse of the participants, energy level can dwindle after some mentally demanding tasks. Even though you have prepared agenda beforehand, it might be useful for the sake of the sprint and the participants to have more breaks and recharges than planned. Perhaps at the end of the day you might do less, but you might find the outcomes more valuable.
  • Don’t treat Design sprint methodology as a Bible you need to follow at all costs. We decided to treat it as an example we could fall back on to achieve our sprint goal but not the sprint itself. The sprint is meant to be a wheel to get us to a destination point, that is project goal.
  • Don’t be afraid of a bit of debate, it’s an important part of the process, but make sure it stays constructive. Allow participants some time for discussions when creating agenda.
  • Make sure that you regularly revisit your sprint goal and sprint questions and, if necessary, update them throughout the sprint. Thanks to this all the participants feel confident that they are here for a reason and see what the goal is we are all aiming at.
  • It seems to be viable and doable to carry out originally 3-stage design sprint (namely Understand, Diverge and Converge) just in one day as long as:
    • all the participants have been cautiously selected and might bring the most food for thought to the project,
    • the nature of the project allows for some flexibility in terms of content and the discovery phase has been carried out before the sprint starts to constructively run it.
    • Building the concept is a planned outcome for the sprint not the finite solution.

What’s next

We finished our one-day sprint with the customer and managed collect valuable amount of data to be able to carry on with the project alone in a group of designers and business analyst only. However, we did manage to present our outcomes to the customer and mutually agree on the design to carry on with the project.

We took a few days to mull over the sprint outcomes and note down all the findings since becomes like a sieve with time. We boiled down our findings from the sprint session and all the challenges we might face when it comes to the project.  These were mainly about onboarding process, notifications and legal aspects of commencing a job request which need to be clarified before it goes into development stage.

Currently, we are working on preparing testing scenarios and prototype.

Final agenda

Here is what we managed to deliver from the original agenda:

  • 9:00 - Introduction
  • 9:30 - Learn & Address Expectations
  • 9:55 - Break
  • 10:00 - Lightning talks
  • 10:45 - Coffee break
  • 11:15 - Long term goal
  • 11:25 - Project Questions
  • 11:35 - User journeys
  • 12:30 - Lunch break
  • 13:00 - Ideation
  • 13:40 – Sketching (Unfortunately we did not manage to work on sketching the concept together with the customer. The reason why we skipped it is that we already built together a user journey, which was enough to work on after the sprint).
  • 14:40 - Prioritization
  • 15:40 - Assumptions + parking lot (Optional)
  • 16:10 – Finish

You can find a short summary of what we managed to achieve from the agenda at the end.


Undoubtedly, we gained valuable insight on how the customer think about their project, where they want to be in terms of their business and what they want to achieve with this solution. The carried out “design sprint” did not cover prototype and testing stage due to tight schedule and the customer availability.

One day sounds like madness, but it enabled us to focus in a way we hadn’t been able to previously, and to ensure that we had enough time to work on a shared understanding of what we are trying to achieve, where we would like to be in a couple of years with the solution and what we need to focus on primarily.  For truly complex projects, this timescale is simply not recommended.

Finally, with the Sprint process itself, we learned where we can be flexible and where it’s important to stick to the plan and what potential values it can generate to the project.  We definitely want to use this approach again for other problem scenarios, but we also see “goes without saying” adopting and extending it to original timescale if time, stakeholder availability and project nature allows for such extravagance.

Additionally, since the project nature we took on board seemed to be quite wide, perhaps it would be worth considering scaling down the project phases to smaller separate design sprints such as: onboarding, reporting, requesting and accepting job requests. When starting, we did not know what the feature would be like. We needed to work together to find the best solution, and to give us a higher chance of getting the feature right at the first time of trying and Design Sprints worked well for this.

What is more, the design sprint has all the merits and characteristic of helping us gain confidence in an area that we did not yet understand at the moment of starting the project.

Finops Stickad Blog430x300
Małgorzata Ciesielska
See all Małgorzata's posts

Related posts

You might be also interested in


Start your project with Objectivity

CTA Pattern - Contact - Middle

We use necessary cookies for the functionality of our website, as well as optional cookies for analytic, performance and/or marketing purposes. Collecting and reporting information via optional cookies helps us improve our website and reach out to you with information regarding our organisaton or offer. To read more or decline the use of some cookies please see our Cookie Settings.