Educating Colleagues on the Differences Between UX and UI

Someone Asks You for Mockups Prematurely

As UX designers, we’re in a constant battle with forces that push us from the problem space into the solution space—even when projects are not on an overly aggressive timeline. As I’ve experienced firsthand, it can be tempting to succumb to such solution-centric pressures before we’ve adequately experienced or understood users’ painpoints, goals, and needs. Often, managers deny us their permission to do research or won’t give us adequate time to walk in users’ shoes before they insist that we must deliver something. However, such unpredictable forces do not absolve us from endeavoring to understand our users first. So, when someone suggests that you start creating UI mockups prematurely—before there are clearly defined requirements or you’ve conducted adequate user research—I suggest that you respond tactfully, reminding your colleague why leaping into the solution space too soon can be problematic. Consider the following possible responses:

• “Yes, I’ll design UI mockups. But, first, I need to understand the product—or feature—requirements and how those requirements support users’ experience. Even if you haven’t yet formally defined its requirements, let’s chat about what you think they are and how we can get access to some target users—even if by phone.”
• “I understand the urgency driving this product—or feature—and can design UI mockups in accordance with the aggressive timeline. However, if we skip over understanding users’ needs, we could create UX and technical debt and deliver a brand-damaging experience. Let’s have a quick meeting to discuss how this product—or feature—can help its intended users be more efficient, effective, and satisfied with their work. Better yet, let’s try to include a target customer in that meeting.”
• “I see where you’re coming from: senior leadership is asking for the impossible. But let’s ask them to participate in our efforts to overcome these challenging demands. If they’re able to help us connect with some target customers—and better yet, target users—that would go a long way toward helping us ensure that we not only meet their expectations but build the right thing for our users. Ultimately, that could help save the company a great deal of time, money, and effort.”

Of course, it isn’t always realistic to try to convince stakeholders to pump the brakes and take the time to connect you with users—or even to join you in dwelling on users’ needs before expecting you to hand over a UI design specification. Fear is a driving force behind many hasty timelines, and product managers avoid saying no to the C-suite out of fear that doing so might make them appear to be incapable of delivering. They want to show progress to senior leaders, which is often why they prematurely insist upon your delivering design artifacts—because they’re tangible and prove to the C-suite that things are getting done. Therefore, you might lose some battles before you finally earn adequate lead time for conducting user research and exploring users’ problems. But, by consistently reminding stakeholders and product-team members why jumping into UI design too soon can be problematic, you can gradually educate them on the differences between User Experience and UI design.

Your Colleagues Mislabel Your Role

It can be frustrating when colleagues mislabel your role. I’ve been called a graphic artist, graphic designer, UI guy, UX developer, UI designer, and everything in between. In many large enterprise organizations, User Experience is still a relatively immature function in comparison to other, more established functions, so many people are still confused by our roles or misunderstand what we do. Consider the following responses if someone mislabels your job title or role:

• “I can see how the deliverables that I produce might lead you to believe that creating them is my only job responsibility. However, they are just the tip of the iceberg. UX design also entails understanding users and their needs, conducting research studies to understand their painpoints—and how well we’re addressing them—and working closely with stakeholders and team members such as yourself to ensure that we’re all putting users’ needs first.”
• “I understand that you think UI design is my sole job function. However, the function of a UX designer is to understand users’ entire experience, which may extend far beyond just this product—or feature—and include the products or features they use preceding or following this one in their workflow journey. The byproducts of my design process might be UI mockups or prototypes, but they could also take other forms such as user stories, persona documentation, or even formal requirements documents, depending on where we’re at in our product-development lifecycle.”
• “Yes, I get that a lot. What I usually tell people is that User Experience operates at a higher level than creating the design deliverables you might see. For example, consider the users’ journeys, including the existing knowledge they possess; the processes or tools they use during, before, and after interacting with this product—or feature—and the deficiencies they experience in using them. UX design concerns include all of these factors, but the many activities that UX designers conduct—as they do research to uncover these deficiencies and try to understand why they exist—sometimes go unnoticed. The mockups you see represent our solutions for those deficiencies, but it takes a lengthy process to get there.”

Someone Assumes You Should Write Code

Asking a UX designer to write production-level code is akin to expecting a developer to perform the functions of a UX designer adequately. Of course, they may ask you to do this if they conflate User Experience with UI design, which then gets miscast further as implementing UI design. This sometimes happens on small, agile teams, on which team members are expected to fill multiple roles. Asking a UX designer to help author code might seem rational in such situations. (I would know because I’ve been in such situations and have handled HTML, CSS, and JavaScript coding duties.) But UX design cannot mature to its full potential at your company unless you educate your peers along the way. While you might not be in a position to push back when someone assumes you can or should write code and you’re supporting a small team, you should still progressively increase your colleagues’ knowledge about what UX designers do. It will pay dividends down the road. Consider the following responses:

• “For many very successful companies, a high-quality user experience is a core differentiator, and they believe their products deserve a UX designer’s dedicated time and attention. When we shoehorn UX designers into development roles, we reduce their ability to focus on the problem space and allow unconscious biases to negate what could otherwise be the most innovative solutions or those that would be most beneficial for users—or the customers who pay for our products.”
• “UX design is a robust role. A huge part of a UX designer’s responsibility is to define the problem space and understand users’ needs before proposing solutions. They then deliver their design solutions in the form of sketches, wireframes, UI design specifications, and sometimes interactive prototypes. Authoring production-quality code—especially in a world where software technologies and code libraries are evolving constantly—requires a full-time developer’s dedicated time, just as doing research to understand users’ needs and designing for them requires a full-time UX designer’s dedicated focus.”
• “A UX designer’s role focuses less on implementation than it does on illuminating users’ painpoints, goals, and needs—all of which deserve their undivided attention. While I might produce UI mockups and prototypes, authoring production-ready code requires the dedicated time and effort of a developer, whose role you should not confuse with that of a UX designer. Only a full-time developer can keep up with constant advances in technology.”

Someone Flippantly Suggests the Use of a UI Component

Off-the-cuff comments from developers and stakeholders on which component or control to use in implementing a design solution can be frustrating, especially if they do not appreciate the user’s point of view. While there could be circumstances that necessitate system- or technology-oriented stories, product requirements that focus on user-facing components and experiences must reflect their primary actor: the user. When you’re confronted with suggestions that confuse the main actor, you can ask questions such as the following:

• “Can you walk me through what the user is trying to accomplish using this feature?”
• “Who is the user in this scenario? What is her role?”
• “What is the user’s goal at this point in the workflow?”
• “How does this component help the user accomplish this task?”

While you can apply these questions in many scenarios, they are particularly useful during discussions that focus on the user interface because they pull the team out of the weeds of implementation and help them take a broader view—where users’ core workflows and goals reside. When you challenge your teammates by asking such questions, they must alter their perspectives to adequately answer them.

Writing User-Centered Requirements

As I described in my column, “Choosing Your Battles, Part 2,” it is best to involve User Experience as early as possible in the development lifecycle. Doing this can help establish your rightful role in the eyes of product managers, stakeholders, and developers. A simple way of reinforcing the role of User Experience to constituents is through writing requirements. This can help you steer the product team toward focusing more on User Experience than UI design, which then leads to more innovative outcomes and lets you educate folks along the way.

For example, many products teams have adopted agile-development methodologies and create concise user stories instead of verbose requirements documents. But user stories are still essentially requirements. Imagine that you’re part of such a team, and the product manager writes the following user story on an index card and places it on the team’s Kanban board:

“As a user, I need a progress bar to determine how long I must wait for a process to complete.”

On the surface, this story seems to make sense, right? It is written from the user’s point of view and acknowledges the user’s need. However, this story prescribes the UI component that the product manager thinks would enable the user to comprehend how a process is progressing toward its completion. Moreover, the story does not define why the user needs to determine how long the process is taking—which is important information that could reveal further information about upstream tasks and workflows that might unnecessarily result in a need for this feature. This is not a UX requirement; it is a UI requirement.

As the UX designer on this project, imagine your looking at the user’s upstream tasks and determining that this feature actually is necessary, then taking the opportunity to rewrite the product manager’s user story from a more user-centered point of view—prescribing users’ needs at a higher level and, thus, alluding to the why behind those needs. Consider the following revision:

“As a user, I need clear feedback on how long the process for [insert task] would take to complete so that I can reduce uncertainty and manage my time accordingly.”

This user story addresses the same user needs while taking into account the upstream task that necessitated this feature. However, it does not prescribe how best to facilitate users’ comprehension of a completed or running process. Too often, product teams limit themselves by failing to challenge their own assumptions. But when product teams resist the urge to prescribe literal components or controls prematurely and, instead, endeavor to define the why behind users’ needs, they open opportunities for creating solutions that deliver positive experiences with the product to users—solutions that could be innovative or save users unnecessary steps.

As I described in “Molding Yourself Into a Leader, Part 2,” a UX designer who wants to be a leader must confidently project vision to her product teams and constituents. A simple way of doing this is during the stage of requirements gathering and documentation. When you show your colleagues what a user-centered requirement or user story looks like, you challenge them to think of potentially better ways of creating delightful experiences for users. After enough repetition of this approach, your colleagues can make the leap to understanding the differences between User Experience and UI design.

Producing Deliverables That Reveal the Why Behind Your Designs

Activities such as designing UI mockups, wireframes, and user flows are often big parts of a UX designer’s job. When your product team and stakeholders review your deliverables, they often cannot help but think of the user interface because that is what they’re actually seeing. They’re seeing user interfaces with controls, form inputs, containers, widgets, and images, so you should not blame them for assuming that producing such UI-centric artifacts is a UX designer’s sole role. However, another part of your job is showing your colleagues why and how your deliverables tie back to the user’s experience.

For example, after designing a UI mockup that supports a user story, I often write that story on the mockup itself so it is visible to anyone who reviews the mockup. Providing the user story that defines the requirements for a mockup just before that mockup is a simple way of reinforcing a focus on the user experience rather than the user interface itself, which is simply a method—the how—for facilitating that experience.

But why stop there? Perhaps, after defining the requirements appropriately—in a way that focuses on the user experience rather than the user interface—you could take a photo of the Kanban card or capture a screenshot from the requirements document and paste it onto a separate page that precedes the mockup. Providing the reviewer with visual evidence that the artifact you’ve delivered is an expression—the how—of that requirement—the why would have a psychological impact. Just as with writing requirements that focus more on the user experience than the user interface, repetition helps engender adoption of this approach by other team members.

Conclusion

Patiently educating your colleagues and stakeholders about the differences between User Experience and UI design can be challenging, but is well worth your effort. Doing so helps foster understanding across product-team members and further matures User Experience throughout the company in which you work. Instead of attempting to describe the differences to people, opt for showing them progressively, through the kinds of requirements you write, the deliverables you tie back to users’ needs, and the tactful ways in which you respond to their sometimes misinformed comments, as well meaning as they might be. Continuously instructing your peers not only deepens your overall UX culture, it also tightens your working relationships with your colleagues and produces better outcomes.