When Sprinting is Actually a Marathon

Selin Insel
MHCI 2018 AllScripts Capstone- HIT Squad
6 min readApr 9, 2018

Last week, Daphne documented our first brainstorming session of our first design sprint inspired by the Google Ventures Sprint book. This week’s post is about the details — how we did it, how it went, and what’s ahead.

The how, however, is only fueled by the why. If you haven’t been following us from the beginning, our team is trying to alleviate physician burnout from EMRs. EMRs are big and scary — and very complex, we’re sure you already know — because of complex billing structures and government incentives that drive physicians to often write EMRs in immense detail. The more doctors write, the more likely their EMR will get coded by ICD-10 standards, and the better off hospitals will be. Read between the lines and/or the semi-colon: $$$$. Problem is, doctors want to spend more time with their patients. But the issue start upstream. We found that with our client’s customers, and frankly, across EMR software providers in general, ill-defined workflows lead to cumbersome EMR interfaces.

Keep in mind, a “workflow” is how a hospital runs an aspect of the patient experience. How you and I experience healthcare is made up of multiple workflows, depending on how large the provider is. A workflow at a hospital for overnight stays (acute setting) versus a speciality clinic you visit for an hour (ambulatory setting) is vastly different.

This conclusion was our sprint’s Northstar. Sprints must be driven with a distinct purpose, if not, they’ll fall apart. Before we recall how our design sprints have gone, let us tell you how we view sprints.

What is a Sprint?

Google Ventures defines a sprint as a “five-day process for answering critical business questions through design, prototyping, and testing ideas with customers.” The writers provide a very granular roadmap for teams to generate solutions for a very specific problem. It’s a proven method for companies to research, ideate, design, build, and test all within 5 days.

The GV Sprint Roadmap

Why do a Sprint?

Having identified areas of exploration from our research phase, we had general stories of different design ideas that could address these needs. These ideas, however, were high-level and not deep enough to really flesh out a solution. The design phase is that time to go deep for a specific idea and GV’s sprint structure would enable us to do exactly that.

HIT Squad’s interpretation of GV’s Sprint

Designers are known to steal the best ideas. We did that with GV’s Sprint by taking the bits and pieces that were relevant to our stage of design. With classes happening in parallel to Capstone, GV’s structure was not feasible for our team. Instead, we created our own spin on the sprint plan that spanned two weeks instead of one.

Here is our version of the roadmap for the first sprint

Here’s the breakdown:

Friday — Define our “How Might We” question that we wanted to address during the sprint.

Saturday — Brainstorm ideas, sketch them out, and vote on the best one to begin building.

Monday — Look at analogous domains and other products.

Tuesday — Come up with the user-testing plan and polish the prototype.

Friday — Test with our target audience.

Sprint Saturday

How might we enable implementation consultants to effectively communicate their proposed workflow?

As mentioned in the intro, a lack of a unified vision leads to clunky workflows in the EMR. Workflows are defined when an EMR is implemented and shape how providers and health organizations operate. The stakeholders involved are often implementation consultants, chief medical officers, chief medical information officers, lead physicians and nurses, and other staff. An implementation consultant works across an entire hospital to understand, outline, and improve workflows. For the sake of our solution, we wanted to focus on improving how the implementation consultant would interface and collaborate with clinicians to get accurate workflows and identify opportunities for optimization.

Our biggest chunk happened on Saturday, March 24th. On Friday, the team had delineated an ambitious, granular plan that dictated what we would be doing every 5 minutes for the next 5 hours. Sounds crazy? It was. And 15 minutes in, we diverged from the original plan to reallocate time for activities we deemed useful.

The schedule that didn’t work out.

In essence, we started brainstorming general solutions that address our HMW question. We then grouped these ideas into buckets. From there, each person chose a bucket and ideated on a specific solution. We voted on our favorite idea across the team then broke for lunch. In the afternoon, we broke into a team of 2 and 3 to create wireframes of our imagined solution. Then, to conclude, we voted on a single wireframe.

Initial sketches. Fancy, huh?

On Monday, we looked at analogous domains that had similar solutions to what we prototyped. We looked at tools such as LucidChart for visualizing workflows, RedPen for giving and receiving feedback, Arena Simulation software for extracting insights and Github for versioning.

Using the insights we gathered from this exercise, we created a feature list for our prototype. At this point, Jia and Jeong Min took on the task of polishing the prototype. Daphne and I started creating a user testing plan. Ishaan created user stories which mapped to the features we wanted to include.

On Friday, we had our first user testing session with many the follow next week. The feedback we received helped us better understand what our target audience.

Was the sprint effective?

In short, yes! The structure helped our team focus on one task at a time to drill deeper in a way that we didn’t have the chance to before. It helped focus our efforts on one question to bring the the highest quality ideas to the table. And since our first sprint, we’ve done another!

So…you’re good?

The sketches and wireframes you see are concepts for “WorkVision,” a collaborative tool that enables implementation consultants to easily create diagrams and map them across other parts of the hospital or clinic. There’s room for this to pivot and we’re in the middle of user testing.

While conducting sprints are fun and exciting, and bring a new layer of focus to the team, it is also exhausting and the team is somewhat burnt out. We’re realizing that design is more than just capsulated design processes we call sprints. Design is a marathon: a tireless effort to put pen to paper and invent (or reinvent) something from nothing. As we’re working past our second sprint into our third, we’re hitting some roadblocks, realizing that getting stuck on one idea or one question too early in the process can backfire. Cue creativity boosting exercises.

Cheers,

Selin + daphne

--

--