GUIs are killing Expert Users (and it’s our fault as UI/UX Designers)

First, let me start by saying, “Milton Glaser (and the state of New York), please forgive me for borrowing your beautiful logo.

Okay, let’s begin.

Recently, I have started to question whether how I design software for expert user experiences is truly satisfactory, or purely lip service.

I am certain that many of you fellow designers out there share a similar story with me — an academically trained graphic or industrial designer, who at some point became a web designer, then fashionably turned into a mobile app designer, and now find themselves sporting a new hybrid title like interaction designer or user experience (UX) designer. And like me, many of you get to work designing projects some of the time for what I would call the public “consumer” space, and some of the time for the private “professional” space. For the professional realm, this could be anything from an internal corporate intranet website, to a custom mobile app for employees working in the field. Designing for this space often has difficult constraints of needing to interact with legacy systems or supporting a multitude of devices and browsers that are years behind the industry. But one thing is common — the users of these applications can spend approximately four or more hours a day, each day, using this software. And our cute, mobile-first GUI based designs are killing them.

One user. Two interfaces.

I was reminded of a story an experienced colleague in the UX industry, whom I worked with on a mobile project a few years back, told me about when they used to work for an airline reservations system company more than 20 years ago. During one of the many business mergers and repositioning, two large systems needed to be combined into a single new one, and with Windows 3.1 and Mac OS 7 sweeping the market, software design turning from terminal character-based interfaces (CUIs) to 16-bit graphic user interfaces (GUIs), they decided to do the same.

On the previous text-based system, an airline agent working at the airport check-in counter could register a passenger, print their boarding pass (for those of you who remember the days before online check-in), and attach their baggage sticker, all approximately in less than 1 minute of time to complete the tasks once starting.

A large problem of the previous system, however, was that is took the average new employee, approximately 2–3 weeks of practice before becoming fluent and up-to-speed on the full action set, largely due to having to memorize the various screen shortcuts and build the keyboard muscle memory for each screen to be efficient. On the new graphic based application, where all the actions were neatly arranged in well organized menus and sections, the same new employee could be fully trained and comfortable in only 2–3 days.

A huge user experience success from initial outset, especially at a time when frequent employee turnover was beginning to rise, to have such a gain in learnability and reduction in training time. But, one key and unforeseen downside was the measured time to complete the same passenger tasks — register, print boarding pass, attach baggage sticker — now took on average between 2–3 minutes.

Generalizing average wait time in CUI vs GUI based systems. If you arrived late, which line would you want to be in?

The new system was faster to learn, but slower to use — simply because the computer now had to generate a beautiful new visual interface and the user had to spend more time navigating spatially with their mouse in a point-and-click, target acquisition fashion, over and over as they would move between menus, screens, and input fields. What happened?

I am a designer, and I am the problem.

Wait, what was that?

I am a designer. I was trained to solve problems with the fundamentals of design: space, line, form/shape, color, size/scale, weight, direction, hierarchy, dominance, gestalt, unity, contrast, balance. So naturally I approach solving any brief with a visual solution first. I pay attention to personas, study workflows, observe users in the field, and then when it’s time to create a solution — I make sure the metaphors and patterns I use are appropriate for the situation and user, ultimately in the form of a well designed GUI. When considering expert users, some additional keyboard shortcuts might be added, the interface expanded to include advanced options, or additional actions menus revealed on hover, force-touch, etc. The problem is most of these features don’t promote true expert usage at all, but mere advanced-beginner usage.

I started to realize in dealing with current projects that I was missing something, and that I was creating the exact same trap for users today that my experienced colleague’s team did those years ago.

Turns out, the failing lies with thinking like a graphic designer — and with a GUI itself.

“Their [GUIs] success is partly due to their natural support for novice users, [because] novices benefit from being able to visually find salient interface elements and manipulate them. … However, the very characteristics that make GUIs effective for novices also cause them to fail in their goal of supporting experts, and GUIs often trap users into a ‘beginner mode’ of operation. … Conversely, interfaces explicitly designed for experts (e.g., keyboard shortcuts or command-line interaction) allow high levels of performance but only after extensive training” (Cockburn et. al. 2014).

Reading further about the reasons why a terminal character-based interface can be superior in speed and performance for expert users is largely due to their ability to provide a mechanism for users to rely on “automaticity,” where the physical motion needed to complete the task can be done quickly and without in-depth conscious thinking. The strength of muscle memory allows for the expert to then focus mentally on other higher level details or actions while completing the current task while on autopilot.

Thinking about it another way, the applications that we create as UX professionals for expert users become their daily tools, no different from the way an accountant uses a calculator while adding receipts, a chef handling a knife while dicing an onion, or a surgeon holding a clamp, scissors, & forceps. In each of those cases, what defines an interface as being expert, is a user not ever having to look at the tool itself while performing the action, but focus on the task at hand, with the tool becoming an virtual extension of themselves. Image that, “designing” an interface that user doesn’t even need to look at. Kind of takes all those years of visual training — studying Milton Glaser, Paul Rand, Saul Bass — worrying about perfect white space, typography, and color, and throws it out the window.

Which makes me wonder if a mobile app, largely driven today by a touch-screen interface could ever be an expert one. Maybe, perhaps only if a user could use the phone and app in a way without needing to physically look at it to complete every action. Perhaps with gestures, or motion, or even dare I say, with a physical keyboard or buttons (goodbye BlackBerry Classic). It wasn’t that long ago when teens could send full 140-character text messages from under the table, not once looking at their phone’s 128x160px screen, all because they had the muscle memory of the T9 keypad input sequence of what they wanted to say.

“… what defines an interface as being expert, is a user not ever having to look at the tool itself while performing the action”

Biasing Principles

Richard Omanson, Adjunct Professor at DePaul University and Vice President at GfK Custom Research, has detailed seven design characteristics when looking at the biasing principles between novice-based interfaces and expert-based interfaces: density, constance, efficiency, knowledge, visibility, constraints, and conventions (Omanson 2012).

Looking at a few examples to best illustrate the seven characteristics, density is best demonstrated by two financially driven interfaces, one being an ATM and the other being a professional stock trading application. Both in essence allow you to “move money”, but the differences couldn’t be greater. An ATM needs sparsity an abundance of white space to direct attention and be easy to walk-up-and-use from the first try. A day trader on the other hand prefers density, keeping as much information visible as possible and learns to see patterns, scanning small sections at a time rapidly to gather information.

Citibank ATM vs. RealTick Day Trading Software

Expert users require constance, items keeping the same position in order to better build spacial and muscle memory learned through repetition, but is not important for novice users where focus can be placed on progressive disclosure and preventing errors. The same is true for efficiency, experts want to avoid multiple pages and uncessary mouse clicks, but again is unimportant for novice users where guidance is key. An example of this might be using wizards, or step-by-step workflows like TurboTax. Perfect for at home consumers, but answering questions one at a time would frustrate professional CPAs filing hundreds of clients’ taxes each season.

Intuit’s TurboTax

Visibility of actions becomes important for novices, less so for experts who learn how the system should behave. Novices will bring knowledge from the outside world with expectations of how your app should behave from other similar apps, experts will learn the patterns of your app and knowledge then comes from the user. Very similar is conventions, where patterns in novice apps should follow same patterns they have already learned elsewhere, experts again will learn new patterns you teach them as long as they remain consistent throughout the application. Finally, constraints like wizards, progessive disclosure, default choices, and conditional enabling of features to help guide novice users will frustrate experts who prefer removing all “bumper pads” that slow them down through their workflow.

The Third User

To quote Jakob Nielsen from 2000, “It is time to take expert user performance more seriously on the Web.

The term “the third user”, coined by Bruce Tognazzini helps describes how we’ve gotten to where we are today. Apple has lead the way with elegant, designful hardware and software that has driven the role of UX design into the front seat of every major product and service company. Microsoft and Google then inspired the industry into flat design with Metro (now referred to as ModernUI) and Material Design, both with a mobile+touch centric attitude.

We are now at a point where we have created solid and repeated patterns for the web, shifted to a mobile-first strategy (thank you Luke Wroblewski), adapted our content with Responsive Web Design and user-context first awareness. Mobile apps are king, flat design is the rage, and we are starting to take stock in what we have left behind with all our successes.

To use two movie metaphors, we have mastered refining the sleek, simple and reduced interface style, similar to Disney’s “Flight of the Navigator”,

Flight of the Navigator (1986), Walt Disney Pictures

but what we have left behind and need to recapture is the amazingly dense console from Pixar’s “Lifted”, only mastered after deliberate practice, but powerful in speed and efficiency once learned.

Lifted (2006), Pixar Animation Studios

Where do we go from here?

Does this mean we should abandon all GUI interfaces when designing applications targeted at expert usage? Reverting back to terminal, character-based and command-line driven interfaces instead?

Well, no — but what we can start doing is advantaging expert workflows by “designing” for the Third User-first. As UX professionals, we can create a mechanism for a user to complete their set of tasks without ever looking at a screen (other than perhaps for key-entry awarenss and confirmation of their actions). Then, we can build requirements around those keyboard-actions, layering on a dense, traditional GUI second which also accomplishes the same tasks while supports the learning of the “expert” mode key sequences, perhaps even building in methods for the UI to listen or toggle on a keyboard “action mode” (think adding a command-line prompt on-screen). Next, I would argue that we need to find the best way to transition users from novice to full experts, which still remains to be largely unsolved with so few industry examples to go on.

One difficulty our field has in showcasing best-in-class expert interfaces is most professional software tends to be private, locked behind corporate NDA’s and policy. When gathering research on Dribbble and other UI pattern resources, sites are filled with consumer-driven examples designed for the novice to advanced-beginners.

So I am putting out a call — if you have worked on an expert interface, seen or used an expert interface that you can freely share, mention it here. Let’s start to gather ideas, patterns, and user research, so that we can continue the conversation of how best we can regain the efficiency lost over the past 20 years after we have unknowingly created very-well designed GUIs.

Let’s stop killing the Expert Users.