UX vs. UI for a Medical App

Universal Health CareUI is not UX

UX professionals make a big deal about the difference between UI and UX. There are dozens of articles on the web about how UI is not UX, and apparently I have made the mistake of reading most of them—hoping to learn something insightful. Instead, these articles usually rattle off a pile of platitudes that I find meaningless in practice. I have been disappointed every time. Click here if you need help finding these articles.

The practical importance of this distinction escapes me. For example, is designing good performance UI or UX? The best answer: it doesn’t matter! Everybody should be designing for great performance, so why exclude it?

Of course, there is a difference. My definitions are that the UI is what users see and hear on the device and how they interact with it, whereas UX is that plus everything else the product touches—from the purchasing, out of box, configuration, daily usage patterns, and support experiences, to experiences that don’t even involve interaction (such defaults or automatic behaviors). Fortunately, my definitions match Don Norman’s, who is credited with coining the term UX.

But it doesn’t matter much in practice

Frankly, most “UX” discussions I witness are really UI discussions. They involve sketching what could be on the screen and how users might interact with it. The obvious clue: the process and discussions are centered around sketching features. Technically, that’s UI design, not UX. But since the practical distinction hardly matters, I never bother pointing it out.

I do many onsite workshops to help software development teams learn UX design or improve their design skills. I had one team lead request that I teach UI design to half his team and UX design to the other half. How does that make sense? How do you make the distinction? What is appropriate to exclude from UI design because it is really UX design? This left me baffled. Training wise, UI is UX. The distinction hardly matters.

UX for a Medical App

The reason I’m thinking about this now is that I just had a two-hour design session with a team designing a medical mobile app and it was 100% focused on UX—no features or UI elements discussed or any sketches made. This is unusual—at least for me—as UI design invariable shows up at some point.

So what did we talk about for two hours? Here is an outline of the topics (while keeping the details sufficiently vague):

  • The target users (elderly Canadians), the different user classes/personas, what they want, and what we could expect them to know and do.
  • The value the app needs to deliver to these users to motivate them to use it. (And more importantly, the understanding that if there wasn’t clear value, they wouldn’t bother to use it.)
  • The different medical problems the target users might have, the medications they are taking, their packaging, and the implications for the app. How do users recognize their meds—by shape, color?
  • The type of mobile devices, and how a tablet is used differently than a phone, and how a specialized tablet (just for this app) is used differently than a general device (like an iPad).
  • How the device and app would be initially configured. How it will be reconfigured later, whether it’s realistic to expect users to bring in their device, do the reconfiguration themselves, or do it over the internet. And if over the internet, what will that connectivity look like? Can we safely assume the users have Wi-Fi? (Answer: no.)
  • Where the device and medicine should be in the customer’s house and whether it’s realistic for them to be in different places. (Answer: it isn’t.)
  • How the device will be recharged or if it should be plugged in all the time. Realizing that the burden of recharging alone could be a deal breaker for many users. (I noted that for a specialized device, it’s better to leave the device plugged in because users will quickly get tired of having to recharge it and they won’t need to move it.)
  • What we could do to make the task as simple as possible, eliminating as many steps as possible. Can we completely eliminate any typing? (Answer: yes.)
  • What it would take to encourage people to use this device long term (over a period of years). How could we encourage them to restart after a long break (such as a vacation)?
  • The steps in the happy path, and what normal usage should look like. What happens when users get off the happy path and how to get them back on.
  • How to deal with traveling, going on vacation.
  • The visual, audio, touch requirements for an elderly audience that might have significant visual, hearing, and manual impairments…while still being suitable for someone without those impairments.
  • What needs to be configured by the user, and how to make such configurations simple and contextual. Should we assume English or Metric by default? (Answer: English—Canada converted to the metric system in 1971.)
  • How to make the results trustworthy so that users will actually follow the advice of the app, instead of ignoring any problems found.
  • How to phrase problems and carefully phrase the reasons behind them so that people will be motivated to follow the app’s advice. (Plus, realizing that stating the reason is more motivating.) We shouldn’t expect people to do something medically just because an app says so. Ways in which we could use A/B testing to validate the phrasing.
  • How to give reminders that are encouraging, not intrusive or annoying. How to deal with awkward social situations.
  • How to “authenticate” the user as easily as possible. How to make sure the data is coming from the user, not a spouse or grandchild.
  • Who is paying for the device and its usage, and how that affects behavior and motivations.

I tried to give these topics a logical flow above, so they aren’t in order of importance. The heart of the session was to make the product as convenient, trustworthy, encouraging and unobtrusive, and realistic as possible. Fail to achieve these critical goals and users will stop using the app or not believe the results.

If we fail these, nothing else matters.

This app addresses a serious medical condition and the consequences of using the app properly are significant. (Failing to follow the current manual process often leads to hospitalization.) One might assume that such target users would be extremely motivated to follow the process properly and stick with it long term. That assumption is wrong. A better assumption is that users won’t do something awkward, annoying, or seemingly pointless—especially over a long period of time. It needs to have a great user experience. Having beautiful, well laid out screens won’t save an otherwise poor user experience. And the screens themselves are only a very small part of that overall experience.

Being a lean advocate (or more precisely, my own interpretation, which I call “lean-er”), I recommended starting with MVPs to minimize risk. The first MVP would determine if an app can replace the current manual paper process, whereas the second MVP would determine if we can make it trustworthy, practical, and motivating over a long period of time.

Speaking of lean, lean advocates talk about GOOB, or “get out of the building.” The lean claim is that there is no knowledge in the building, so you have to get out and talk to users to understand anything. Frankly, I think that is bullshit. If you have a good team there is a great deal of knowledge in the building, but you have to know what to do with it. It’s far more productive to talk to your users once you have done this type of analysis than to go to them with a blank sheet of paper. You could talk to users for years and still miss many key UX issues that we found in two hours.

The bottom line

People often confuse UX design with sketching stuff. While sometimes is makes sense to start by sketching to explore different design directions, often that leads to putting too much emphasis on features, layout, and basic navigation—in other words, the technology. Instead, starting with users, their goals, the value we are providing, and addressing critical details like building trust gives us a much better direction to sketch. In true UX design, user goals, scenarios, and value drive the process.

I never design with a feature list or a set of user stories—they are just tools to figure out how to implement an experience, not to create one in the first place. This leads to what I call Everett’s Ultimate User Story:

As a user, I don’t give a damn about your feature list or product backlog.

Getting the app to perform the task mechanically would accomplish nothing because nobody would be motivated to use such a mechanical app. The key is to work through and design the human experience for the target users and being realistic about what people will actually do. For this project, sketching screens, working on the task flow, or making the screens pretty are secondary concerns at best.

The comments are closed.

For more information, please contact info@uxdesignedge.com

All Content Copyright © UX Design Edge