Bionic Pancreas User Interface (3/4) : Interface details

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 iLetTM, 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.