When we think about UX, we need to understand the breadth of the discipline. When we talk about it and evangelize it within companies that are new to UX – such as in a 1-2 on the maturity model – we need to always refer back to the user or the customer. Another key point to remember is that Return on Investment (ROI) must always be proven.

This will result in a focus on the direction of the product and engineering groups within the organization as well. By showing depth in the research, and if your team is involved, the solution discovery process findings, you’ll be paving the way for a smoother full-cycle process of UX > Product > Engineering.

As a group of professionals who uncover or discover a hypothesis and then test its efficacy, UXers use methods and best practices to uncover the truth, which can be either positive or negative. Companies just starting down this path will incur expenses in management and individual contributor roles to start with.

So, what are the fundamentals of UX? In loose order of importance, they are research, design thinking, iteration, reporting, design, and testing. And while sprints are moving forward and we’re getting in front of users to test designs and hypotheses, we’ll consistently be watching for the universal criteria for good UX, as shown in the following figure (Credit: Usability.gov):

Figure 1.1 – UX honeycomb diagram

When I teach teams about the values shown in the preceding figure and use them in direct interviews with users, we have people rate them on a scale of 1 to 5, with 1 being the most difficult. We’ve had people ask if they can give 0 or at best 0.5! They dislike the current state of the software used in their work that much, and when we combine these numbers together for all interviews, we create a simple bar chart to show how each value scores. More about that later, in Chapter 17, The Power of Visuals to Support Cognition and Decisions.

If we go a bit further, UX is the ease of readability, the proper placement of a button, or the path from start to finish in a workflow. It’s the empathy we practice with our users so that we get them to be honest and open with us about the problems and pains they’re facing when using the software. UX is about finding what’s not working and creating a solution to fix those problems. It’s about bringing together the corporate view of a need with the contributor view to find the best possible go-forward plan.

The bottom line and key takeaway is that UX is strategy. It’s the what and the why. We’re going to do this and we’re doing it because of this reason.

Now that we have a decent understanding of what UX is, it is equally important to understand what it isn’t. UX isn’t the pixels on the page. It isn’t the code underneath or the decisions that a product team must make about how to provide the proper data to the people who need it. Yes, those decisions support the UX, but they aren’t in the realm of the UX practitioner.

The UI isn’t the UX either. While it supports the overall experience that a user has with your application, it relies on all the work done by the UX team. Wireframes are produced from research and design thinking sessions, and then tested with users to see whether the direction is correct. When there’s a greenlight to move into the development cycle, the UI designers move into action and ask questions such as the following:

• Which design system are we using for this?
• What’s the best card to use for this element?
• Is this font the right one?
• Can I place the button as specified? Can it be moved 20 pixels to the left and be approved?

Right? These people need to take what’s given from the handoff and start creating the user interface that will drive the application. They’re essentially working from a blueprint to build a house, car, or office building. They’re asking questions when a design challenge occurs and working with a UXer to ensure that the usability, usefulness, accessibility, and so on are still according to the plan – the plan, as we now know, that’s been formed from the research, design thinking, and iterations through the beginning stages of the project.

So, now let’s circle back – these things aren’t UX. UX sets the stage, but this is UI.

The bottom line and key takeaway from this section is that UI is tactics. It’s the how.

In this section, we will see a point-by-point breakdown of the differences between UI and UX. Understanding this is vitally important to a strong UX practice within an organization, and you must be able to help others understand this as well. Let’s look at these:

• UI supports UX: The user interface is what people interact with in an application. It’s the buttons clicked, the body copy and titles, the white space, and so on. If these are designed correctly, and users understand how to move around and do work, then the UI has supported the UX the way it should.
• UI and UX require different skill sets: A UI designer knows how to code, a UX designer in general doesn’t. UI designers can create CSS classes and know HTML and JavaScript. They’re responsible for creating what the UX team has specified for the design of the application. A UX team says, “This is what needs to be designed,” and the UI team does that work to tie the design into the system.

A UX person learns and understands empathy and rapport. They work directly with the user and customer to uncover problems and to ensure that the new designs are satisfying demand and expectations. True UX is more about research and iterative design phases than it is about anything else. It’s about doing the absolute best job of giving the UI team a solid start to build with, which will in turn smooth the process and allow for quicker transformation to a market-winning product.

• UI is what an application looks like: Briefly touched on earlier, what a person sees and uses is the UI – user interface. It’s the colors, the sizes of the buttons, the amount of white space on the page, and the placement of titles and paragraphs. If the UI is consistent with the company brand, then it appears to belong to that brand. If blue #6C9FB1 is your brand’s blue, and the UI team uses #317EB1, the UI isn’t correct and breaks the brand promise of the company.
• UX is how it supports the needs of the user: Go back to the meaning of UX – user experience. If the brand promise is kept, and we listened to the users and built what they said would make their lives easier, we’re creating an experience for them that satisfies them and makes it easier to do their jobs efficiently.

Next, let’s explore the roles that perform UX.

With UX becoming one of the hottest career paths in the past few years, specialties such as UX architect, UX designer, UX researcher, UX strategist, UX writer, and more are being born. And while they all do UX, their roles differ. An architect or a strategist has the broadest work priorities, while a researcher, designer, or writer has a tighter set of responsibilities.

As I mentor people who are just getting started, I advocate being a full-stack UXer – having a core strength and building on that with knowing how to do any of the other parts. Since UX is still a relatively new discipline – especially in the US – some companies will just need to hire one or two people to start building a team around. Those people will be full stack UXers. A designer alone won’t get the job nor will a researcher. If the company wants to figure it all out first, they may hire a strong strategist to start with plans, or an architect to start working with developers and engineers. A strategist that can design, do research, and write is one of the strongest UXers in the market – always.

UXers are curious by nature, I believe. They like to talk to people and help them solve problems, sometimes through rigorous and sometimes through soft inquiry. We’re comfortable expressing our views and opinions and will always be the strongest advocate for the needs of the user and/or customer. We understand that building rapport with a user will always get us the best and most honest feedback, and therefore, the best results in the final product. We’re okay with ambiguity because, at times, it’s all we’ve got. We can find a common strand of information across several planes or channels of expertise, problems, needs, and goals.

Understanding the functioning of a UX Team

A tight UX team is a cross-functional unit where all of those roles mentioned earlier work together to accomplish the goals. A researcher will rely on a designer to help turn wants and desires into beginning-level, low-rez wireframes. A strategist will brief the entire team on a direction for an upcoming project and review all the expectations and deliverables. A writer will ensure that everything is covered in reports and other collateral, and in some companies, even write all the copy, instructions, and error messages that go into an application, and if they aren’t directly responsible for those, they are advised and used as a final editor. An architect will be working closely with data and software people to ensure that the backend and frontend needs are understood and met. They will work through blockers with product and management to either pivot or figure out the best plans to get those blockers dissolved so progress can continue.

A tight UX team works well together and they work well in the collaboration that’s needed with product, engineering, marketing (at times), business development, and sales. Those companies that score highest on the maturity model understand this and it’s become the heart and core of the way the company does business. Challenges to thoughts and ideas have to be made but they’re made with respect for the others on the team. Not everyone agrees on direction, strategy, or tactics, so, we often use a design thinking session to whiteboard the situation and work through it visually. Together, as a unit, we move forward, making positive changes in the company and providing great value to the corporation.

I’ve trained teams around the world that comprise many mental model types. Engineers, Vice Presidents (VPs), tech managers, developers, designers, researchers, report writers, production line controllers, shipping clerks, and on and on. Some of them will use what they learned, and some won’t. I’ve gotten emails from managers telling me how vital the training was to their team. I’ve watched VPs and CEOs walk out of training for a break still talking about how they could have asked that question during interview training better. Or even still, being in character of the role they played when learning the skills needed to use empathy, build rapport, and get down to the honest problems that someone is having.

It’s quite remarkable to see changes within a corporation as they begin to embrace the principles of UX and support efforts to grow it to maturity for the benefit of all involved. A UX practice within a company can open opportunities they never knew existed. It can improve morale by pushing for better workflows and systems for higher productivity, and it can lead the company in the direction to cut inefficiencies and improve profits. In short, a strong UX team can be the driving force behind digital transformation to move a company to the next level.

To conclude, a UX practitioner is a curious, empathetic, and diligent seeker of problems to solve.

In this chapter, you learned how to tell the difference between UX and UI, and to identify what types of roles practice the UX discipline. You also learned the starting basics of what a UX team is and how they function within an organization.

These points are important to you because UX is gaining momentum as a mature and important practice in companies across the globe, and if you know this going into a new role or even being tasked with expanding UX within your organization, you’ll be successful much more quickly than if you didn’t have this core understanding.

In the next chapter, we begin to dive into the core fundamentals of UX analytics. We’ll uncover the two main types of metrics we use to measure and assess current performance and users’ usage patterns, while we gain an understanding of research readouts.