Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles What UX is and isn't?

What UX is and isn't?

Let me start with a story that I think sums up what most people think of when they hear the term user experience.

A financial site I use sent me an email asking me to click a link to review some information. So I click the link from the email and am about as confused and disoriented as when I wake up in the middle of the first night in a new hotel room and nothing looks familiar at all. And just like when I wake up in that situation, I start to panic, whimper and groan. Unlike when I’m in that situation, however, this time I’m not alone. My friend Lisa is visiting and my emanations prompt her to ask, “What’s wrong?”.

“I got a notice to review information, with a link. But when the page loads, I don’t see the information! Nor any place on the page that indicates where to find it. This web site is lame. What a bad user experience”, I grouse.

“C’mon, Aaron. It’s impossible to make a financial site sexy and attractive”, she retorts.

Lisa was making the common mistake of conflating the attractiveness of a site with whether it is usable or not. Since Lisa travels weekly on business, rather than lecturing her on the finer points of UX, I instead ask her, “Have you ever been in a hotel where the iron doesn’t fit under the sink? To me, that’s a bad experience, even if it’s a four-star hotel and a top-of-the-line iron.”

“You know what’s my pet peeve?” Lisa asks, now animated and standing up, “When the door to a bathroom opens in against the toilet.” She pantomimes the action of scooting around a door like she’s on the edge of a cliff, and then stepping over the toilet like the floor is lava and must be avoided at all costs. She then turns to me and says, “It makes entering near impossible and happens to me in high-quality places. I think I get it. With a good experience things are easy and enjoyable, or at least require little thought and no hesitation to do.”

Lisa now has a pretty good insight on what User Experience is, and it is more than how a site looks. She mixed up the aesthetic of the User Interface (UI) for a software product with a good User Experience (UX) for the person interacting with that UI.

Confusing the site’s look and design with the overall experience is so prevalent that Ed Lea wrote a much-shared blog post, PRODUCT + UI + UX + CEREAL. It is one of the better metaphors, using breakfast cereal to illustrate the difference between the Product, the UI and UX.

The product shows a picture of all the components used to make a bowl of cereal, neatly separated out. It’s everything you need to eat cereal, including bowl, spoon and a pitcher of milk. For me, the flakes, raisins and milk are the different information. The bowl is a container for the information like a browser or server, and as shown, the spoon is the UI.

The UX, on the other hand, is how all of the components come together. The cereal in the bowl, milk poured in, spoon sticking out has everything needed to enjoy a nice bowl of cereal.

One of the reposts had a comment that the UX should be a picture of a child grinning, and maybe a dribble of milk out of the corner of their mouth. I tend to agree. After all, it’s the user experience. The bowl of cereal looks nice and without seeing how it affects someone, we have no idea if this product positively changes someone’s behavior.

This example simply gets the point across that there’s a difference between UI and UX. You might also be noticing that I don’t refer to UX as a role, or a person. There are highly skilled specialists in the role and they can be called anything from designer, to UX architect, to maybe even developer. It is the person on the team that cares deeply about the users and making sure their needs are met. It might also be a group of people in a role, and reporting to a director of User Experience.

I take a page from Marty Cagan’s playbook here, that UX and usability are one third of the disciplines needed to build products people love. The other two are Product Management, which concentrates on what is valuable to the user, and Development, which concentrates on the feasibility of building what people want and can use.

With that in mind, I coach teams on how to run parallel tracks of continuous discovery and development in either Scrum or Kanban environments. There are other ways that we’ll get to later, but these are ones that I prefer and know the most about. It basically means that User Experience is part of a collaborative, self-contained and balanced team that has all the necessary roles to be wholly responsible for building the right thing, and building the thing right.

User experience runs deep, is way more than the UI, and starts in the abstract with the strategy. What are the business, creative, or other internal goals? What does the user want to accomplish and what are their goals? At this level, UX is involving the team in user research, interviews, observations and the like.

From there, we can start to discuss the scope needed to obtain the company, customer and user goals. Getting a little more concrete, we can then look at the structure needed to support the scope. UX will be working with the team on the flow of user tasks, interactions and how the information will be put together for easiest consumption.

With a structure in place, we can now take a look at how the user will navigate through the information, the interface elements, and how to best present the information for understanding while the team is working with UX to put together a skeleton of the site.

When all these elements are in place: the strategy, the structure, the scope and the skeleton; UX and the team can concentrate on the surface. These are the most concrete aspects of User Experience needed to finalize the site, put together a visual design and presentation layer in order to build the UI. Visual design includes treatment of graphics and text, interface and page elements, and navigational components. It is the frosting on the cake.

Jesse James Garrett explains “The Elements of User Experience” in his diagram, which later became a book by that title.

UX isn’t about having a sexy look and feel, although a good aesthetic helps. Making a good product look great should be done last, after iterating on the need and then starting with something more abstract. In reality, and even Jesse admits it, teams tend to traverse between the different layers, depending on what they’re learning about the user and what would make the site better for them, and how best to hit the internal goals.

The problem of confusing the UI with UX is so prevalent, even people in the role of design are guilty of doing it, producing the visual design comp first. Working from the top-down and creating the pixel perfect design comp is similar to making a “hobo with a shotgun” (HWAS). This is one of the only examples I can find of a movie where the trailer was shot first. It’s expensive to do that. A trailer needs actors, a stage, equipment and other stuff that costs a lot. Most movies start with an outline and some wireframes, even before the script is generated. Have you ever heard of HWAS? It wasn’t really that good and people don’t like it. There’s a bit of a cult following, but that’s about it.

The pixel-perfect design comp usually lacks important things like a budget, team, or reasonable estimates for the effort involved. This shiny object cannot address the strategy, or all possible site flows. Instead, it has executives uselessly debating things like if there should be a hyphen between pre and season. Users wonder what’s happening with the product. A budget might not exist, but the pitch worked and the concept sold. This typically leads to making expensive decisions early that have to be stuck to. It results in death marches, and other Really Bad Stuff. Most users, like most people who saw HWAS, tend to not like the end result very much.

It’s usually a hired out design agency that produces the visual design first. It can also be an internal group, like User Research and Design. An internal group like this is sometimes called the “internal agency” model.

This agency model is justified through a desire for design consistency, brand protection and best utilizing this somewhat misunderstood skill set. People rationalize that having a center of excellence will make sure everything hits the design standard, vetted by all the different skill sets.

When things come back out of this center, if they do at all, they are highly polished with posters for the personas, mock-ups for the product. They are very hard to change and full of holes as it’s impossible to cover all the “what-if” scenarios in a mock-up.

Looking back at Jesse’s Elements, there are many roles represented, like visual design, user research and information architecture. Typically, one person will be great in a couple of these areas, but not in all of them. This necessitates many people coordinating their work together to fulfill everything needed. This is a strong case for the internal agency model. For those using this model, try letting UX people work on delivery teams to shorten lead-times, amplify learning and cross-train. To keep the design consistency, try communities of practice.

In a community of practice, people in a functional area like UX and their enthusiasts gather regularly to discuss and work together to keep functional consistency. The community may create and update the design library together, have brown bag lunch-and-learn sessions, have more formal training, and workshop sessions. It goes far beyond everyone who reports to the same boss getting together to talk about work, and decisions being passed down from the executive team.

Distributing User Experience onto delivery teams helps build a learning organization. This can only happen if there’s the time and skill for collaboration. In Senge’s shared vision process, it takes leadership capacity from the troops in order for co-creation to be effective. The trade-off is that it requires less direct input from the boss and allows management to level-up.

Sharing the capacity means that every team can make decisions on what people need, the best experience for them and if it’s feasible to build it. User Experience collaborates with Product Management and Software Development in a co-creative model of shared leadership and picking up skills from each other to deliver the right product quickly.

User Experience is still a blend of all the things like visual design, interaction design, information architecture, and user research. Integrating UX into the team allows other team members to apply their expertise on areas of UX like performance, ADA compliance and micro-text; as well as gain new skills in areas like user interviewing and acceptance testing.

Forming a core team from Product Management, User Experience and Software Development makes UX a part of Product Ownership. Scrum goes better if all team members develop some mastery of Scrum, making it more than the ScrumMaster role. Scrum also goes better if the team feels ownership for the product in the market, making it more than the Product Owner role.

Together, the team explores the real options on what people want (to buy), the best experience for them, and what’s feasible to build. They work together to give these options value by using all the known practices out of Lean UX, design thinking, discovery and other tools that help validate that the right thing is getting built for the user.

About the Author

Aaron Sanders is an Agile Coach. Coaching people to enjoy working in collaborative, learning environments excites Aaron.  Especially in pursuit of building lovable products. People ask him to train, consult, mentor and facilitate teams to better use a set of Agile discovery and development concepts, tools, methods and practices. The whole set gets absorbed through interactive training, applied in context. And it usually takes more practice for it all to sink in. Coaching allows Aaron to sense an impactful situation, helping people to integrate the set of Agile concepts, tools, methods and practices that much faster. Aaron’s effectiveness results from experiences spanning over two decades in technological and interpersonal disciplines. For him, there’s always room for improvement. Pairing with others helps improve Aaron’s collaboration skills while increasing the customer’s benefit, so he consistently seeks out people to co-train and coach with.

Rate this Article