There are many UX design methods and tools that guide designers in creating brilliant solutions for whatever types of products or services they create. However, I’d argue that their effectiveness depends enormously on the profiles of the individuals on a team and an organization’s understanding of user experience. If we fail to take these factors into consideration, those methods and tools alone won’t make us successful. Hence, I want to take a step back and look at what I think forms the foundation that enables and sustains great user experience.
Two Sides of User Experience
User experience is about the impressions a design solution makes on users—what they remember about a solution and whether it left them satisfied or frustrated. As psychologist and Nobel laureate Daniel Kahneman has pointed out, the key here is not the moment when users achieve their goals, but what they actually remember about achieving them. [1] Kahneman differentiates the experiential moment—of what he calls the experiencing self—from its memory, by what he calls the remembering self. The former is temporary; the latter, long lasting. We do want people to remember and talk about their experiences with the solutions we design, don’t we?
Believing that the moment of experience is all that matters can mislead designers. That moment is certainly important, but it is not the crucial aspect of user experience. We often focus too much on the temporary wow and too little on designing solutions that are meaningful and have a positive impact on people’s lives. The book Paradox of Choice, by Barry Schwartz, and the short documentary The Story of Stuff, by Annie Leonard, both illustrate this problem wonderfully. How can we consistently design products that both address users’ goals—that is, the experiential moment—and leave great memories?
Meta-users: All of the Stakeholders Who Play a Part in Creating User Experiences
When a project commences, one of the first questions we always ask is: Who’s the intended user? We do user research to uncover and understand our target audience. The findings from our research provide us with insights that directly influence the creation of our design solutions. While understanding our prospective users is vital, there are other players who we, as designers, need to consider: the stakeholders who are participants in our design process. These are a project’s meta-users.
Before team members do any work together, each person on a team needs to understand all of the other team members, their motivations, and their agendas. These will have a direct impact on our design work and, thus, the resulting user experience. We need to get answers to the following questions:
- What are the company’s goals and agenda?
- Who in the company is asking for this product and why?
- Who are the decision makers?
- Who sets the constraints in the organization?
- Who are the team members creating the product?
- How do their skills fit together in helping to design and develop the product?
- What are the motivations, agendas, and influences of each team member?
Answering these questions—and it’s crucial to probe until we have the actual facts—helps us to understand our meta-users. Then we’ll know how to adapt our design process to get the best effort out of everyone. It also gives us the necessary confidence to deal with obstacles that we encounter along the way. Challenging stakeholders lets us achieve better results. To do so, we have to grasp the motivations behind each of their requests and identify the source of requirements.
For example, on two different occasions, a designer wondered why the product she was working on had to have a timer in its user interface. The businessperson in charge claimed that, without the timer, the product couldn’t get built, but gave no further explanation. Getting answers to that list of questions I outlined earlier uncovered the true reasons behind his statement. In one case, the product was part of the clock business group. All of their products had to have a timer; otherwise, they would belong to another business unit and that particular businessperson would lose the project. In the second case, the product consumed more energy in its standby mode than government regulations regarding maximum power consumption would allow. Including a timer in the display was a cunning evasive move: regulators would not then consider the product to be in standby mode.
Understanding the underlying facts makes our work much easier.
Assembling a Team: From Titles to Skills
Today’s products are complex, and great products result from the well-synchronized team effort of people in different disciplines, who have different perspectives—the UX designers, engineers, and business and marketing professionals who are assigned to a project. Rather than just following the typical steps of an iterative, user-centered design process, it’s important to adapt our UX design process to the needs of our product teams—their ways of working, information flows, decision making, people’s skills, and the roles they play. This is simply applying user-centeredness to the product development process.
I’ve noticed that, when people discuss their product development process, the talk often revolves around job titles, with every role having predetermined tasks, as follows:
- designer—Gets the design brief and comes up with a solution that fulfills users’ needs. Studies users’ behavior to craft an appropriate solution. Along the way, comes up with many new ideas about how to address and solve the design problem.
- product manager—Identifies market needs and builds the business case for a product. Along the way, defines new business models and the product’s value proposition.
- marketer—Spots market gaps and helps the business to formulate market needs. Along the way, finds different ways of expanding the business’s product portfolio.
- engineer—Looks at ways of developing the product. Along the way, discovers new technologies that suit the project and address its various development problems.
When people in specific roles limit their contributions to working in just their own area of expertise, they complete their job, then hand responsibility over to a person in another role. There may be some collaboration, but designers, business people, marketers, and engineers have their own individual jobs to do during product development. While people in every role try to innovate and improve on what others have done before them, because they’re working in silos, their ideas stay within those silos.
However, a product development process can be more fruitful if a product team leaves behind narrow, siloed thinking; considers the strengths and weaknesses of the specific people they have on board; and emphasizes answering the questions and resolving the issues the team needs to tackle. Some of the questions that any product team needs to answer during the course of a project include the following:
Proposition
- What goals are users trying to achieve?
- Why do people need the product? What job would it perform for users?
- Why would someone care about having the product?
- What should the product do? What features should it have?
- How should people use it?
- How could we make the product stand out in the marketplace?
Development
- What level of performance should the product have?
- How can our team implement the product?
Distribution
- When would be the right time to introduce the product?
- What should the product’s price be?
- How should we introduce the product?
- What are the right promotion and distribution channels for the product?
- How should our organization follow up with customer care and getting feedback?
A cross-functional product team can consider these issues from various angles and should address them collaboratively. Only real teamwork lets us utilize the unique skills of everyone on a team—whether it’s a product team or a UX team. However, it’s important to align the skills and motivations of all team members to ensure we have a high-performing workgroup.
Pabini Gabriel-Petit’s article “Specialists Versus Generalists: A False Dichotomy” exemplifies this principle of collaborative work. [2] In her article, she describes her ideal small UX team and the skills a team needs versus job titles.
When we organize teams by job titles, each person on a team sees only what other team members’ business cards tell them to see. However, if a team works together to address and solve all issues, three things happen:
- When the team discusses issues as a team, they’ll develop a common mindset and shared objectives. The team comes to have a single vision of what they want to achieve.
- Everyone gives their best, because they are working toward a common goal that they’ve agreed on. This is very different from individual team members’ working toward only the goals for which their job titles say they’re responsible.
- Everyone contributes to every aspect of the product because they’re sharing responsibility for it.
On high-functioning teams, job titles become relevant only when they’re assigning accountability for decision making. Team members should be experts in whatever role an organization has employed them to fulfill and should be responsible for making decisions in their own areas of expertise. If more than one person is making decisions about the same thing, you’ll know they’re working in silos.