Are Design Sprints Worth It?
A case study on how the government leveraged Design Sprints for public safety
Design Sprints have mixed results for many reasons. Some people feel they can’t accomplish anything of value in such a short period of time or that it won’t scale on larger projects.
From my experience, there is value to be gained from using Design Sprints, but like with any method, you must learn how and where it should be applied.
To investigate this further, I want to walk you through a project we worked on for the U.S. government. The Federal government has made great strides in adopting the latest industry trends. For example, Customer Experience (CX) best practices are a presidential mandate, requiring various agencies to perform and prove their adherence to specific CX standards and methods.
These methods cross over into user experience, human-centered design, Agile, and other user-centered methods — include Design Sprints. In one such case, we had the privilege of helping the government utilize Design Sprints to develop a Food Recall dashboard utilizing publically available data from the Food and Drug Administration (FDA).
As the U.S. population increases in size and food distribution become more complicated, the need for well thought out recall processes will grow. This project was about public safety and making sure our supply of food is safe and sustainable.
According to the Food and Drug Administration (FDA), there were 1,928 food and cosmetic recalls in 2018.
This article outlines various lessons learned from this effort to illustrate how Design Sprints are facilitated and what can realistically be accomplished in such a short period-of-time.
Our Approach and Plan
Our goal was to import information from an opensource data repository on recalled food and create a compelling and easy to use design to outline the data by State. We performed a 1-week Design Sprint to accomplish this project, including User Research, Card Sorting, Prototyping, Development, Usability Testing, and Launching the product.
The team included a Product Manager, Interaction Designer, Visual Designer, and Front-End Web Developer. All team members provided input into an initial plan to complete the Design Sprint by the end of the week.
To gain traction and improve the odds of completing the project, the team needed to be clear on expectations upfront. For example, designers and user experience experts will typically start with the end in mind by asking the question, “what does success look like?” In this case, it was to develop a user interface that displays information about food recalls in a dashboard format. The interface must be user-centered and easy to navigate, and it must display pertinent data to help make decisions.
User Research
To better crystallize the needs, the team performed light user research, which led to establishing a group of 3 potential users external to the project team. The team planned and executed a Focus Group where the users and project team collaborated to brainstorm and elicit high-level user needs. Several users were interviewed to determine specific interactions.
The research portion occurred over a day and a half. Given the research results, the team determined the overall “ask” from the user group was too much to be completed in one week. This is a common occurrence within Design Sprints and on most IT software projects, for that matter. To prioritize tasks to determine what could be completed in Sprint 1, the project team facilitated a Card Sorting session with the user group to organize and prioritize the identified features.
The team then created User Stories with Acceptance Criteria from the list of features and organized them in a Product Backlog, which is a list of prioritized User Stories. The Product Manager ensured proper prioritization based on the business and technology needs identified during user research. The Front-end Developer established the Story Points to determine the level of effort for Sprint Planning. The team then had to determine what they could realistically accomplish in Sprint 1 to deliver the most business value. This is typically a compromise between essential business functions and “nice-to-have” features. Throughout the project, the Product Backlog was managed to ensure that needs were prioritized with story points to drive the subsequent sprints. The team then took their findings, started to design concepts, and performed peer reviews to elicit additional feedback.
Sketching and Prototyping Design
With all the findings in hand and the User Stories identified, the team started to sketch and visualize potential solutions. The team created three Product Design Concepts through rapid prototyping. The concepts were leveraged to gain immediate feedback from the users to establish the design direction and validate user needs.
During the review session, the project team discovered the users preferred a mix of Product Design Concept 1 and Product Design Concept 3. Product Design Concept 1 was updated in real-time to confirm the feedback directly with the users immediately. The project team then created a responsive design using Bootstrap and Google Android design patterns and D3 Chart Library for the user interface. Coding began using the datasets and API from openFDA.
With the developed application in hand, the team conducted two rounds of Usability Testing with each of the three users for feedback, refinement, and accessibility compliance. Using a cognitive walkthrough technique, the project team asked users to complete a series of tasks using the functional prototype. The tasks given to the users were based on each User Story identified for that Sprint, and users were given the freedom to complete the task on their own with little instruction. Throughout each session, the project team observed the users and captured usability findings. Key findings included updates to the global navigation and the methods by which users could search and/or filter results for Food Recalls. Upon successful iteration and final testing, the team conducted an End of Sprint Review to demonstrate the working prototype and supporting documentation. The team gained approval to push the code to production and post all supporting documentation. The product backlog was updated to reflect completed User Stories, and the development team calculated the team’s initial velocity during the Sprint.
Performing a Design Sprint is not an exact science. Its purpose is to iterate on concepts quickly and to test new ideas within short timeframes. It helps reduce risk by quickly and efficiently producing code based on user feedback. This way, developers are not building products void of user research. However, the degree to which you employ research may vary depending on several things.
For example, how much do you understand about the user's needs, what data needs to be displayed, how should a user navigate the application, and who exactly are the users of the system (i.e., Personas). These are items you never want to assume. It’s important to take the time to understand the true needs upfront. This is one of the reasons that the team started to sketch and visualize the design early. This also helped the Front-end Developer by giving him prioritized and well thought out designs to build from. Thoroughly understanding what needs to be developed before coding is essential to reducing risk and scope. The beauty of a Design Sprint is that you can quickly test-drive concepts at a relatively low cost and pivot if things don’t work out.
Video Case Study
Here’s a video case study I created to give more context to the project. In this video, I’ll walk you through each day and the associated tasks.
