top of page

3-day Design Sprint - Improving release orchestration solution

Web Product

Case Brief


Create a new functionality for an existing customer segment of a release automation solution for software applications.



Large enterprises that are making their transformation to DevOps.


Combine a 5 days Design Sprint exercise into 3 days (time that Senior Management could allocate) and create real-looking clickable prototype to be used for user testing. 


Group of 7 people including CTO, VP of Product, VP of engineering, Product Manager, Sales Engineer (user representative), Back-end Engineer and Designer.

My role

Design Sprint organiser and facilitator.



While running customer analysis, we have observed users making same steps over and over again when building templates for their software releases in the product. The observed participants were re-creating parts of the process that were already existing in their previous projects. Our goal was to help users to save time and promote standardisation of certain processes in their release templates creation.

As DevOps is a complex domain, we wanted to involve few different expertises into the process for solving the problem. We selected Design Sprint as a perfect way for dealing with this challenges in short time period.




As a organiser and facilitator of the Design Sprint, I had few important things to prepare prior to the workshop:

  • select members of the sprint team 

  • hunt and invite users for user testing (for Day 3)

  • make sure that people are familiar with the challenge prior to workshop (so everybody is starting on same page)

  • prepare the exercises and think about the every day structure

Design Sprint Introduction Slides

In order to save time - we had to deviate from the original Design Sprint schedule. Therefore, I have structured our exercise to be only 3 days instead of usual 5 with the below agenda:

  • day 1 - opening up the problem (stakeholders interviews, defining user personas, making user journey maps, setting sprint goal)

  • day 2 - ideation (competition review, solution brainstorming, voting to pick one solution, making story map)

  • day 3 - make & learn (creation of the prototype and user testing).


I also have made a decision to involve limited amount of people into the last 3rd day in order to save people's time, so I've only invited those who would contribute to the prototype creation - designers & engineers. User testing sessions were planned to be recorded so they could be presented back to the full team. 


Design Sprint Launch

There are couple of things that I, as Design Sprint facilitator, always make sure to start Design Sprint with:

- identify key user personas and capture their main goals & challenges . This is needed to ensure that everyone is having a clear understanding of who are we solving this problem for;

- clearly define a problem we want to focus in order to turn it into a Sprint Goal. The goal will be written down on the most visible place to be always available for people during the exercise;

- ask people to commit to the process no matter how confused they can sometimes feel. Only if everybody is committed to the journey - it can be successful.

Day 1

Step 1 - we have started from interviewing stakeholders in order to better understand the challenge. The introduction was done from 2 sides: business (Product Manager) and user (Sales Engineer).

Next, we have talked about the target audience by visiting some of the user personas information that I have prepared before the Sprint start. Important next step - was to define the long term goal: how do we see a success of this feature in 1 year from now?


Step 2 - was a time to create a Sprint Map. We listed all our target users as actors and defined their path to achieving the end goal (the success criteria that we have picked for the Sprint). We ended up having a map with few user journeys and next we voted on the main problem areas to be focused on. The below two problems have collected the most votes:

  • How to allow users identify parts of the process as repeatable / reusable?

  • How to operate / execute those reusable parts?

In the "Design Sprint" book it is advised to not focus on big parts of the work for one sprint, therefore as step 3 - we needed to narrow down the focus area. With the help of voting exercise - we have agreed that to start with solving challenge "How to allow users identify parts of the process as repeatable / reusable?".

Step 4 was about coming up with as many questions regarding the selected challenge as possible - so we started writing the "How Might We" notes.

We have grouped similar "HMW" notes into 4 groups:

  • HMW allow Admin to define process requirement?

  • HMW enforce rules during release design time?

  • HMW enforce rules during run time?

  • HMW ensure that the rules are followed?

Working with "How Might We" notes

Next, it was a time to vote to select a problem to be solved during this 3 day Design Sprint. Everybody in the group received few coloured dots and have been asked to give their votes to a challenge group (or groups) that they thought we needed to focus on. Decider had a special vote that could overwrite the others, however he preferred to go with the team's opinion. 


With having a topic to focus on - we have closed the first day to continue the work next morning.

Day 2

We have opened up day 2 of Design Sprint with looking back into all the work that was done during Day 1 in order to recap and get ourselves into the brainstorming mode. 

Step 1 in the beginning of a second day - was to look into inspiring examples from other businesses to help everybody get ideas and be ready to do some sketching.

Step 2 - was to run the four-step sketching exercise to come up with ideas, remix and improve on each other solutions. 

As a result - we had 6 sketch boards that were reflecting team's ideas on the solution.


Step 3 - it was a time to run a critique session and decide which ones have the best chance of achieving the goal. Team voted for best parts from all the solutions suggested with the help of coloured dots and proceeded with story board creation as step 4. We have divided a whiteboard wall into 16 pieces and started filling them with top voted pieces from sketching exercises. Final step was to fill in all the blank spots until we had a ready skeleton (storyboard) to start building the clickable prototype during the next day.


Day 3

For Day 3 day of the Design Sprint - our goal was to create a real-looking clickable prototype for a chosen solution. We decided to use Sketch to build screens and InVision as a tool for building interactions.

Since the product was not containing many complex graphical elements and complicated visual components, we have allocated 0,5 day for building prototype and 0,5 day for running usability testing. As a facilitator - I have taken care of users recruitment before the Design Sprint start.

In the second half of Day 3 - our User Researcher have conducted 3 usability testing sessions with 3 test users. Sessions were recorded and presented back to the Design Sprint team with the summary report later.


Outcomes of the usability testing:

- 100% of testers were able to quickly find their way to create a reusable element and well understood the placement of these elements in the product's user interface;

- 66% preferred to have the reusable element content expandable in order to be able to see what is inside (this request was added to the backlog as an enhancement);

- 66% requested to have the reusable element disabled or editable based on user permissions (this request was added to the backlog as an enhancement);

- 100% liked the feature visual design and wanted to see it in the product.


After the successful results of the user testing - we have scheduled few small design thinking sessions to complete the feature with more details and run more validation sessions to ensure the desired outcome.

Design Sprint exercise proved to be an effective tool in solving broad challenge with fast speed and cross-functional knowledge. Compressing the exercise from 5 to 3 days allowed us to limit the involvement of business stakeholders and free up their schedule.

At the end of 3 day process - we were able to achieve first results in solving user challenge and receive a great start for further feature development.

bottom of page