Author Archive

Research, definition, and design of reports detailing insulin pump and glucose sensor-derived data to enhance the care of patients with Type I (insulin-dependent) diabetes.

Why it works

While visiting endocrinology practices and talking with endocrinologists, nurses, diabetes educators, and clinic staff, we learned that there is very little standard about diabetes care save three facts:

1. Practitioners have very little time to spend with their patients, so this time must not be taken up with paging through many pages of disorganized or out-of-context information,
2. the collection of data and generation of reports is rarely done by the primary practitioner, and
3. There are approximately thirty clinical questions that practitioners seek to answer about their patient’s recent health history and “glucose performance” that can be answered or investigation enhanced via device-derived treatment data.

It is these thirty or so questions that the above six reports answer. For the first time, glucose, carbohydrate, and insulin data from multiple treamtent devices (insulin pump, continuous glucose sensor, fingerstick blood glucose meters) are presented together, in context, showing patterns in a patient’s glucose response, areas where pump use or lifestyle changes are needed, and revealing the local history around adverse events.

What I’d change

We’ve crammed a lot of data into each report, prompting some warranted complaints about their complexity and density. Ever more fine-garined, complex, and feature-laden data is streaming from new and updated treatment devices, so this situation is not likely to improve. Instead, we must begin to bring patterns to the surface and name them so that the practitioner may verify the information and act upon it with a minimum of fuss.

Research, definition, and design of software collecting and reporting on insulin pump and glucose sensor-derived data to enhance the care of patients with Type I (insulin-dependent) diabetes.

Why it works

The typical endocrinologist has a very short visit with each patient, often fifteen minutes or less. Acquiring patient data from an insulin pump can take eight minutes, so this process needed to be delegated, reduced, or eliminated for accurate evidence-based health management to gain a foothold among all but the most high-end practices. CareLink Pro is the first software of its kind to allow device reads to be performed by the patient at home and be automatically synchronized with the endocrinologist’s patient database. In addition, in-office read times have been substantially reduced, and device management made much simpler. CareLink Pro remembers which devices (and which serial numbers) were used with a particular patient, which connectivity settings worked during the last visit, and which report parameters were used, eliminating the need to re-configure the software when a patient returns for a follow-up or routine visit.

What I’d change

While we’ve reduced technical decision-making surrounding associating a device with a patient and getting data out of it the first time, there are things we could do to nearly eliminate the work there altogether. Some poke-a-yoke (mistake-proofing) needs to be added to the patient profile to preven office staff from “recycling” patient profiles. And we have not yet succeeded in simplifying diabetes therapy, which will require machine interpretation of the data (much as is the standard of care in cardiology).

More from inside the application:

Definition and design of software demonstrating the usefulness of a continuous glucose sensor (to endocrinologists and their patients) by simulating the body’s response to food, exercise, and insulin via a mathematical model.

Why it works

The complexities of diabetes care are deliberately minimized to put the focus on three variables: food, exercise, and insulin, and their effect of blood sugar. In one experience, the user attempts to adjust basal insulin infusion rates, carb-to-insulin ratios, and dosage shape and timing to improve patient performance retrospectively. In the other, the user makes patient lifestyle choices (what and when to eat, when to check blood sugar, when to exercise, when to take insulin) and wrestles with high and low blood sugar as a result.

Ask me for a demonstration! You needn’t be an endocrinologist or a person with diabetes to enjoy a little demo.

What I’d change

The software was never intended for use on a touch screen, but fared well when pressed into service (at the American Diabetes Association national conventions in 2005, 2006, and 2007) save for the sliders used to control basal insulin infusion rates and carbohydrate/insulin ratios. The small slider handles are difficult to fat-finger. Dragging them is iffy on all but the slipperiest touch-sensitive surfaces. I’d like to further enhance the slider interaction by making the sliders’ values more apparent, either by including them in display areas above each slider or on the slider handles themselves. It can be tricky to quickly discern your setting when you are 3/4 of the way to the next graduation on a 3–23 unit scale with ticks every two units.

More from inside the application:

(pdf) Review of a problematic segment of an on-device interface for a major medical device manufacturer.

Why it works

This presentation was to embedded software engineers, so they needed a small amount of stage-setting: what should we attempt to accomplish in improving the interface? WHat changes will help, and how?

What I’d change

I could have focused more on removing user decision-making from the processes implied by the existing interface. Likely this would have resulted in even greater intelligibility and significant interface reduction. Even so, the difficulty of the proposed changes caused the engineering staff to stretch meaningfully.

Simulation of a medical-device for design-phase usability testing. (The ACT, ESC, up, and down buttons are active.)

Why it works

This HTML prototype allowed us to test terminology, information architecture, process flow, scrolling behavior, and other aspects of a medical device’s overall usability with actual patients in the target market. We overturned many myths about the usability of our existing products and terminology, and learned that several work flows were needed that didn’t previously exist. We also learned that it is possible to test both usability and the conceptual “rightness” of terminology at the same time, within some limits.

Top lessons:

• A “best practices” approach to workflow design is easily beaten by rapid prototyping and testing.
• The nuances of scrolling behavior have a huge impact on how “explorable” a list-based interface is, and therefore on adoption.
• People like some feedback, to know that the device heard them and is acting according to their wishes.
• Nobody understands “ACT” and “ESC” without some coaching, contrary to company belief. But if six of seven test subjects volunteer the same term, it is probably safe to use, contrary to company belief.
• It is important to pay attention to the “out of the box” experience, to help people get started with the device smoothly and quickly. Failure to do so endangers adoption success and customer good will, and increases support costs. Even so, new work in this area is likely to be a tough sell because “it’ll only be used once” and seems needless to the people who built the device (because they are so familiar with it).

What I’d change

The simulation could be more robust; not all of the functions available on the device are represented, most notably the ability to set and retain a value. We had to coach the test subjects to skip over these parts of the interface when they interrupted the tested tasks. And the one-page-per-screen structure of the simulation makes keeping track of the various screens and states somewhat worky; a JSON-based tree structure might make more sense in the future.

This simulation does not represent the full set of our recommendations. Unfortunately, not all that we learned made it into the final product, either.

Extranet definition, design, and implementation for a Mac-centric IT consulting firm.

Why it works

An information-first design that contrasts with the Mann Consulting website to give the feeling that it is separate and private, and that carries pertinent, prioritized information about their current and coming projects.

What I’d change

It would have been nice to link the projects to actions that the client might choose to take, such as contacting the consultant in charge, or leaving a note for same, or suggesting new projects.

Login pages (one from the mann.com site itself):

Site design and implementation for a Mac-centric IT consulting firm serving advertising and other creative firms in the San Francisco region.

Why it works

Minimal, “single sell” design grabs attention with a strong image and headline, with red accents supporting the brand colors. A random sell graphic and text are chosen from a stable of favorites on every visit to the page, each highlighting a different facet of the firm or customer testimonial. The design has stood the test of time; Mann Consulting has been happily using it, with minor modifications, since 2001.

What I’d change

The implementation of this design pre-dated the popularization of CSS and semantic HTML, and is therefore not as accessible as it should be.

Some other design directions that were considered (complete with provisional logo and watermarked images):

Flyer inviting business school students to participate in a competition aimed at recruiting.

Why it works

Clean and spare design uses a small amount of ornament and typographic variation to ease the stodginess.

What I’d change

The vertical axis established by “E-business case study challenge” isn’t taken advantage of by any of the type below it. The useful design principle that “everything must be aligned with something” is unfulfilled.

Design and development of marketing and informational site for an online time sheet service.

Why it works

A sell graphic leads directly into the sales funnel, while swappable promo units highlight new features or promotions to interest potential customers returning for a repeat visit. Standards-based code is easy to maintain and search-engine-friendly, leading to an uptick in already substantial search engine traffic and a corresponding bounce in sales.

What I’d like to change

A contract that included creating the promo units would have prevented the client from diluting their brand polish.

Prior versions of same:

Research, definition, and design of online app allowing people to find diabetes- and pump-related education in their area and sign up for same.

Why it works

This simple online app interfaces directly with the back-end that the sales force uses to rate and track sales leads. It automatically increases the search radius until at least ten events are found, if searching for all event types, or five events if looking for a specific event type. Location and timing data are displayed prominently in the categorized search results to allow users to quickly choose an event and sign up on the spot. This small app has led to a sharp uptick in sales opportunities and had a measurable effect on revenue in the first moth of its deployment. It is now an important part of the lead management process.

What I’d change

The app runs within the framework of the minimed.com website, so pay no attention to the man behind the curtain. It was also designed for four-to-seven event types; this list has ballooned to fifteen or more as the sales staff has embraced the tool. Redesign of the event-type picking mechanism is now needed.

More:

Research and design of intranet site gathering data and reports for consumption by senior management .

Why it works

Complex reports are presented with the most current numbers pulled directly from internal reporting and databases and presented in a clear, unambiguous manner. The look is distinct from segments of the intranet that are for general use to signal to the handful of habitual users that they are getting the real story.

What I’d change

More at-a-glance or interpretive highlighting could be used in key areas, especially when reviewing the performance of ever-smaller segments of the business.

More:

Two designs for an internal HTML newsletter.

Why it works

Straightforward designs incorporate branding elements (colors, fonts, etc.) while remaining fully accessible; there’s nothing fancy here.

What I’d change

As common as it is, it rarely works to design a vessel expecting to pour content into it later. Content first! This is the hardest thing for clients to accept.

Locale-selection and welcome structure (research, design, code) for online therapy management software for Hemophilia and Primary Inmmunodeficiency patients and their health care providers.

Why it works

A bold and unambiguous country selector that skips the politics of regional assignment (put Turkey in Europe? Middle East? Asia?) is immediately followed by a bilingual-capable welcome page.

What I’d like to change

It would be nice to separate language from country, essentially to offer service in any language in each of the supported countries. The language selection could come first. This would make full language support possible in places like Belgium, which could then enjoy quadrilingual support (German, French, Dutch, and English).