Improving Healthgrades’ Survey Audit Process
// Design Sprint
Overview
What is a Design Sprint & why did we use it for this project?
My squad at Healthgrades was tasked with creating a consolidated solution for a set of internal customers that were using multiple tools in their daily workflow to audit patient surveys.
I took this as an opportunity to champion and implement Google Venture’s Design Sprint process in order to expedite our solution as well as expose my team to a different approach that they weren’t used to in order to solve problems.
We embarked on this five day journey and came out the other end with enough tools, knowledge and momentum to complete the project before our deadline. We were also able to put ourselves in the best possible position to scale our product efficiently.
Developed at Google Ventures, the design sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers.
Role
Product Designer
Duration
One week in November, 2017
Squad
1 Product Manager
1 Engineering Manager
2 Full-Stack Developers
3 Engineers
1 Data Scientist
Day 1: Monday
Longterm goal
Monday’s structured discussions created a path for our sprint week. In the morning, we agreed to a long-term goal: To unify & enhance survey audit processes.
Map making
Next, we made a map of the challenge. In the afternoon, we ask the experts at Healthgrades to share what they know with us.
Picking a target
Finally, we picked an ambitious but, manageable piece of the overall problem that we think we can solve in a week. We select as our target: To consolidate survey investigation tools for our primary stakeholders.
Day 2: Tuesday
Lightning demos
After a full day of understanding the problem and choosing a target for our sprint, on Tuesday, we got to focus on solutions. The day starts with an inspirational review of existing ideas to remix and improve.
4-step sketches
Then, in the afternoon, each person sketched out a 4-step process that emphasizes critical thinking over artistry.
Recruiting customers
We also began planning Friday’s customer test by recruiting customers that fit our target profile.
Day 3: Wednesday
Sticky decision
By Wednesday morning, we had a stack of solutions. That’s great but, it’s also a problem. We can’t prototype and test them all - we needed to come up with one solid plan.
Rumble
In the morning, we critiqued each solution and decided which ones have the best chance of achieving our long-term goal.
Storyboarding
Then, in the afternoon, we took the winning scenes from our sketches and wove them into a storyboard so we could better come up with a step-by-step plan for our prototype.
Day 4: Thursday
Building a prototype
On Thursday, we adopted a “fake it” philosophy to turn our storyboard into a functioning prototype.
A realistic facade is all we needed to test with customers and, here’s the best part, by focusing on the customer-facing surface of our product/service, we can finish our prototype in just one day.
We also made sure everything was ready for Friday’s test by confirming the schedule, reviewing the prototype and writing an interview script.
Day 5: Friday
User testing our work
Our sprint began with a big challenge, an excellent team and not much else. By Friday, we had created promising solutions, chosen the best and built a realistic prototype.
That alone would make for an impressively productive week but, we took it one step further as we interviewed customers in order to learn by watching them react to our prototype.
This test makes the entire sprint worthwhile. At the end of the day we, as a team, knew how far we had to go and just what to deliver next.
Outcomes
Improved alignment
This design sprint allowed our team to achieve a much more streamlined level of alignment we had not previously experienced before. The intimate setting and fast-paced atmosphere allowed us to have an unfiltered view of the problem as well as revealing how best to work with one another on a tight deadline.
Hyper-productive momentum
Having moved much more quickly through the project’s requirements in this environment allowed us to keep that same momentum into the next week which allowed us to hit the ground running on the following Monday.
Scalable roadmap
Having a better understanding of the new moving parts we developed in that short week allowed us to develop a shorthand that helped us to quickly and efficiently pivot & move our work around to much more easily accommodate critical changes to our existing roadmap.