UX ≠ UI

Hi Birm here.....

My name is Ricardo Birmele, but people around here call me “Birm.” I am lucky enough to be the user experience (UX) guy on the CISG team. Like many of us working at Microsoft, I’m an immigrant; in my case flying into the United States from Brasil when I was a kid. In past professional lives I’ve been a Deputy Sheriff, a newspaper reporter, a book author (I wrote the very first of the “Idiot’s Guide” series), and a software developer. I’ve won prizes for UI design and for portrait photography. For fun I play a dog house bass in a community orchestra, go golfing, or SCUBA dive. For sanity I commute to work on a motorcycle. I’ve been a Microsoft FTE for about two and a half years; first running a worldwide training program, and now influencing the user experience effort for CISG.

Enough about me; let’s talk about user experience.

UX is fairly new as cognitive disciplines go. The ideas behind it derive from the sciences of applied psychology, ergonomics, and human factors as practiced by people working in the aircraft industry during World War II. The problem was that equipment then was becoming too complex for people to be able to use it safely. UX began as a way of looking at a collection of entities as being a single object, seeing how that object behaves, and then understanding how people interacted with that object.

People often take UX as being the same thing as user interface (UI), and that’s a miscommunication. An application’s UI certainly has to do with its UX. In truth though, UX as applied to software has to do with everything you perceive about using an application: how pleasing it looks, how well it works, what information it contains, how easy or difficult it is to use, how well it makes your work easier. In short, how our application appeals to you. Or how it doesn’t.

At the end of the day, UX is all about you.

We start our UX work by researching you and people very much like you. We learn all we can about how you go about your job. What information do you need to do it well? What are your pain points? What are your goals? How exactly would you use an application if we built it?

Once we have the answers to these questions, we build a persona: an archetype of a user who represents you and the other people very much like you. Notice that I said a persona is an “archetype” and not a “stereotype.” This is a very important distinction. An archetype is a statistically validated impersonation. Stereotypes are guesses derived from anecdotes.

Personas let us create scenarios: a sequence of actions we think you will perform as you use our application. Scenarios imply a design for a user interface: the pages containing the controls you use manipulate our application. Once we have user interface design, we ask people like you to test its usability, to make certain that this application solves your problem as intuitively as possible. And so it goes…

I think that you can see where I’m heading with this.

In upcoming blogs, I’m going to tell you in detail about all things UX. We’ll look at everything from UX design to UX research. We’ll come to understand some of the theories underlying UX. I’ll show you what makes a good UI design and how to accurately measure usability. We’ll even go into the science of cognition. And when UX makes the news, we’ll talk about that too.

For now though, I hope your take away is the fact that while they’re similar, user experience is not the same thing as a user interface.