UX: You are not the user.

Chad Macandog
NYC Design
Published in
7 min readMay 8, 2018

In such a rare chance when Jony Ive (Apple’s Chief Design Officer) graced a public interview, he was asked what he would consider the greatest product he’s ever designed — the one he was most proud about. The interviewer, a newspaper director, could not contain her excitement and haphazardly blurted out: “Would it be the iPhone?”

At that point when I was watching, I said to myself: “Yeah, why not?” iPhone was a true game-changer in many ways. It did not only revolutionize the phone industry, it ignited a shift in how consumers perceive and interpret products. As a result, companies started embracing design in order to keep up. Plus, it catapulted Apple to the zenith of the tech world buoyed by people’s love and loyalty for their products. So yeah, why not the iPhone?

So Jony quirkily gestured to ponder what his response was. Then he opened his mouth and the first thing that went out was: “No”. He then furthered:

“I think what I’m more interested in is an approach, a process. Those are the things I get frustrated with, excited about, inspired by, and proud of. And that seems for me so much more significant than a single thing, more significant than a single solution.”

It’s The Process

One person can’t save the world. Not Jony, not even Steve.. it takes a village, more passionate souls but sheer talent, nor skill, even genius is not all that cuts it to create something product. And by great I meant something useful, understandable, usable, and desirable for people. That’s the hallmark of a great user experience, isn’t it?

I have to thank NN/g’s UX conference in Chicago last week for inspiring me to write this. It was enjoyable as it was re-affirming. Having a strong affinity with UX prior, the sessions did not wow with new groundbreaking principles, concepts, and/or techniques but the rich stories from the pioneers who have seen it all and lived it through the years were profoundly eye-opening in many respects.

I have a newfound advocacy. Drawing upon my decade-long experience in technology, I have known this to be true — its the process. It’s the special sauce. It’s what makes the result greater than the sum of individual parts. And this is empowering to know and recognize because by doing so, we have a better shot at success.

Having a process is not rocket science, by the way, far from it. There’s no need to reinvent the wheel because frameworks like design thinking already exist which gives us “the” process. The problem is we’re taking some but leaving out the critical parts — the key activities we tend to overlook. In barebones, these are (1) understanding the user and (2) testing with the user. Simple, but always missed.

First: Understanding the user.

“You are not the user.”

I love this quote from NN/g so much so that i used it as the title of this post. It’s true. One way or another, we have been a part of a project that delivered a product or service designed by a few of us in a room with the best intentions in mind only to be startled by low adoption figures, not-so-good feedbacks, or reported losses in productivity which makes things worse than they initially were. Unfortunate, but utterly avoidable.

“The road to hell is paved with the best intentions.” — Jughead, Riverdale (Ep. 10)

If we want our users to use our product, we ought to understand them first. The rule of thumb should be: if we don’t understand our users, then we should never start designing for them. It’s all about knowing who they are, their dreams, their worldview, their motivations, their routines, their environments, what frustrates them and what makes them happy to give us an informed sense of why and how they might use our product.

Right, that sounded like creating “personas”, didn’t it? Yes, because that’s what it really is. Do we have them in our projects? Maybe yes, maybe not. Are they a result of user research? No. And that’s the problem. When personas are defined in a room without the due diligence of research, we run the risk of not capturing the real behavior of our target market or user base. We would end up relying on pure empathy which isn’t bad but completely insufficient leading to loose hypotheses.

Bill Gates and Steve Jobs agreed on one thing. During their iconic appearance together in an interview at the D5 conference back in 2007, Bill said something like: “In a certain sense, we build the products that we want to use ourselves.” Fact of the matter is, Apple has had human computer interaction professionals since the early days of Mac. It took ten years before the graphical user interface with Windows took off and became mainstream.

Jan Gehl, master architect and planner who helped made Copenhagen one of the most livable cities in the world was asked about the tools he would give a politician who is interested in designing a city in a bike-friendly manner for the future. Part of his response was: “The cities knew everything about the traffic and nothing about people, and how and why people use the city.”

The problem transcends industries. Understanding our users is key and arguably the most important thing to do when designing something for people. Freedom is never absolute and as such we must acquire a license before doing certain things in society like driving. This is how I feel about design, the license requirement is gaining knowledge about users.

Second: Testing with the user.

During our interaction design class at NN/g UX, Bruce “Tog” Tognazzini told us a story about him being summoned to the “San Francisco Chronicles” office during the 80’s where he faced about a hundred angry and seemingly protesting employees because Adobe had a new version of Photoshop for the Mac which changed shortcut keys people were already familiar with on the previous version and introduced a whole new bunch of keys for folks to memorize anew. Tog was the keeper of the Mac user interface at Apple back in the day.

Amazing story. Adobe clearly missed out on one simple step that could have unraveled and exposed how people would respond to the changes made and course-correct along the way. Right, testing with real users. How many times has this happened to us? I am guessing at least once or twice for the most of us and a lot for some of us. How we’ve managed to screw up here is perhaps one of life’s unfathomable mysteries but now is the time for change.

It’s never too late.

Let’s talk jargons. In design thinking terms, this would be the “test” after the “prototype” phase. In lean terms, this is your “measure” after the “build” phase. A lot of people know about this and yet are not doing it right. In agile terms, this is NOT the sprint review. There would usually be a User Acceptance Test (UAT) at the tail end of all the build sprints. Are we going through these phases? Most of the time, yes. Are we doing it right? Yes and no.

The way we do user acceptance testing needs to improve. We’ve been used to relying on scripts where the happy path is laid out to the user, or the business stakeholder, to follow so the outcome is focused on the technical quality of the product, not the experience. In the end, this gives us a working and stable product that nobody uses because we failed to give our users the freedom to explore and tell us what they think or feel about our product.

There are various ways we can pull it off inexpensively such as doing a usability lab study where we would gather a few of our users in a room and get them to use our product by giving them goals and scenarios, not scripts. We would then observe them to see where they are being confused or stalled. Even better if we can get them to verbalize their thought process as they do it. Also, it would be great if we can record the whole thing so we can review and capture valuable nuances that we might have missed out during the session.

I remember doing this recently for an app and the results told us a lot about our stuff we never knew before. The whole team found it both revealing and fascinating. And now we’re on the path to improving the app based on what we learned. Now, if you’re piloting out small, the benefit can be enormous. A stitch in time saves nine.

The key is not to be discouraged by criticism. It’s better to be embarrassed now rather than later when your stuff ships widely — right?

Wrap-up

Okay, so that was my one-two punch. Of course, in between is where the fun stuff of crafting the look and feel, the information architecture, and the interaction design of the product happens.

What I’m saying is we can create something beautiful AND impactful at the same time, it’s not either or. We can do this by ensuring we (1) understand our users and (2) test with them as part of our process.

, Chad

--

--