Imagine this. Six guys, five days, 1 concept, 22 webinar attendees. If I was to boil down the experience of my first multi-disciplinary design sprint into one word, that word would be “impressive”.
Back in 2012, I started working for a nonprofit organization for primary care physicians in Pennsylvania. The Pennsylvania Academy of Family Physicians was one of the best places to work at as an in-house creative professional. I was a designer, developer, social media manager, photographer, storyboard artist, videographer and the occasional IT specialist. All of my work though was focused through the lens of healthcare and it was the first time I felt that my abilities as a designer was being put to the greater social good. My passion for improving the healthcare industry took root deep within me. Once my eyes were opened to how insurance worked, hospital system workflows, changing technology in Health IT, government relations and how physicians fit into all of this while trying to provide the best possible care for patients lit a fire in me.
I read Johnathan Shariat’s post “How Bad UX Killed Jenny” and it gave me this almost crystal clear focus on what I could do as a designer working in healthcare. During my time at PAFP, I worked with physicians and technologists on how we can push for universal vernacular and design standards that we can push for future healthcare applications. Even after I left PAFP and continued my career in the agency side of the industry, I kept that passion for improving healthcare. Since PAFP, I have worked at three different places before settling into the venture capital realm…and now have come full circle being able to work on healthcare projects with our ventures.
About two months back, I got recruited into a design sprint to create a basic, working concept of predictive blood glucose app that would help inform type 1 diabetics when they tend to go out of range with their blood sugar. The team was comprised of myself (designer/front-end developer), a software engineer, a data scientist, a health IT implementer who happened to be a type 1 diabetic, a copywriter and our core-tech team developer intern. The mission: create an MVP of predictive blood glucose app that would inform a type 1 diabetic of when they tend to go out of range based on data from their CGM and finger stick data from sources like Apple’s HealthKit or Google Fit. We organized our design sprint by following Google Venture’s Design Sprint model.
While I can’t talk too much about the technology we baked into the backend works or how it overall would works based individuals input, it’s main goal is help create behavioral changes for type 1 diabetics through data visualization that would allow them to have a greater hand in making decisions that can potentially be lifesaving. The Google Ventures Design Sprint method was the catalyst that allowed us to go from an idea to prototype inside of five days. Here are the basics of this sprint method.
1) Set The stage. You’ll need someone who is the proctor and keeps the team on track each hour, each day, gets the necessary supplies, helps set the expectations and the rules of the sprint (example: no phones or computer until build day). The five big things for this part is to choose a big challenge (and suspend disbelief), recruit the team, block five full days on the calendar, have a space with at least to large whiteboard (and in our case, additional big ass post-it note tablets), and getting the necessary supplies (beyond paper, pens and post it notes…things like snacks, coffee, water, etc). For the next five days, it will be the proctor and the team in a quiet room all by ourselves.
2) Monday – Day 1: Setting up the expectations and agreeing on a long-term goal. This is the day we can ask the subject matter experts and build enough information to begin our research and map out our challenge. We pick an actionable target, as group, that we are going to shoot for.
3) Tuesday – Day 2: This is when we begin to focus on our solutions and begin to improve upon our ideas from the previous day. We all sketch ideas and concepts that emphasize critical thinking. Also, this is when we begin to sketch out what our Friday’s live test audience is going to look like. Choosing an audience from several different key metrics is vital. We opted for a webinar.
4) Wednesday – Day 3: Now that we have a big old stack of solutions, now is the time to pair down and critique each solution to find the idea with the best chance of meeting our long term goal. This where the brainstorming has ended and the development of one idea is worked through. By the end of the day, we will have worked out a storyboard to show step by step our solution.
5) Thursday – Day 4: Build Day…this is when the team builds a prototype, a model that we can test with our chosen audience. This doesn’t need to be a masterpiece and it’s not meant to. It’s meant to be a realistic fake that gives the audience the appearance of something that could exist in the real world. By the end of this day, we’ve wrapped up our build process, reviewed it and made sure it’s ready and write the interview script for our audience test. In our case, we tried to build as much production level code as possible. Using some of our own in-house tech, the Ionic Framework and a lot custom design elements and SCSS, we were able to create a realistic prototype that actually was pulling in some real data from a colleague’s own data.
6) Friday – Day 5: Interview day. This day was filled with early morning UI tweaks (due to my just learning how Ionic works the day before), any final copy edits to the script and everyone diving into hearing the interview responses. The goal of today was to let us know if the app is going to be a no or no-go. We launched the webinar and had our CMO read the script and proctor the webinar as we sat back and took notes and recorded feedback from the live polling. This part of the process taught us a lot about our findings, methods and ideas and pitted them against what users would like and use in the real world. By the end of the day, we had an incredible amount of data and feedback that we’ll use to pitch at a later date whether or no to continue development or shift gears.
By the end of the sprint and hearing the feedback from the audience, I was full of zeal in feeling that I worked on a project that has the potential to make a meaningful impact in the lives those with type 1 diabetes. The design sprint process itself helped us organize and pull from each others strengths to be able to create the prototype we could all back and say answered our challenge and target.
More and more healthcare startups are taking design and iteration as part of their core business strength. The more that this process of the design sprint is adopted, I feel, will lead to the creation of better healthcare software and workflows that will truly aid healthcare professionals in providing better patient care.