Bionic Pancreas User Interface: A Design Process in 4 Parts

Part 1: Kickoff

July 13, 2015

The plane, the train, the car, and now what? Insulin pumps?! Yes! Finally? What do these things have in common? They are becoming increasingly automated. A few of us at Tidepool have spent the last 4 months designing the interface of the iLet™, Boston University's Bionic Pancreas (BP) device created by Ed Damiano and Firas El-Khatib. My hope is by sharing the process and learnings we have had, that your devices, understandings and designs can benefit. Please share, use, and iterate on it all.

This is the first of four posts on the design process of the iLet that we went through. The posts will cover...

1) Kick off and goals
2) Mental models and user research
3) Details from the interface
4) FAQ (or what I think your FAQ will be)

If you have diabetes, I'm sure you come across this too, but most people assume that the CGMs and pumps are connected; well of course the pump is responding to the CGM value, right? Well, no, not yet. And on one level it's an incredibly simple problem when it is hypothetical; - sugar goes up - give insulin, sugar goes down - give sugar. And on another level, getting a system like this in place in the real world, when you get down to the nitty gritty of it all, is pretty complicated. The margin of error is so so tiny, the variables are many, the risk is high, the consequences are severe, the resources are slim, the pace is slow, there are patents to avoid, there is red tape to get around and the regulations are serious (for good reason). All of these things become real barriers for good design and fast iteration of medical devices, but we are pushing the boundaries as best as we can, and things are moving and improving in meaningful ways. I'd like to share our process because part of what is so slow about the development of these devices is the closed-ness of processes and learning. We started the project with a kick off meeting in person in Boston with the two documents below.

Big Questions

We put our biggest questions down on stickies, brainstormed through them and then had a time boxed discussion for each one.

(How can we help people using the BP take care of it through using relatable measurements? How might we build trust through communicating device status to people? What are good BP habits and how can we encourage them? What things aren't supposed to happen but will happen anyways? What models or framework for alerts do we want to implement? What do we believe safety means? What happens when the CGM is not connected? What hardware are we designing for (speakers, vibration, screen)?

Feature mapping

We put every action and element on a sticky and talked through the backend of it, the limitations, behaviors, and needs and then had time-boxed discussions for each one. This helped us make a complete map of the features that we were working with.

(Phone connection, alerts, BG entry, carb entry, target, system settings, first experience, CGM, G-burst, hormone [cartridge] replacement, basics controls, stats, weight entry, current status)

Design tenets

What will guide our decisions?

• Be reliable and transparent, show cause and effect.
• Communicate respectfully - people with diabetes are smart, they are experts in their own care.
• Simplify and take away as much interaction as possible.
• Design for safety. Safety means - intentional entry, customizable alarms, education and transparency.

Control and collaboration!

How much control does the person using the bionic pancreas have? How does the relationship we have with current insulin pumps shift with the bionic pancreas? Control is a pretty big issue - for blood sugars, exercise, food, and insulin dosing. Pre-BPers have spent their diabetes years trying to have as much control as possible, to imagine relinquishing all of it to algorithm, or a system of many connected parts, can be terrifying. Some responsibilities will be passed off to the device and some will still be on the BPer. The relationship with the bionic pancreas will be a back and forth, give and take. Together, things will be easier.

Humans are good at living, and through the intimate journey with food and insulin, people with diabetes develop an innate sense of what those things do and how they make you feel. This extra sense and understanding is valuable day to day, in relationships, in work and in the world in general. The other thing that is uniquely human is that we are unpredictable and we change and grow. We also know when we are going to exercise or if it is Thanksgiving and we will be sitting and eating all day. These things we need to tell the iLet™, it can't know without our help. It is however, SO good at monotonously checking, correcting, estimating, and adjusting. It is good at repetition and being meticulous.

The interaction with the iLet™ is not about passing off everything. It is about collaborating in the management of blood sugar levels. And the better I take care of it, the better it will take care of me. The mental model for the relationship as a collaboration guided our design decisions. What could we do in the interface to nudge people to do 'good' things for the device? And what repetitive tasks can the device do for the person in return?

We started with two kinds of goals for the design of the user interface...

Functional goals : What does it do?

• Tells person if device needs help
• Tells person if device is working
• Tells person how body is doing
• Lets person influence and inform device and therapy

Experience goals : How does it feel?

• Safe / effective
• Trustworthy
• Not intrusive / considerate
• Honest / transparent
• Liberating / control
• Easy to use / simple / basic
• Enabling / independent
• Regular / everyday

While it's easy to go straight into feature details, limitations, worst and best case scenarios - it is so important to all agree on guiding principles and goals. It sets a foundation for the whole team to align on a design direction from the beginning. This part is what guides decision making the rest of the way. The next post will be on our User Research process and understanding mental models.

Part 2: Mental models and user research

July 16, 2015

In order to wrap our head around how managing diabetes today with current insulin pumps will change with the bionic pancreas, we had to understand the experience. Our first question was Can we try it? An inherent challenge for good design of medical device: we can't try it. Clinical trials have specific protocols, and we did not meet them. The closest we could get was to talk with people who had been in the trial. To begin, we did 5 interviews with people who had worn the current prototype of the bionic pancreas for one week.

Our questions going into the interviews...

• How did it feel? How was your week?
• What was it like to get started? Was there anything you wish you were told before using the system?
• If you could talk to someone who was just starting, what would you tell them?
• What was most exciting?
• What was the biggest change?
• What was useful in the device interface?
• What did you get from looking at the main screen?
• Did you feel safe?
• Did you trust the system? What made you trust it? Did it ever do anything that you didn't like?
• How did you think about carbs at the end of the week? Did you still think in size or were the amounts relative to each other?
• Did you worry about anything? What?

We put all the features we could think of on cards and asked our interviewees to sort them. This exercise helped us understand how people's mental models were different with the BP than current pump therapy. We also brought paper prototypes of the interface to explore a specific interactions; disconnected CGM, Carb entry, and target adjustments).

A few things we learned...

1. The device learns, have patience.

"I trusted it, after I learned it. I would say [to someone just starting] that every time you have a first, it's not going to do well, but after that…[sigh of relief]"

2. Carb entry is about where in your day are you, not what time is it or what meal is it.

3. Need to know becomes nice to know.

"Again, because it's a machine, it's doing all these things for you - you don't have to know all of that stuff - it's neat to see, but you don't have to know that. It's way cooler when you're trying to explain to someone what's going on. The interesting stuff becomes adjustments and actions… readings and other info become less interesting."

We asked the people we talked to to organize the cards based on most important. Each person started with how it is now, and placed the data related cards in the most important group. When they thought about using the BP, the data cards moved over the not as important information. This understanding of need to know (with current therapy) → nice to know (with the BP) influenced how we designed the overall architecture which you will see the impact of in the following post.

Today, pre-BP, the main concern with diabetes is How am I doing? This question has three possible outcomes... 1. If BG is in range, do nothing 2. If BG is high, give insulin 3. If BG is low, eat sugar. It was really hard to embody, and still is foreign to me, that this question will stop being the primary one. What we heard, and what I came around to feeling is that with this device the main concern will lean more towards, How is the device doing? Does it have everything it needs? The majority of the time, if you are taking care of the device the answer to the "How am I doing?" question will be, You are good, the device is keeping or bringing your BG in range.

When you're starting out, using physical prototypes and prompts is an incredibly rich way of understanding what you are designing. We also did usability testing at the end of the process when we had a working prototype of the full interface, this let us see if the text was big enough to read, if the wording made sense, what questions the interface prompted and basic stuff like 'is this button big enough to touch and is it clear that it is being touched'. User research is all the rage these days because when you do it well, the feedback is invaluable. In the next post we will go into details about the decisions we made for the interface.

Part 3: Interface details

July 20, 2015

In this post we will go into details of the decisions we made about individual screens and interactions.

The main screen

Should it be map or a path? (see Bill Verplank). A map shows the ins and outs; you can get a sense of where you are in relation to everything else that might affect you. A path gives you step by step; it is easy and requires little thought. Because of how many variables there are, because it is a collaboration, and because people with diabetes are smart, they are experts in their own. We chose a layered architecture. The sketch below shows how the interactions go from simple and immediately accessible / glance-able to the bottom features which are buried further into the interface.

We organized the interface architecture by these three main questions...

Safety

What does safety mean for the design of the BP interface and behavior?

Design to prevent alarm and interaction fatigue: Alarms only when needed. Every interaction that is asked of the person using the device should be intentional and necessary. Over use of alerts, confirmations, and alarms make them less effective. By asking the person to do less, we think we'll actually get more explicit and directed attention to the entry. In the entry flow of anything that will directly deliver insulin or glucagon (G burst, Carb Entry, or BG entry), there is a "preparing" screen. The preparing screen gives an extra moment to cancel the delivery before it begins. It's a moment of pause and reflection to offer a time for cancellation.

Confirm screens are perceived safety, instead, provide the ability to change your mind and undo. Confirmation screens are a really interesting piece of this conversation. Their intent is to make sure the user is sure of the information they just entered, but in actual use the entry occurs so often and the confirmation becomes a completely routine part of the entry that is rarely considered. Confirmation screens train you to press ok-ok-ok without actually double checking the information you have entered. The next question is, well, if a confirmation doesn't help, what would?

Provide feedback in context. A good example of this tenet impacting the design are the icons that represent levels of the critical pieces of the iLet. We designed them to be glance-able, to give you allow yourself to effortlessly see if the device is okay. Originally it was on the home screen but once we started

Design for intentional entry. Another thing to keep in mind about how this carb entry is different than current bolusing for carbs is that the impact is lower here - the delivery amount cannot be exorbitantly high because the calculation is being done by the device anyways and the BP is continuously checking and correcting, so if large is entered instead of small or vice versa, the device will correct the mistake.

Lock screen

The purpose of the lock screen is to prevent accidental button/screen presses that influence therapy. We made a list of the different features, how many presses you need to have an impact and how severe the impact would be if entry went through. With the interactions that have a more severe impact we added the ability to undo the entry.

Alarms

Alarm fatigue is real. I don't wake up to my Dexcom in the middle of the night because the sound is so common. We tried to come up with a system of communication that escalates necessarily and that the person can have some personalization. We separated the communication in the following 4 levels. Sounds and custom time periods would be ideal for combating alarm fatigue, and hopefully will come in version 2. We designed for that possibility.

1. All is fine - Do nothing.
2. Notification - Needs no acknowledgment, will go away after sufficient time period. e.g., low insulin.
3. Alert - Needs acknowledgment. Can be snoozed but will return if reason is not met. These can be set and turned off if desired. e.g., very low insulin.
4. Alarm - Needs action and cannot be snoozed. User cannot turn these off. System will not continue to function until action has been taken. e.g., empty insulin.

Carb entry

This was a really interesting piece. I don't know if what we designed is right. I think it needs more testing to really see how it works. For now it accomplishes what we need, and hopefully is intuitive enough for people to understand on first use.

It was a tricky balance of how much and how we should communicate the reasoning behind the questions asked which were...

1. Where in your day are you?
2. Relative to this time of day, how many carbs are you having?

In the first version of the BP, there were three choices for your carb entry - is it Breakfast / Lunch / Dinner? This simplified option erked us, bringing up a long standing frustration with log books that demand we eat in regular intervals. What about everything in between? What about brunch? What is this question really getting at? Why do you need to know Mr. Bionic Pancreas? We went and asked questions to people who had tried the previous version, did hallway tests and then compiled our insights to come the design we have now.

For the iLet™, it is about your body's cycle and metabolism, not what time of day it is or what meal you're eating (if it's a meal at all). We came to the circle/cycle visual and organized the selections not similar to a clock. If it was similar to a clock, it prompts the question - why do you (device) need to know what time it is... don't you know? Leading us back to needing to emphasize that this question is about your body time, not about the clock time. The algorithm learns through your responses. It learns how sensitive you are to insulin and for how much carbohydrates.

I do still have the lingering question about how well the system will do for my typical thanksgiving dinner ;) But I think the nuances of this entry and delivery will only be understood after it's up and running with a diverse spectrum of people.

Number entries.

Keypads or up down buttons or a scroll wheel? There are a few places one needs to enter a number or adjust one. The BG entry, weight entry, date and time and pairing the phone and Dexcom transmitter. Keypads are easier and unassuming. You can get directly to the number you wish to enter without chancing a stop on one you're scrolling past. The keypad is a more intentional entry than a scroll wheel or an up–down button. We designed the interface for an eInk screen (we will go into this decision in the next post) and refresh rates are slow, so a scroll wheel wouldn't be great. It would leave ghosting in the area you need to read. Keypads take up a lot of real estate, and if you're adjusting a number, like weight, it's not going to be so far from the current number. With an up–down button for weight adjustment, we get to keep the information in context without needing a new screen for the entry. But for the BG entry, the number entry is the main action and is different every time, the keypad is the better option for this entry.

If anything, the overarching take away from this post is that perfect is the enemy of done and good simple doesn't come from simple. Pushing designs out and seeing how it works in real use is really the only way to make it better, constraints are really important. And simple doesn't come from simple, it comes from complicated, and the art of good design is choosing what to take out. The next and last post will be a series of FAQ. And if you've got questions, send them our way and we will do our best to address them.

Part 4: FAQ

July 24, 2015

Why black and white?

We chose to use an eInk display for this first version of the BP. And yes, eInk screens are at their best with black and white (for now, there is color but its just not as nice yet). This may come as a surprise but we chose this display technology for its technical advantages, its look and feel, and its ease of use. eInk displays are super thin and use very low power. If the battery or device dies, the screen can leave a support message with dosage suggestions and a support phone #. They are incredibly readable in the sun, and will be quietly front lit in the dark. In terms of its design character, the device is a tool. It should be reliable, trustworthy, intentional, simple to use, and light of heart. To have used an OLED screen would have demanded bells and whistles, animations, transitions, etc. OLED screens are hard to see in the light and shine disruptively in the dark. We did not want to use device power on bells and whistles. A little story about power consumption...I was at a party in college, with friends, having a blast, I needed to test my BG (before my sensor days) and the cool new meter I had (iBGstar) was turning on and giving me an animated version of their logo and then displayed "not enough power to test BG". This was infuriating - I know the power used to do that stupid colorful animation (which already is pretty annoying to start with when all you want to do is test your BG), would have been enough to let me test.

How did you prototype the designs for an eInk screen?

We used the Yota phone and built a web app that could be viewed in the eInk screen. This was much much faster than writing our own prototyping toolkit. It allowed us to test interactions, responsiveness, contrast and refresh rates. It was critical to be able to see and interact with what we were building. It was also really cool to interact with and see how it shifts expectations and experience of using a not light emitting display. It feels more sturdy, more robust, I trust it.

Why so big?

The size is mainly because there are patents protecting motors and drive train. A risk not worth taking, a lawsuit from anyone about motor design and implementation would kill the project. It is also a first version and it will get smaller, but for now the main goal and focus is integration of all the aspects and commercialization. The design was driven by the size of the screen, not the other way around.

Why batteries?

The choice for using AA batteries in this version was primarily to mitigate extra risk. The less pieces of the system that are dependent on an external supplier, and that aren't off-the-shelf, the less risk. I do however feel mixed between the benefits of a rechargeable BP and a battery operated one - both have pros and cons, and batteries might be better for some people and rechargeable might be better for others. If i'm traveling, and not sure when and where my next stop will be that has an outlet, if I lose my cord, if the rechargeable battery capacity dwindles, are all reasons why I would like a battery over a rechargeable one. One of the last rounds of user research I spoke to someone who said that everything in her life was rechargeable, Dexcom, Phone, Computer etc - why should her pump be different? And I get that, for some people, recharging is easy, dependable and cheaper. This is why diversity of options in important, and I hope that when smart pumps come to the market, there are multiple options for people to choose which works better for them and their lifestyle.

Everything is in lowercase letters! Hmm?

This choice was about the character of the device, and its approachability. Lower case letters are less demanding, less assuming, and less pejorative than upper case letters. Lower case speaks to the intended character of the device by being unassuming, communicative and calm.

Can I see/use anything/everything?

YES! Please do! The design files are here and the prototype is here.

Who was the team?

Having a team with complimentary skills is so important, and to be able to be focused and communicate well is almost more important than the skills you have. With a team of highly motivated, opinionated and smart people, the risk of bike shedding is high but the right balance of personalities can really help to avoid it. Ed Damiano and Firas El-Khatib did an amazing job of communicating the functionality and needs of the device as well as making final decisions. Ian Jorgensen worked on prototyping and understanding the technical specifications for the screens we were working with. My focus was making sure we were on track with our design process/project management as well as conducting the user research and UX. Howard Look helped to guide our process and make sure everything we were scheming about was feasible and not out of scope. Raj Setty (Ed and Fira's assistant) made sure we had all the things we needed and is helping to get the designs implemented well. Yoann Resmond helped to get the graphics and icons perfect. And then a handle of amazing people gave us ongoing feedback that helped shape the design.