Now that Blip and the Tidepool Uploader are available, we’ve been learning a lot about how people use them to gain insights into their diabetes. We feel strongly about incorporating people with diabetes and their caregivers voices into our design and development process and want to share with you what we’ve been up to.
The bottom line is that Blip needs CGM in the trends view, and we have a massive opportunity to show more trends between pump, BGM and CGM data in one place. So we took a step back with design and looked broadly at how we could provide better insights for people by integrating the various kinds of data (pump, cgm, bgm and notes).
I’m going to try to be brief and share our process in a way that exposes the insights we found, how we got there, and our plan is for implementing them. We always want your feedback, so don’t hesitate!
We asked a group of people who use pumps and CGM’s to come into our office for a 1.5 hour brainstorming session. Drew Stock and I prepared materials and structure for the brainstorm the few days prior. We listed our questions, assumptions and identified the biggest gaps in our own minds about how to design for better trends in d-data. We used this plan for the time and gave out this sheet to welcome people and set their expectations. The goal of this session was to ideate (create lots of ideas).
From this brainstorm session themes emerged, we boiled down the themes into a few key insights…
- Automation is hard. While it makes things easier in some cases, to do it well, we need to dedicate more resources than we have. To do it badly is not worth the risk. I’ll give an example of a case of over automation. Facebook, with one of the largest and well endowed design and development teams, designed this experience, which you may have seen the output of, that summarizes our year in review. When the new year comes around and my friend, whose father had died in February of 2015, gets a glaring and totally out of tune post on her home feed, her father’s face underneath a caption of “Happy 2016! You’ve had an amazing year!”. I just don’t think that kind of error can happen with diabetes data.
In the brainstorm we prompted ourselves with the question, “If Blip was an instruction manual, what would it be like?” This part of the brainstorm was super valuable, it helped us understand what voice Blip should have and got us to understand how much automation we would be able to do well. It helped us define what we can expect from Blip.
The “IKEA version,” while being extremely clear to follow, is too simplistic and linear – diabetes data and spotting trends varies much more. The “Old School diagram” is sure and authoritative and it defines what there is without room for interpretation. The “Go it alone Reference Docs” are totally flexible but leave people who aren’t deeply engaged lost in a sea of information. And the “Summary Report” is personal and informational, but requires automated grouping of events and trends identification. We concluded that Blip should show us our data clearly and nudge us towards finding trends so that we can act upon them. Automating analysis would be awesome if we could do it well, but right now we don’t have the bandwidth.
3. Prototype and get feedback
So now that we have all these ideas, and things to guide us, we have to build prototypes, test them out, and see what works and what doesn’t. We used a tool called Framer that would allow us to build interactive prototypes, with real data. Here is one of the prototypes if you’d like to click around, just be aware that it’s not fully functional – try switching between the stacked and layered, mouse over a detail day of CGM on layered view and expand the top rows on the stacked view. We also mocked up an idea for trends within the device settings page.
We took our prototype and asked 3 individuals (one clinician, one mother of a teen and one adult with T1D) as well as the pediatric team at Stanford for feedback. The goal of these sessions was to help us get a sense of where different types of users would want to start, what aspects they found most valuable, least valuable and if they had ideas of things that we hadn’t considered.
4. Take-aways and iteration
- Pattern recognition/automation is hard. Defining rules opens up can of worms and desire to customize. If we set rules, how do we know the right rules? We must be thoughtful with expectations of what software can/should deliver and automate and dedicate significant resources to making sure automation of events would be meaningful and not misleading. From this we decided that to do automation well, would require more resources than we have right now.
- Grouping events is wanted by all parties – the idea of albums, like in a photo app, or soccer practice days, holidays, menstrual cycle days all came up.
- The clinicians we spoke with were more confident in their own ability to do analysis on the data. They leaned more towards detail info while PWD’s were more interested in overall. The mother we talked with said, “tell me things i want to know so i can get on with my day.”
- Anomalies in data (like bad infusion site) are not useful for seeing a trend in data and clinicians were not interested in them. While PWD’s were more interested in them because they saw that as something they could do something about next time.
5. Plan for implementation
Our team is still small, so we must do one thing at a time and get things out the door. The prototype we built helped us form a vision for where we might want to go with Blip in the future, but for now we must choose the most valuable parts that will be feasible to implement quickly. First things first, we’ll add CGM data to Blip’s trends view. In order to do that and still have it be performant, we have to restructure the code that is currently running trends view. This will enable us to re-implement a more consistent date navigation that will eventually be across all the views (basics, daily, weekly and device settings). We will transition to this over time and it will lead to a consistent date navigation, more accessible colors and contrast as well as become fully responsive (being responsive means that Blip will become more readable on bigger screens or projections as well as on tablets). Below is a mockup of what we will implement first, however the colors are still up for debate.
All of Tidepool’s UI designs are made available freely under a Creative Commons License: Tidepool User Interface Designs by Tidepool Project are licensed under a Creative Commons Attribution 4.0 International License.
That basically means you can do whatever you want with these designs and this content as long as you attribute your work to Tidepool.