Enterprise UX is communication - beyond UX clichés with Everett McKay

Jon Reed Profile picture for user jreed March 13, 2015
The importance of Enterprise UX is largely agreed upon, but that doesn't make it easier to do it right. UX expert Everett McKay has some fresh approaches to UX design that are worth a closer look.

My series on Enterprise UX has led to many discoveries, but the biggest danger is still the dreaded cliché. Yes, Enterprise UX matters, but why? And how do you translate that sentiment into designs that truly delight users? Even the word "delight" feels like it's been trademarked by a marketer somewhere, perhaps it has.

Everett McKay

In search of better answers, I attended Everett McKay's  UX Design Essentials class during a recent trip to Atlanta. I got plenty of content from McKay, whose approach to UX design is refreshing in its emphasis on communication over pure aesthetics (McKay's UX design class is three days long; I attended day two).

After the class, McKay and I taped a podcast on Why UX matters which delves into McKay's background and some of the content that surprised me the most. In this article (and one more to follow), I'll break out the principles of McKay's UX approach that move beyond the platitudes, including the flaws of UI aesthetics and why "intuitive UI" is such an over-used (and misunderstood) phrase.

How a developer became a UX evangelist

Before we dive in, a bit about McKay and why he thinks UX issues are coming to a head. McKay is an independent UX design consultant and instructor whose company, UX Design Edge, delivers both public design classes and on-site UX workshops and consults. He hails from Microsoft of all places, and was originally a developer. McKay's UX interests were peaked by the crummy materials of the time:

My career path has not been exactly carefully planned. Early on, I recognized that the key to success to software was to have a great user experience. However, early on, nobody really knew how to do a great UI. So I tried to learn how to do that pretty much on my own as a software developer.  Around 1998, I want to a C++ developer conference in Boston. I went to a talk on UI design, and it wasn't really that good of a talk. Half the audience left, the other half was falling asleep. I was thinking, "Well, I can do a better job of explaining this to people."  So I ended up writing a book that was published by Microsoft Press called Developing User Experiences for Microsoft Windows.

Eventually, McKay became a Senior Program Manager at Microsoft, with responsibility for the user experience for Windows server security. Later, McKay moved to the Windows client team, where he was responsible for writing and driving the Windows User Experience guidelines for Windows 7 and Windows Vista. He took over an internal UI training class at Microsoft, and for the last five years he's been teaching UX as an independent. His timing was pretty good, given the growing impatience with hard-to-learn enterprise software:

I am noticing a significant increase in the interest in UX design, mostly by technical teams. It boils down to the fact that the world has changed in may ways. The old way of thinking is, "If our users have to have training and read big giant documents, in order to learn how to use our product, that's fine." But I think we live in a new world now.

We're walking around with great user experiences in our pockets. We know what a great user experience is, and I think we have the expectation of being able to use a product without training. I certainly know that teams, or specifically companies, don't want to have to pay for training for their employees to get productive. We have this expectation that we can figure out how to use these products on our own without the documentation, without the training.

McKay's design principles are derived from his technical background and work with technical teams. But I found his content to have broader relevance, which was backed up by the mix of attendees in Atlanta, including folks with more functional, management, or design backgrounds.

Aesthetics are overrated - Enterprise UI is communication

McKay is not opposed to beautiful-looking designs. But one standout from his workshop is how the beauty of a design is less important than how it communicates with the user:

Aesthetics are a secondary consideration, not a primary—even for visual design decisions. The primary, of course, is how well the UI communicates. Visual appearance is very important. But I’m sure every IT pro would prefer a useful, understandable dashboard over a beautiful, meaningless one; yet there are way too many meaningless, beautiful ones out there.

With a focus on communication, UI design can avoid getting bogged down in subjective disagreements about which logo design looks better. During our podcast, McKay elaborated:

Honestly, I think there's a little bit too much art, a little bit too much subjectivity in UI design. A lot of what I try to do in my training is look at various tools and techniques that we can use to eliminate a lot of the art and subjectivity. So rather than having a discussion over personal opinion about what we feel about the artistic attributes of a UI, what I really try to focus on is more objective principals that we can use.

Which leads to McKay's "Enterprise UI is communication" mantra:

A user interface is basically a form of human communication. If we focus on how effectively a UI communicates to our target users, who are trying to get a task done, and we can do that in a very comprehensible, understandable way, that actually eliminates a lot of the subjectivity. It's not a question of what I like verses what you like. The question is: Which one communicates better? That takes a lot of the subjectivity out of it. Because we can figure that out; w e can agree on that. Whereas if we were just to discuss the visual attributes, we could talk past each other all day long and never agree on anything.

So if human communication is natural, why is software-to-human communication so stifled? McKay puts it simply:

Q: If the way we communicate in person is so much better, can’t we just design UI to be like that?
A: Yes! We can and we should!

He believes the differences between software and human communication are artificial and historical. On top of that, software that communicates better usually has no additional technical requirements. A great UI gets rid of those differences, and speaks to the user in a natural way:


Image used with permission of Everett McKay. This content is available in his UI is Communication book.

To illustrate, McKay showed examples of poor (and better) software communication. Poor examples include those interminable loads and  dumb search status bars without timeframes:



(Hopefully McKay doesn't mind that I chose a Windows example - this also happened on my HTC One Droid phone yesterday with a three hour firmware download).

One example of a more human approach came from a proto.io sign up form:


Nothing sexy or fancy about the proto.io confirmation screen, but nice touches include the informal "you never know" language and easy access to support. Feels like a human wrote and designed this page for another human.

McKay notes that EVERY design element on a page communicates something - from text to buttons/controls, icons, colors, animations, page layout, and feedback opportunities.

"Intuitive" is not just UI happy talk - there is a methodology behind it

Head to a UX design event, and you'll hear the word "intuitive" tossed out in the first five minutes. But what does "intuitive" really mean? McKay urges us to move past a link between intuitive and gut feel and instead, recognize the distinct characteristics behind an intuitive UI:

Whenever anybody tells me about "intuitive UI", I'll ask them, "Well, what exactly do you mean by intuitive?" The big surprise is that quite frankly, nobody really knows what they're talking about. The dictionary definition of intuitive is instinctive. But that has nothing to do with what we're talking about here. It's not about instinct at all.

A very important part of what I try to do in my class is to teach people what exactly it means to be intuitive. I give a very specific definition which is: a UI is intuitive if our target users can understand how it works without the use of documentation, experimentation, memorization, training, or any sort of assistance. In other words, it's immediately self-explanatory. So if we have to do any of those things, that's by definition a sign that it's not intuitive.

Fine - but then how do you make a design intuitive? McKay has identified a series of specific attributes that are needed to make a UI intuitive, which he frames in terms of the "interaction life cycle." In other words, what are the steps that a user must go through to interact with something? Here's McKay's attributes:



Image used with permission of Everett McKay. This content is available in his UI is Communication book.

Most of these concepts are self-explanatory, but they prove invaluable when building out mockups based on the target personas. "Affordance" is not a commonly-used term by the layperson, but the definition of providing the right clues is clear enough.

I was particularly swayed by the concept of UI forgiveness, having just encountered an unforgiving Google Chrome bookmarks design that resulted in several hundred bookmarks wiped out without so much as an "are you sure?" screen. We'll all been on the wrong side of that kind of unforgiving UI. McKay:

Users make small mistakes all the time. Most software makes you start completely over. I had an experience with Lufthansa the other day. So I have a account which is like a 14-digit number. They were asking me for my PIN.  So I type in the 14-digit number. I type in the PIN. Guess what? They cleared not just the PIN. They cleared the 14-digit number.

McKay then went on a mini-rant about entering the number again and again, getting an email confirmation, re-entering the number, and so on. Bottom line:

I had to enter this 14-digit thing four times. They cleared it every single time. Now if I enter a correct account number, is it too much to ask for them to remember it? Especially, if it's 14 digits.  I have what I call my Law of Large Input, which is the more difficult it is to enter something, the more likely it is we're going to have to enter it more than once. The funny thing is when you look for this pattern, you see it all over the place. Every time the user makes a small mistake, we really punish them quite harshly by making them start over.

McKay's brought these intuitive elements to bear on a number of UI examples. He then made a final point: consistency is crucial to being intuitive. But by consistency, he was referring not to the visuals but to the consistency of interaction. In fact, McKay believes that interaction consistency is far more important than visual consistency. He cautions against adding features that result in an inconsistent design, as such elements are "easily outweighed by the lack of familiarity." An example would be to use the "swipe" gesture on a mobile device in a different way than other apps utilize it.

But McKay is not an idealist: he recognizes that each design element has a tradeoff:

  • Discoverability might result in clutter, or by showing features that are not relevant to all users.
  • Predictability might require too much explanatory verbiage.
  • "Forgiveness," as appealing as it sounds, might not always be practical and in some cases, might hurt performance.

That's why McKay recommends thinking of intuitive not as an ideal end state, but in terms of "Levels of Intuitiveness." He divides UI experiences into Intuitive, Usable, and Unusable. As designers plot their design, they can assess the importance of each element in relation to this usability scale. Tradeoffs of time, performance, and feature completeness can then be factored against the user's expectations.
That's plenty to gnaw on for one piece - I'll return with more on McKay's approach to UX design next week.

Here’s the embedded version of my UX podcast with McKay:

(You can download the podcast also, on my Busting the Omnichannel page)

Note: this article is part of a ongoing series I am writing on Enterprise UX and the highs and lows of mobile app design. Next week, I'll have more from McKay, including his take on why design personas actually do matter - as long as you don't screw them up.

Image credits:  Slides and book excerpts from UI is Communication are used with the express permission of Everett McKay, all rights reserved. McKay photo by Jon Reed. Feature image: Man with future high tech smart glasses © ra2 studio - Fotolia.com.

Disclosure: I have no financial ties to Everett McKay or UX Design Edge, and I funded the trip to Atlanta for family reasons. McKay provided me with a complementary one day attendance to his class for the purposes of this article content.

3/21/2015 - Updated with several clarifications and an additional quote on aesthetics.

A grey colored placeholder image