We had the privilege of helping the Federal Government utilize Design Sprints as an approach to developing a Food Recall dashboard. According to the Food and Drug Administration, there were 1,928 food and cosmetic recalls in 2018. 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 is all about public safety and making sure our supply of food is safe and sustainable. Our task was to pull information from an opensource data repository on recalled food and to create a compelling and easy to use design to outline the data by State. To accomplish this task, we performed a 1-week Design Sprint, which included components of User Research, Card Sorting, Prototyping, Development, Usability Testing, and Launching the product. I want to share some lessons learned from this effort in the hopes of improving how Design Sprints are facilitated and what can realistically be accomplished in such a short period-of-time.
The Team
The project 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 first Sprint by the end of the week. To gain traction and improve the odds of completing the project in 1-week, 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.
To better crystallize the needs, the team performed light user research, which led to establishing a user group of 3 potential users, all of whom were 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 results from the research, 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 Sprints, and on most IT software projects for that matter. In order 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.
User Stories and Needs
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. The Product Backlog was managed throughout the project to ensure that needs were prioritized with story points to drive the subsequent sprints. The team then took their findings and started to design concepts and performed peer reviews to elicit additional feedback.
Design and Prototyping
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. Product Design Concepts are leveraged to gain immediate feedback on design direction and to validate and refine the user needs that were captured in previous sessions. The team reviewed the three Product Design Concepts with the user group for feedback and design direction. During this session, the project team discovered that the users preferred a mix of Product Design Concept 1 and Product Design Concept 3. The Product Design Concept 1 was updated in real-time to immediately confirm the feedback directly with the users. 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.
User Testing
With the developed application in hand, the team conducted two rounds of Usability Testing with each of the three users for feedback, refinement, and to ensure 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 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.
Conclusion and Lessons Learned
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 needs of the user, 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 things you don’t want to guess or assume. It’s vital that you 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 prior to 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.
About the Author:
Jason Moccia has over 20 years of experience in the software development field is the CEO of OneSpring LLC (www.onespring.net). OneSpring helps companies to work smarter by providing an entirely new approach to designing solutions.
