This guide is for anyone who designs software products as part of their work. You may be a full-time designer, a UX professional, or someone who has to make decisions about UX in your organization’s products. Regardless of your role, the principles in this guide will improve your products, help you to serve your users’ needs better, and make your customers more likely to return to you.

Although various examples in this book feature a mobile app, website, web app, or some desktop software, the principles are ready to be tailored to a wide range of applications, from in-car UIs, mobile games, and VR, to washing machine interfaces and everything in between.

Developing the primary skills of empathy and objectivity is essential for anyone to be great at UX. This is not to undermine those who have spent many years studying and working in the UX field—their insights and experience are valuable—rather to say that study and practice alone are not enough.

You need empathy to understand your users’ needs, goals, and frustrations. To “walk a mile in their shoes” requires you to approach user problems with respect—they’re not stupid, your software is just too hard to use. You need objectivity to look at your product with fresh eyes, spot the flaws, and fix them.

User testing is essential and will reveal flaws you never imagined were there—talk to users early and often. It’s easier to fix a product at the beginning—and almost impossible to fix at the end.

With this foundation of empathy and objectivity, you can learn everything else it takes to be great at UX.

Learning points

• UX isn’t a talent you’re born with—you can learn how to be good in this field.
• Objectivity and empathy are the two key personality traits you need to display—your problems and needs aren’t always the same as your users’.
• This book aims to provide a shortcut to success with 101 tried-and-tested principles.

The principles we look at in this book are great and all, but how do we put them into action? Since the first edition of this book was released in 2018, the number 1 question I’ve been asked is a variation of “How do I put these principles into practice in my day-to-day work?” The best intentions of a principled UX professional are one thing, but the messy reality of working in a modern business is quite another. Here are the best tips I’ve successfully used over the years:

1. Fight for the user. Day-to-day business involves competing departments and priorities. KPIs and OKRs are fine for marketing and sales departments, but your job is to fight for the user—putting their needs front and center of the plans. Sometimes this will mean clashing with other teams, it’s unavoidable, and you won’t win every battle—but it’s important you’re there and your voice is heard. The sales team has goals to hit, but your job is to convince them—with best practice and data—that a full-screen unskippable video advert will do more to drive customers away than engage them.
2. Build allies in your organization. The most effective way to “get UX done” in an organization is to build allies across the business. Product managers, developers, and senior stakeholders (yes, including the “C-level” suits) all need to be onside and understand the value of UX. Take them along on your process.
3. Understand the business goals. You’re the voice of the user, but you can’t work in a vacuum—you need to understand the business goals and the plans for your products and services. You won’t survive for long if you’re just the voice of the user without enabling results for the business. Engage with product managers and help shape the roadmap and business plan.
4. Build a culture of user research. Involve your colleagues in user research, bring them to testing sessions, and disseminate your results to a wide group of people. UX designers and product people alike should be thinking about user needs and testing ideas with them every step of the way. Finally, bring these ideas back to the stakeholders in the business: there’s nothing as powerful in changing a CEO or CMO’s mind than presenting them with a trove of research findings from real customers.
5. Drive data-driven decisions. Use data to steer your high-level decision-making—this point is less about qualitative data (data you can describe with language, not numbers) from user testing, and more about quantitative data (data you can measure with numbers) from analytics and other metrics. Use this data to help you make better decisions in terms of product features, missing services, and whole approaches to doing business.

Learning points

• Fight for the user
• Build allies in your organization
• Understand the business goals
• Build a culture of user research
• Drive data-driven decisions

One of the (many) great things to come out of the software industry’s adoption of Agile methodologies in the early 2000s is the behavior of shipping early and often. From the Agile Manifesto principles:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

– Agile Manifesto,https://agilemanifesto.org/principles.html

You don’t wait for a “big bang” release; you don’t perfect every aspect of your product—you release valuable software out to users as soon as it’s ready, and you update it continuously. Some of the ways that this principle is often violated in modern software development are:

• You want to add just one more feature before you think the product is ready
• The marketing team wants to wait until the campaign is ready to promote the feature
• Your competitor offers more features and you need to match them

Trust me—your users don’t care about these reasons. Your product doesn’t need to be a whole new category of product; it just needs to help users get their shit done. Fewer, better features are better for the user experience than trying to cram too much in, pushing deadlines and developers until your user ends up with 100 half-baked features instead of 25 excellent ones—and a later release date.

Try to remember that, in most cases, most users will only use your app for 1% of their day—you work in it all the time so it’s easy to lose objectivity. Ask yourself: “Do we really need Y? Would users be happier with a better X?”

Create a well-researched, well-defined scope for your first version, so that—when stakeholders inevitably get the fear about missing features compared to competitors—there is justification and strategy for continuing with the minimal version release and then iterating later based on what you learned.

Learning points

• Keep it simple; don’t reinvent the wheel
• Ship early and often, delivering valuable features
• Don’t chase competitors’ feature sets; sometimes less is more

A few years back I did some work for an insurance company—I know, I get all the exciting projects, right? The software was a web-based UI that call center staff used to manage incoming customer inquiries. In this web application I was tasked with improving, a customer would call up to change their policy, or get a new one, cancel their cover, and so on, and the user would need to search, edit, save, or delete as necessary.

It had recently undergone a redesign and my job was to work with users to understand how successful the redesign had been and what features were succeeding and which weren’t. The new UI was clean, modern, airy—based on Material Design, with lots of negative space and big, clear typefaces.

It turned out that all the users hated the new system. The information density was too low. Instead of seeing all the customer information on one (or two) screens, tightly packed together, the user now had to navigate through multiple screens, scrolling view after view to see the details they needed. They even had to navigate back and forth between two views—waiting on the page load each time—to do basic things like checking a policy expiry date.

Nobody had asked users, “What is wrong with the current system?” Instead, they optimized the new design for user needs that didn’t exist (see #6, Test with Real Users).

Many skilled users who work in an enterprise environment rely on software to do lots of the same thing, repeatedly. Making enterprise software too simple—by trying to be more “consumer-looking”—just hides necessary functions away from the user and makes it frustrating and slow, increasing cognitive load.

For example, an aircraft cockpit is dense and complex—but it needs to be, because complexity is good for these users:

Figure 4.1: Look at all those controls. Image by Honglin Shaw on Unsplash

Similarly, professional audio tool Ableton Live has a dense, complex interface, but musicians spend all day, every day here and love the productivity it offers:

Figure 4.2: Ableton Live UI

Learning points

• Be wary of making complex products too “consumer-looking” and simple
• Don’t follow trends; focus on what your user needs
• Complexity doesn’t always mean a bad user experience

We can learn a great deal from our users with interviews and feedback studies, but it’s hard to achieve a large scale with these techniques—it’s just too time-consuming to talk to 1,000 or 100,000 users. A/B testing (where you compare two designs) and multivariate testing (where you change multiple design elements), are a great way to gather results and test your designs with large audiences because they can be run by robots, not humans.

A/B testing is a technique that involves splitting a user base into two groups or populations and showing two different designs (“A” and “B”) to each group to see which design performs better. A/B testing gives the best results with larger populations of users; over 1,000 is a good sensible minimum to give meaningful results.

It’s that simple: set up two different versions of your UI and use some software (many free and paid services are available) to serve them equally to visitors. Tag each group with a label in your analytics software and you can see easily which design performed better against your chosen conversion metric: whether that’s checkout conversions, sign-ups, or something else.

Start with a hypothesis to test. In the example below: “We suspect that making the purchase more instant and presenting the option in a brighter color will cause more checkout conversions.”

Figure 5.1: Run version A and B past 1,000 users and see how many ducks you sell for each cohort

All well and good, and a useful research tool to have in your UX research toolbox. One last word on ethics—make sure you’re helping the user, not just optimizing for company needs. That way lie deceptive patterns (see #101, Don’t Join the Dark Side).

Learning points

• Use A/B testing to work out which design performs better
• Make sure “performs better” means the design performs better for the user
• A/B testing works well with two distinctly different designs, rather than just tiny changes

Nothing in this book means anything unless you test with real people. Moreover, you need to test with real users: not your colleagues, not your boss, and not your partner. You need to test with a diverse mix of people, from the widest section of society you can get access to (within your target audience, of course).

User testing is an essential step to understanding not just your product, but the users you’re testing—what their goals really are, how they want to achieve them, and where your product delivers or falls short. You’ll not only understand your users better, but you’ll reduce development time by short-circuiting the feedback loop and getting problems fixed much earlier in the product life cycle.

It’s never too early to start testing—an unfinished prototype or even paper prototype (cards or notes that you move around on a desk) can yield valuable insights—so get your product in front of users as soon as you can. Additionally, you can save yourself (and your developers) a huge amount of work and rework by heading in the right direction early, rather than making lots of false starts.

So, what are you testing? User tests are, in themselves, a broad spectrum of activities ranging from “guerilla-style” tests—where you approach a random person and ask them to perform a task in the app—through to specific feature-based tests, where an expert user (usually with domain knowledge) is asked to perform a complex task. Either way, you need to start with an idea of what you’re testing, tuned to both the complexity level of the product and the domain knowledge that a user needs to operate it.

A few of the most common usability testing methods are:

• Guerilla testing: informal and ad hoc, as mentioned above. This method is cheap, rapid, and great for getting an early steer on your proposed solutions.
• Lab tests: performed in controlled conditions with a moderator. This method provides greater insight into the users’ motivations, but they can be costly and slow to yield results.
• Remote testing: performed unmoderated, where the user is left to their own devices. This method does not provide the same depth of feedback, but you can scale these tests up to thousands of participants.

There’s a myth that user testing is expensive and time-consuming, but the reality is that even very small test groups (fewer than 10 people) can provide fascinating insights. The nature of tests with a small number of participants is that they don’t lend themselves well to quantitative analysis, but you can get a lot of qualitative feedback from working with a small sample set of fewer than 10 users.

There’s research to show that testing with as few as five users will uncover 85% of usability problems in a single test. This startlingly high number is arrived at thanks to the Poisson distribution and some math.

Too often, products aren’t tested, the thinking being that “we’ll just hear what users don’t like and fix it.” The problem is that your users won’t tell you; they’ll just leave. The near-infinite choice of products and services on the web, app stores, and a myriad of devices means that the user has no incentive to stay, complain, and help you to improve your product—it will simply fail.

The cost of switching to an alternative for a user is almost zero—a quick Google for a competitor and they’re gone for good. Test with real users and listen to them, and you’ll build something they love.

Learning points

• Test your product early and with real users within your target audience
• Test with a diverse group of people from different ethnicities, ages, genders, and backgrounds
• You only need to test with a small group to get huge benefits

I don’t mean brand in the sense of visual identity—a good logo, wordmark, or tagline is a great idea. I mean brand in the modern sense—a woolly definition that’s come to be commonplace over the past 10 years or so.

The word brand has come to allude to the company or to stand for the entire personality of a corporation or product . It is seen as the “feeling” of interacting with products and services, and inevitably the core interactions of those products.

The problem with this approach, developed for over a decade by multinational branding corporations and advertising agencies, is that we already have a discipline for this: UX. By crafting a product to adhere to a brand (in the modern sense of the word), we defer control of the UX to the marketing and branding teams, not the UX professionals.

I’m not talking either about the megabrands with a billion customers; Apple, Google, Coca-Cola, Microsoft, Nike, and so on are so big and their brands so powerful that it does and should make a difference when it comes to how their products are designed.

What about your brand, with a few thousand or tens of thousands of customers, or your small company, product, or newly launched start-up? Nobody cares. Harsh, but true. None of your users care about your brand. They care about what your product or service lets them do. They care about how your product improves their lives and enhances their productivity, and so on.

The experience of your product is your brand and it shouldn’t be designed by a marketing team, but by UX people. This is also your competitive advantage against the big, lumbering dinosaurs that have to adhere rigidly to brand guides.

Don’t let the brand guide ruin your product with:

• Unreadable brand typefaces: Just use the native system font stack.
• Branded splash screens: Just show me the damn app.
• Build-your-own nightmarish UI controls: Oh, the things I’ve seen…
• Awful, unreadable contrast ratios : Don’t stick to the brand palette if it doesn’t work in your product.
• Unnecessarily quirky copy: The wacky humor on the side of a smoothie bottle—just get to the point!

A brand can help to enforce consistency, but, if you’re a decent designer, you shouldn’t need a brand guide to tell you how to build a consistent UI. Brands are bullshit, so focus on the UX and the experience becomes the brand.

Learning points

• Nobody cares about your brand, only about what your product lets them do
• A good UX is better than a good brand
• Fight for the user, not the brand guide