How to use Design Sprint in Open Source projects

In NearForm, we applied our client Design Sprint methodology to kick-start an Open Source project. We used a two-day workshop to design Node Clinic , a performance toolkit for Node.js developers. Over the course of two days, the team defined the problem and developed a user-centred solution. As part of our Open Source initiatives in NearForm, we would like to share details of how we conducted the Design Sprint for Node Clinic - a diagnostic and performance toolkit for Node.js developers. This blog post will describe the Design Sprint for Clinic Doctor - one of the tools in Node Clinic.

A Design Sprint is a method of applying design principles to design a solution that solves a problem based on user needs. A lot of projects fail because there is no UX research before development begins. If we don't focus on the user needs upfront and go straight to development then there is a high probability our product will fail.

The majority of Open Source projects are made for developers, so developers see themselves as the end user. When developers are not making products for their own use, they need to take the time to understand and empathise with the people who will use the product. The Design Sprint helped the Node Clinic team build a solution that answers the user needs.

The Design Sprint also helped us innovate. By listening to each other's viewpoints and assembling them into an idea, we were able to design a first-class solution.

There are three necessary ingredients for a Design Sprint: a challenge, the right team and design space.

Before a Design Sprint, the team spends time sharing and discussing knowledge and material around the challenge. Sharing information helps the team build an understanding of the problems and challenges faced by the users, the business, and the project's domain. It also introduces more common ground and helps with a smoother introduction to the Design Sprint. Our challenge involved exploring solutions to help developers investigate and fix performance issues in Node.js applications. We concluded that there are not many tools available to help dig into performance issues, so we decided to create some.

The right team for a Design Sprint includes a leader or decision-maker, a facilitator and people with a diverse set of skills. The decision-maker understands the problem in depth and decides how things move forward in the Design Sprint. The facilitator is responsible for managing time, conversations, and the overall process. The rest of the Sprint Team are a mix of domain experts and the people who build the product - engineers, designers, product managers. Each person in the team will provide unique viewpoints that combine to create unexpected solutions. To achieve our goal of creating developer tools with a great user experience we assembled a team of experts in Node.js Core, Data Science, Design, Front-End Development, Data Visualisation and Product.

It is necessary to have a dedicated, bright, and spacious room for the entire length of the Design Sprint. Booking the same room for the duration of the Design Sprint means you can continue each day without having to set up or move. It is also essential the Design Sprint team has access to sticky notes, markers, flip chart paper and whiteboards.

A Design Sprint follows a set of specific steps usually over a five-day period. However, a team can achieve a lot in two days. We would like to share in detail the activities and learnings for each of the two days of our Design Sprint as well as our progress post-workshop.

Day 1 of our Design Sprint process involves understanding and setting the challenge for the Design Sprint. We start by defining the product goal. Next, we spend some time understanding a typical user of our product by exploring their goals and motivations as well as the pain points they currently experience. At the end of Day 1, we discuss opportunities to improve the pain points in the user experience.

Setting product goals early in the Design Sprint helps the team align with an understanding of the project initiative. Goals focus on the user needs and business objectives. These goals guide and motivate the team throughout the sprint. Compose clear and concise goals by specifying if it is a short or long-term goal, the type of person who will use the product, the overarching capability the product will provide a user and what differentiates the product from others solutions in the market.

With our user identified we make a fictional character who represents the needs, goals and motivations of our target user. We refer to this fictional character as a persona and use it to guide product teams in decision making throughout a Design Sprint. Without personas, we are not able to understand and empathise with a typical end user, and our attention is not focused on designing a product that addresses their needs. We identified a mid-level developer named 'Alex' as our persona. Throughout the rest of the Design Sprint, we designed Node Clinic from Alex's perspective. It is important to note that we decided not to target an entry-level or expert developer as our persona. Based on field research we concluded that that the mid-level developer deals with Node.js performance issues regularly and often requires assistance.

Our persona Alex and our project goal.

As-is User Journey Mapping gives the sprint team a shared vision of the process a person goes through to accomplish a goal. We used a User Journey Map to describe how our persona, 'Alex', currently resolves Node.js performance issues. By exploring his everyday experience, we were able to identify pain points in his journey that Node Clinic could address.

Our As-is User Journey Map illustrating Alex's current experience of resolving Node.js performance issues.

With the pain points of the current user experience identified, we discussed opportunities to improve it. We discovered a major pain point in the experience when the user checks and rechecks their code based on a system of guessing the possible reasons why their app is experiencing performance issues. We decided to focus on this pain point for the rest of the Design Sprint. It is important for the team to agree on a pain point that is achievable and in scope.

Day 2 of our Design Sprint process involves ideation and creative thinking around our solution. We begin by getting inspiration from products in other domains not linked to our own. Feeling inspired, we brainstorm big ideas and create a storyboard that outlines the entire experience a user has with the product from start to finish.

With the challenge established, we were ready to sketch big ideas. However, the process of coming up with ideas can be daunting. We understood from our user journey map that our persona 'Alex' needed to consider a lot of information to figure out performance issues with their app. To create a seamless user experience for our performance tools, we needed to think about how Alex can access this information directly and quickly. Bearing this objective in mind, we decided to study examples of data visualisation to get inspired. The website, https://informationisbeautiful.net/ is an excellent resource for data visualisations. Feeling encouraged, we began to sketch solutions together on the whiteboard. It is important to note that depending on your project and team; it is sometimes a good idea to create these initial ideas individually to avoid groupthink.

After deciding on the ideas we liked best, we began to sketch a storyboard collaboratively on the whiteboard. Storyboarding blends the best ideas into a story that outlines the entire experience a user has with the product from start to finish. Here, we discussed and designed each screen of our tools in the context of how the user sees when using them to resolve performance issues with their Node.js app. It is important to note that depending on your project and team; it is sometimes a good idea to create storyboards individually before doing a collaborative storyboard.

A whiteboard sketch of a major screen in Clinic Doctor illustrating how it displays performance issues in an application as well as recommendations that guide the developer towards more specialised tools to look deeper into specific issues.

By the end of Day 2, we had the storyboard complete. Although our time together ended, we carried on with the next phase of the Design Sprint remotely.

The next step in the Design Sprint is prototyping. The storyboard informs the design of the prototype. The designer builds a high fidelity interactive prototype with feedback and content input from the rest of the team. The prototype describes interactions outlined in the storyboard in more detail.

A prototype screen in Clinic Doctor. Sketch and InVision were used to create the prototype. The final stage is proving our product fulfils customer needs by observing how our target users react to the prototype. The team discusses the results and incorporates the learnings into the prototype. It is a cycle of sharing, learning and iterating until we come up with a product solution that addresses the user's needs.

There is a rich pool of talented developers in the Open Source community who work on interesting projects in need of design guidance. Design Sprints offer a social and comprehensive means for designers to get involved, developers shouldn't hesitate to reach out to designers for assistance. Engage designers by introducing the project and informing them that you are interested in using the Design Sprint methodology. Good designers always look for opportunities to expand their creative repertoire.

The NearForm Design Sprint Handbook and NearForm Design Sprint Templates are available for download to help you with your Design Sprints. The nearForm Design Sprint Handbook is a guide to how we run Design Sprints at nearForm. The NearForm Design Sprint Templates are used throughout a Design Sprint. They create a shared understanding of the activities that occur in a Design Sprint and ensure the team gathers the necessary information in each phase of the Design Sprint. We also recommend the book Sprint by Jake Knapp, the creator of Design Sprints.

Good luck and happy sprinting!