Data can be messy. When tamed properly, it elegantly meets every demand: it’s complex yet clear, objective yet definitive, accessible yet highly secure.
Too many tech companies are forcing product solutions into the market without first understanding if there is even a problem worth solving. Only the most innovative digital companies know that understanding the end-users’ pain points is superior to shipping more features devised in closed-room sessions. A Design Sprint is a 5-day framework for uncovering the most critical problems, then creating and testing a solution in real time.
eClinical Solutions (eCS), a leading provider of cloud based software and services for clinical research, are the architects of the elluminate® platform, used by over 40 life sciences companies to intelligently acquire, manage, and analyze clinical data.
elluminate is a powerful SaaS tool that helps life sciences companies manage and track the results of their clinical trials. Every single piece of data - blood pressure, heart rate, side effects, temperature, etc. is collected and analyzed in real time, while flagging potentially incorrect results to keep the data set squeaky clean. eCS provides both software and software-driven services to its life sciences clients and uses the elluminate platform on every client project to deliver high quality clinical data sets. The professional services team at eCS includes data managers and medical data monitors that use elluminate in the same way that end users do, providing a wealth of user feedback daily.
This feedback delivered a clear set of pain points. Existing data management processes were highly complex and cumbersome, and largely driven by massive spreadsheets populated with exorbitant amounts of information sourced from numerous systems requiring aggregation and constant review. The complexity made finding the right data time-consuming and frustrating.
Here we had the perfect backdrop for a Design Sprint - a clear set of problems, but a lack of alignment on what to prioritize and how precisely to ease the pain. The purpose of a Design Sprint is to define the single most critical user problem and to design a prototype solution to test with actual users. Our five day Design Sprint began on a sunny day in October.
Day 1 - Understand
Day 1 of the Design Sprint lays the foundation to fully explore the customer, the user, and their problems. After a thorough review of the existing product, industry, user research, and competitors, we dove into a series of activities to uncover the goals & anti-goals of the work ahead, riskiest assumptions, stakeholders, user journeys, and a clearly defined problem the team could all align around. These activities brought the entire product team together to fully understand and align on three key questions: Who is the customer? Who is the user? What problems do they face?
Sound pretty elementary to you? If you’re thinking, “that’s ridiculous, of course we know who our user is” - think again. In our experience facilitating countless Design Sprints (and writing a book on the topic), clients rarely enter the room perfectly aligned on who their customer/user is and what their most critical problems are. This groundwork is critical for aligning teams around a solution in future phases.
Day 1 Takeaways
The team focused on four key users of the clinical trial tool: Data Manager, Clinical Programer, Medical Monitor, and Clinical Operations. They outlined the users’ backgrounds, motivations, and current frustrations. Using these insights, the key problem facing users was identified: they were forced to use several different systems of record to access the data needed to complete their tasks and in doing so, were forced to jump back and forth between massive data sets on a scavenger hunt for the information required to solve their queries. This data hunt was time-consuming and frustrating, and the number one problem for all four user types.
eClinical knows their business and knows their users, so this revelation wasn’t new to them. It was only after the day’s activities that they realized how critical a problem this really was and were able to unanimously align themselves around the importance of solving it.
Day 2 - Diverge
With the hard “understand” work of day one complete, day two of the Design Sprint widens the lens to generate a whole host of possible solutions to the central “data hunt” problem defined on day one. The objective is to generate as many ideas as possible, and there are no wrong answers.
The key takeaway from day two was ideas.
Day 2 Takeaways
To set our minds in the right direction, we revisited assumptions from day one that related to the chosen problem, added new assumptions as needed, and then asked the team to prioritize the riskiest ones with a voting activity.
Once the team was aligned on where their biggest risks would likely be, we asked each participant to craft as many job stories as they could come up with. These are not feature requests, but statements that outline their users’ needs mapped directly to the motivations driving them and the users’ desired outcomes. Head to our blog for more information on this framework and why it’s so powerful.
With this strong foundation in place, we finally opened up the creativity flood gates and set the team to generating ideas. Lots of them. We started with an exercise called 6-ups that requires participants to visualize their ideas by drawing them out. Each idea is timeboxed to just 60 seconds and no words are allowed. This forced the eClinical team to think about the problem from a number of different perspectives in ways they’d never tried before. The result was a massive number of ideas. The team then voted out the bad ideas and used storyboards to expand on the best.
We ran through several rounds of this process to ensure there were enough ideas to achieve the right solution to our problem, not just any solution.
The key takeaway from day two was ideas. The team generated as many ideas as possible to solve key job stories and demonstrated them with storyboards, ultimately creating dozens of solutions to user needs; some viable, some not. But that’s ok, the diverge phase is all about getting outside of your comfort zone and thinking about problems from an entirely new angle.
Anything goes in day two, but that all changes on day three.
Day 3 - Converge
With a variety of possible solutions laid out before us, day three was about making tough choices and picking a direction that would allow the team to validate (or invalidate) their riskiest assumptions through prototyping and user testing. The focus was on having the right (and sometimes difficult) conversations about how to solve the “data hunt” problem in order to design an effective prototype solution. Day three was steeped in passionate debate, as it should be. Our rule of thumb for Converge is always,
“If everyone consistently agrees with everything, something is seriously wrong.”
Day 3 Takeaways
Using assumption tables, sketching, tough conversations, and ranking activities, one solution reigned supreme. The team believed a streamlined, unified workflow for scrubbing data was necessary, and that not only could eCS present just the necessary information dynamically, but users would actually be more comfortable with seeing less, albeit more valuable data.
Previously having to jump around for the information they seeked, users desperately needed a single place where data could be filtered in a dashboard view, pulling out only the most pertinent information for each user specifically. Ultimately, this new workflow could avoid hours wasted wading through irrelevant data. Solving this single problem could result in highly delighted users, and the team was absolutely itching to start building a prototype. Enter, day four.
Day 4 - Prototype
With three days worth of blood, sweat, and tears (okay, maybe just the latter two) spent uncovering the right problem and crafting the right solution, it was time to bring the solution to life with a prototype.
Prototypes are not perfectly polished products, they are an interactive digital sketch, and contain just enough polish to test the idea with real users outside the client team. Day four was spent designing interactive screens which brought a theoretical data management workflow to life. Cutting out the messy spreadsheets and superfluous data, the prototype screens surfaced only what eCS understood to be the most desired data for their target users.
Day 5 - Test
Now was the time for our prototype to spread its wings and be tested in the wild. Actual users were contacted in advance to arrange the user testing. Users were each asked a series of questions and encouraged to perform a range of tasks within the prototype, for example, “Can you show us how you might determine which data to clean first?”
The results were definitive. Users marveled at the simplicity of the tool, and the ease with which they could find the data they needed, ultimately making them exponentially more efficient in their work. One rough calculation estimated the tool could save one hour per day per user. The enthusiasm was truly humbling.
More work to be done.
The Design Sprint wrapped on a high note. In five days, working side by side with eCS, we transformed a painful set of problems into a simple, elegant solution capable of producing squeals of delight in real-life users. How could we possibly end our journey at this point? Thankfully, we didn’t.
The Design Sprint led directly into an eight week engagement to evolve the prototype into a true product through an iterative process of product strategy and prioritization, focused design, and user testing. Building on the key takeaways from testing and deeper discussions with subject matter experts, the team developed a more robust list of job stories, completing the experience conceptualized during the Design Sprint. With these design requirements in place, we moved into a rapid prototyping and testing cycle to smooth out the kinks in our designs and built solid confidence in the solution.
As the workflow became more defined, our team layered on efforts to complete the last phase of the design strategy, which was to create a design system that would serve as the foundation for a visual overhaul of their entire application. The team identified the unique components necessary to develop the design system while applying a level of visual polish to the screens. The user tested, fully designed workflow and visual design system (UI kit, coded style guide) we delivered allowed the client team to implement the changes necessary to banish the messy, cumbersome spreadsheets, and give life to the crisp, clean, data-illuminating interface