Smart Interface Design Patterns

How To Measure The Impact Of Features

Vitaly Friedman — Mon, 09 Mar 2026 00:00:00 +0000

So we design and ship a shiny new feature. How do we know if it's working? How do we measure and track its impact? There is no shortage in UX metrics, but what if we wanted to establish a simple, repeatable, meaningful UX metric — specifically for our features? Well, let's see how to do just that.

With TARS, we can assess how effective features are and how well they are performing.

I first heard about the TARS framework from Adrian H. Raudaschl's wonderful article on How To Measure Impact of Features. Here, Adrian highlighted how his team tracks and decides which features to focus on — and then map them against each other in a 2×2 quadrants matrix.

It turned out to be a very useful framework to visualize the impact of UX work through the lens of business metrics. Let's see how it works.

👩🏻‍🦱 1. Target Audience (%) #

We start by quantifying the target audience by exploring what percentage of a product's users have the specific problem that a feature aims to solve. We can study existing or similar features that try to solve similar problems, and how many users engage with them.

Target audience isn't the same as feature usage though. As Adrian noted, if we know that an existing Export Button feature is used by 5% of all users, it doesn't mean that the target audience is 5%. More users might have the problem that the export feature is trying to solve, but they can't find it.

Question we ask: "What percentage of all our product's users have that specific problem that a new feature aims to solve?"

🗂 2. A = Adoption (%) #

Next, we measure how well we are "acquiring" our target audience. For that, we track how many users actually engage successfully with that feature over a specific period of time. We don't focus on CTRs or session duration there, but rather if users meaningfully engage with it. E.g. if anything signals that they found it valuable — sharing the export URL, number of exported files, usage of filters and settings.

Adoption rates — from low adoption (<20%) to high adoption (>60%). Illustration by Adrian Raudaschl.

High feature adoption (>60%) suggests that the problem was impactful. Low adoption (<20%) might imply that the problem has simple workarounds which people have relied upon. Changing habits takes time, too, and so low adoption in the beginning is expected.

Sometimes low feature adoption has nothing to do with the feature itself, but rather where it sits in the UI. Users might never discover it if it's hidden, or if it has a confusing label. It must be obvious enough for people to stumble upon it.

Low adoption doesn't always equal failure. If a problem only affects 10% of users, hitting 50–75% adoption within that specific niche means the feature is a success.

Question we ask: "What percentage of active target users actually use the feature to solve that problem?"

🗃️ 3. Retention (%) #

Next, we study if a feature is actually used repeatedly. We measure the frequency of use, or specifically, how many users who engaged with the feature actually keep using it over time. Typically it's a strong signal for meaningful impact.

If a feature has >50% retention rate (avg.), we can be quite confident that it has a high strategic importance. A 25–35% retention rate signals medium strategic significance, and retention of 10–20% is then low strategic importance.

Question we ask: "Of all the users who meaningfully adopted a feature, how many came back to use it again?"

❤️ 4. Satisfaction Score (CES) #

Finally, we measure the level of satisfaction that users have with that feature that we've shipped. We don't ask everyone — we ask only "retained" users. It helps us spot hidden troubles that might not be reflected in the retention score.

We ask users how easy it was to solve a problem after they used a feature. Illustration by Adrian Raudaschl.

Once users actually used a feature multiple times, we ask them how easy it was to solve a problem after they used that feature — between "much more difficult" and "much easier than expected". We know how we want to score.

Using TARS For Feature Strategy #

Once we start measuring with TARS, we can calculate an S÷T score — a percentage of Satisfied Users ÷ Target Users. It gives us a sense of how well a feature is performing for our intended target audience. Once we do that for every feature, we can map all features across 4 quadrants in a 2×2 matrix.

Evaluating features on a 2×2 matrix based on S/T score. Illustration by Adrian Raudaschl.

Overperforming features are worth paying attention to: they have low retention but high satisfaction. It might simply be features that users don't have to use frequently, but when they do, it's extremely effective.

Liability features have high retention but low satisfaction, so perhaps we need to work on them to improve them. And then we can also identify core features and project features — and have a conversation with designers, PMs and engineers on what we should work on next.

Conversion Rate Is Not a UX Metric #

TARS doesn't cover conversion rate, and for a good reason. As Fabian Lenz noted, conversion is often considered to be the ultimate indicator of success — yet in practice it's always very difficult to present a clear connection between smaller design initiatives and big conversion goals.

Leading vs. Lagging Measures by Jeff Sauro and James R. Lewis. (But please do avoid NPS at all costs).

The truth is that almost everybody on the team is working towards better conversion. An uptick might be connected to many different initiatives – from sales and marketing to web performance boost to seasonal effects to UX initiatives. UX can of course improve conversion, but it's not really a UX metric. Often people simply can't choose the product they are using. And often a desired business outcome comes out of necessity and struggle, rather than trust and appreciation.

High Conversion Despite Bad UX #

As Fabian writes, high conversion rate can happen despite poor UX, because:

Strong brand power pulls people in,
Aggressive but effective urgency tactics,
Prices are extremely attractive,
Marketing performs brilliantly,
Historical customer loyalty,
Users simply have no alternative.

A practical overview of design metrics and UX scorecards: Measuring UX: Your First Step Towards Objective Evaluation by Roman Videnov.

Low Conversion Despite Great UX #

At the same time, a low conversion rate can occur despite great UX, because:

Offers aren't relevant to the audience,
Users don't trust the brand,
Poor business model or high risk of failure,
Marketing doesn't reach the right audience,
External factors (price, timing, competition).

An improved conversion is the positive outcome of UX initiatives. But good UX work typically improves task completion, reduces time on task, minimizes errors and avoids decision paralysis. And there are plenty of actionable design metrics we could use to track UX and drive sustainable success.

Wrapping Up #

Product metrics alone don't always provide an accurate view of how well a product performs. Sales might perform well, but users might be extremely inefficient and frustrated — yet the churn is low because users can't choose the tool they are using.

Design KPIs and UX Metrics, a quick overview by yours truly. Numbers are of course placeholders. Large view.

We need UX metrics to understand and improve user experience. What I love most about TARS is that it's a neat way to connect customer's usage and customer's experience with relevant product metrics. Personally, I would extend TARS with UX-focused metrics and KPIs as well — depending on the needs of the project.

Huge thanks to Adrian H. Raudaschl for putting it together — and if you are interested in metrics, I highly recommend you to follow him for practical and useful guides all around just that! 👏🏼👏🏽👏🏾

Useful Resources #

How To Measure UX and Design Impact, by yours truly
Business Thinking For Designers, by Ryan Rumsey
ROI of Design Project
How the Right UX Metrics Show Game-Changing Value, by Jared Spool
Research Sample Size Calculators

Designing Better Loading and Progress UX

Vitaly Friedman — Wed, 04 Feb 2026 00:00:00 +0000

As designers, often we can't speed up interactions for technical reasons. But we can reduce the perceived waiting time, which is often way more important than the actual duration.

But how do we reduce the frustration of waiting? Let's explore a couple of options and UX guidelines to consider — to reduce the impact of waiting and choose the right loading indicator based on anticipated wait time.

Improve user experience with smarter loading indicators tailored to task duration and type.

The Psychology of Waiting #

Nobody likes to wait. Especially when it's not clear how much is left to wait, and if there is any progress at all. However, not every waiting is the same. The perception of waiting time is typically way more important than its actual duration.

There are 2 types of waiting that we experience:

Passive waiting (standing still)
Active waiting (walking, interacting, being busy)

Progress bars significantly reduce perceived wait time and abandonment. A study on Tolerable waiting time and the impact of feedback on user tolerance by Fiona Fui-Hoon Nahassessed.

Research shows that we tend to overestimate passive waiting by a significant margin (36%) (Katz et al., 1991), so mundane waiting usually feels much longer than it actually is. Active waiting, on the other hand, usually feels much shorter — even although it isn't necessarily true.

Changes in speed are perceived differently, too. Small optimizations in speed, like shaving 0.2 seconds off a 5-second wait, typically go unnoticed by users. We usually speak about the 20% rule: users only notice speed changes of at least 20%.

Choosing The Right Loading Indicator #

When we design loading experiences, we must always answer 2 key questions: "How much longer will this take?" and "Is it actually working?" Typically this means adding signals about progress — a loading bar and a status update.

There is no shortage in loading indicators, but some might work better than others.

When we are choosing a loading indicator, we actually design not that indicator — we are designing the waiting UX. The less that waiting feels like passive waiting, the better. And typically it means keeping people busy while something is happening in the background.

Different loading indicators serve different purposes, and are used for different thresholds. By Taras Bakusevych.

We choose the right loading indicator based on the anticipated waiting time:

No wait (< 1 sec):
Don't use any loading indicators. They won't be perceived in time, and only cause visual noise.
Short wait (1–3 secs):
Use skeleton screens or looping spinners.
Medium wait (3–10 secs):
Determinate progress bars that show how much is left.
Long wait (10+ secs):
Show progress bar, percentage, status update.

Headspace uses a skeleton screen to build users' expectations for the structure of the page. These days it's a common way to indicate progress as the application is loading.

For long wait times, it's a good idea to not only show detailed progress, but also allow users to interact with other parts of the application or offer options for what to do next. Keeping people busy works best.

Reducing Perceived Waiting Time #

Uncertainty amplifies waiting discomfort. But when a product signals and visualizes progress, users tend to accept longer waiting time because they have right expectations and can track that progress as it's happening (Buell & Norton, 2011).

The different flavors of waiting UX — dynamic, determinate indicators typically work well for longer waiting times. By Denys Mishunov.

One interesting technique to reduce perceive waiting time is optimistic UI. There, we allow users to proceed with next steps or interactions while a background process continues. Basically we shift from passive waiting to active waiting, again, by keeping users busy.

We know it intuitively, but it's worth mentioning nevertheless: the more valuable the reward for completing a task, the higher the user's tolerance for waiting. So if we communicate that the waiting will be worth it, it might be helping to nudge user to wait a little bit longer.

Always Start Early #

Research also shows that waiting to start a task feels longer than waiting for it to finish, so initiating tasks early can minimize frustration. For example, we perceive loading slightly faster if the progress bar moves faster at the beginning and slows down at the end, rather than moving at a constant speed.

The UI Stack: we need to design not only ideal and error states, but also loading state and partial state. By Scott Hurff.

We also need to be mindful of "queue jumping": when a task that started later finishes before one that started earlier. That's when users lose trust and confidence in the system as they no longer know if everything actually worked as expected.

TL;DR Useful UX Guidelines #

Match the indicator to the wait time. The choice depends on how long you expect users to wait.
Spinners work for short, repetitive tasks. Avoid multiple spinners on one page.
Skeleton screens work better than spinners. They make the load feel faster and more structured.
Show indicator where they will appear. For "scroll up to refresh" the indicator should be at the top; for pagination or infinite scroll, it should be at the bottom.
Design background operations: For long processes (e.g. video export), collapse the task into a background state, so the user isn't "blocked" from using the rest of the application.

Wrapping Up #

While these strategies might not make your application faster, they will make it feel faster — and it could be enough to keep users on the page for just a little bit longer, and drive them to success from there.

Just keep in mind: you are not designing a regular UI component. You are designing the waiting UX. And the best experience is when users never experience it. But if they must, make sure it's worth the waiting.

Useful Resources #

Part 1: The Perception Of Time, by Denys Mishunov
Part 2: Perception Management, by Denys Mishunov
Part 3: Tolerance Management, by Denys Mishunov
Part 4: True Lies of Optimistic Interfaces, by Denys Mishunov
Loading and Progress Indicators UX, by Taras Bakusevych
Everything You Need to Know About Skeleton Screens, by Bill C.
Progress Indicators Make a Slow System Less Insufferable, by Katie Sherwin, NN/g
Loading Feedback in Enterprise UX, by Fanny Vassilatos, Ceara Crawshaw
How To Fix a Bad User Interface, by Scott Hurff

Combobox vs. Multiselect vs. Listbox

Vitaly Friedman — Mon, 02 Feb 2026 00:00:00 +0000

So what's the difference between combobox, multiselect, listbox and dropdown? While all these UI components might appear similar, they serve different purposes. The choice often comes down to the number of available options and their visibility.

Let's see how they differ, what purpose they serve and how to choose the right one — avoiding misunderstandings and wrong expectations along the way.

And the confusion begins: Listbox, Combobox, Multiselect, Dual Listbox.

Not All List Patterns Are The Same #

All the UI components highlighted above have exactly one thing in common — they support user's interactions with lists. However, they do so slightly differently.

Let's take a look at each, one by one:

Dropdown → list is hidden until it's triggered.
Combobox → type to filter + select 1 option.
Multiselect → type to filter + select many options.
Listbox → all list options visible by default (+ scroll).
Dual listbox → move items between 2 listboxes.

Watson design system with grouping inside of its combobox pattern.

In other words, Combobox combines a text input field with a dropdown list, so users can type to filter and select a single option. With Multiselect, users can select many options (often displayed as pills or chips).

Listboxes display all list options visible by default, often with scrolling. It's helpful when users need to see all available choices immediately. Dual listbox (also called transfer list) is a variation of a listbox that allows users to move items between two listboxes (left ↔ right), typically for bulk selection.

Never Hide Frequently Used Options #

As mentioned above, the choice of the right UI component depends on 2 factors: how many list options are available, and if all these options need to be visible by default. All lists could have tree structures, nesting and group selection, too.

MongoDB design system with nested filters and chips.

There is one principle that I've been following for years for any UI component: never hide frequently used options. If users rely on a particular selection frequently, there is very little value in hiding it from them.

We could either make it pre-selected, or (if there are only 2–3 frequently used options) show them as chips or buttons, and then show the rest of the list on interaction. In general, it's a good idea to always display popular options — even if it might clutter the UI.

How To Choose Which? #

Not every list needs a complex selection method. For lists with fewer than 5 items, simple radio buttons or checkboxes usually work best. But if users need to select from a large list of options (e.g. 200+ items), combobox + multiselect are helpful because of the faster filtering (e.g. country selection).

A matrix of options, broken down by single- or multi-selection and static or scrollable view. By Anna Kaley, from NN/g.

Listboxes are helpful when people need to access many options at once, especially if they need to choose many options from that list as well. They could be helpful for frequently used filters.

Dual listbox in action: it can be very helpful when assigning tasks or permissions. That's why it's "Transfer List". Example from Mantine.

Dual listbox is often overlooked and ignored. But it can be very helpful for complex tasks, e..g bulk selection, or assigning roles, tasks, responsibilities. It's the only UI component that allows users to review their full selection list side-by-side with the source list before committing (also called "Transfer list").

In fact, dual listbox is often faster, more accurate and more accessible than drag-and-drop.

Usability Considerations #

One important note to keep in mind is that all list types need to support keyboard navigation (e.g., ↑/↓ arrow keys) for accessibility. Some people will almost always rely upon keyboard to select options once they start typing.

Keyboard navigation is often in use with any kind of lists. Example: Watson.

Beyond that:

For lists with 7+ options, consider adding "Select All" and "Clear All" functionalities to streamline user interaction.
For lengthy lists with a combobox, expose all options to users on click / tap as otherwise they might never be seen,
Most important, don't display non-interactive elements as buttons to avoid confusion — and don't display interactive elements as static labels.

Names matter. A vertical list of options is typically described as a "dropdown" — but often it's a bit too generic to be meaningful. "Dropdown" hints that the list is hidden by default. "Multiselect" implies multi-selection (checkbox) within a list. "Combobox" implies text input. And "Listbox" is simply a list of selectable items, visible at all times.

The goal isn't to be consistent with the definitions above for the sake of it. But rather to align intentions — speak the same language when deciding on, designing, building and then using these UI components.

It should work for everyone — designers, engineers and end users — as long as static labels don't look like interactive buttons, and radio buttons don't act like checkboxes.

Useful Resources #

Autocomplete: UX Guidelines, by Vitaly Friedman
Combobox, by eBay 👍
Combobox, by Elastic
Combobox, by Elisa
Combobox, by MongoDB 👍
Combobox, by Visa 👍
Combobox, by Watson (Docplanner)
Combobox, by Wikimedia
Combobox, by Zendesk
Multiselect (MongoDB Combobox Design Docs), by MongoDB 👍
Multiselect Lookup, by Wikimedia
Multi-select Combo Box, by Vaadin
Multiselect, by Visa
Transfer (Listbox example), by Ant Design
Listbox, by Hopper
List Box, by Vaadin
Listbox, by Visa
Dual List Selector, by Red Hat (PatternFly)
Dual Listbox, by Salesforce (Lightning Design System)
Transfer List, by Mantine
Dual Listbox, by Dashlite
Badges vs. Pills vs. Chips vs. Tags, by Vitaly Friedman
Listboxes vs. Dropdown Lists, by Anna Kaley (NN/g)

Designing For People With Dementia

Vitaly Friedman — Tue, 20 Jan 2026 00:00:00 +0000

Design is often an exercise in resilience. Our products must work for people in any life situations they find themselves. A path there always lies through accessible, inclusive design — that makes it more difficult to make mistakes.

One frequently overlooked condition is dementia. How we can design better experiences for people with severe challenges around memory and thinking? Well, let's find out.

Design with empathy: a powerful approach for developing dementia-friendly products and services. Practical guide PDF.

What Exactly Is Dementia? #

Dementia is a syndrome that significantly affects memory, thinking and social interactions. It affects 55 million people globally and that number will reach 139 million by 2050. Alzheimer's disease is the most common cause for dementia (around 60–80% of all cases).

The syndrome comes slowly and unexpectedly, typically around the age of 65, but early-onset dementia can also occur between 45–65 years (9%). Usually it starts showing in confusion, disorientation, language and difficulty with sequenced actions (like cooking).

A practical overview of UX guidelines on how to design with and for people affected by dementia. Practical guide PDF.

That's when shiny surfaces look wet and dark mats look like holes. And sometimes it's simply forgetting what a microwave beep means. In such situations many people feel incredibly embararassed, so they mask symptoms for months and years — writing extensive notes to "make up" for memory loss or avoiding phone calls.

As dementia progresses, it's becoming impossible to remember recent events or recall information. Following multi-step instructions is hard (e.g. cooking a meal) — but even counting coins or cutting and pasting text can be difficult.

Design Patterns For People With Dementia #

Here are considerations that we need to keep in mind for more inclusive experiences — they are quite broad accessibility needs:

Avoid auto-moving carousels or moving, flashing content. They are very distracting and are likely to cause task abandonment.
Don't rely on working memory. Instructions often get lost between the screens. If something is important to know, show it. Keep details needed to act available for look-up.
Leave traces of what happened. E.g. it's not a good idea to clear search query after it's executed, or use an overlay that covers information that a user needs to reference.
Avoid patronizing language: "sweetie", "well done", "really good job!".
Always add text labels to icons, especially the abstract ones. People learn icons, but just as well they forget them and get lost between them.
Buttons and inputs need borders, min 44×44px touch targets. White buttons with subtle shadow on white background are difficult to spot.
Test legibility of web fonts. Use the text snippet 1Il0O to test legibility — individual characters must be distinguishable. Line height of 1.5+ prevents lines from "swimming" together.
Favor left-aligned text: justified text creates "rivers of white" that are highly distracting.
Avoid generic labels ("Submit", "Confirm", "Proceed"). Better use descriptive, verb-based labels, e.g. "Finish and Send".
No puzzles/CAPTCHAs: these are cognitive blockers (WCAG 2.2).
Forgiving inputs: Allowing variations in data entry and toggle passwords for easier access.

Accessible doesn't mean boring. The ambition was to create an accessible, inclusive UX that is also exciting and bold. Wise case study.

A point I'd like to raise is that memory tests, image recognition tests and puzzles proactively exclude people with cognitive disabilities. And, as stated in WCAG 2.2, we need to avoid password-only authentication with alternative ways — password managers, social login and biometric auth. Password-only systems are often cognitive traps for dementia users.

Also, around ~15% of dementia users also have motor impairments or low vision. They navigate entirely with keyboard or adaptive devices. Steph Walter highlighs use cases for cognitive accessibility in post on neurodiversity and UX.

Dignified Experience and Sense of Independence #

When we think about users with dementia, we might instinctively consider a "simple" version of the product that strips all details and all complexities away. However, an oversimplified version is likely to lead to more, not fewer, mistakes.

Users with dementia don't need a barebones version of your product. They need resilient, error-proof paths to follow — with a respectful, helpful, dignified UX and a sense of independence, even if the mind changes frequently.

Wrapping Up #

It's important to understand that dementia fluctuates (good days vs. bad days) but the long-term trajectory is downward. Still, it's a condition where capability can be highly fluid and highly dependent on user's environment. Creating order around tasks helps.

Just like any other group, older users need a reliable, clear product that helps them feel independent and competent. Bring people living with dementia in your design process to find out what their specific needs are.

"Nothing about us without us": you can't design for people without designing with them.

And huge kudos to wonderful people contributing to a topic that is often forgotten and overlooked. 👏🏼👏🏽👏🏾

Useful Resources #

Dementia Diaries (audio diaries recorded by people living with dementia)
Free Webinar: Dementia-Friendly Design, by AbilityNet
Making memory loss easier for families, UX case study, by Sean Rockwood
Dementia Digital Design Guidelines, by Rik Williams
Designing for Dementia, by AbilityNet
Practical guide to designing products for people with dementia, by Alzheimer's Society
MinD: Designing for People with Dementia
Designing For Dementia: 9 Tips To Improve Environments
Dementia-friendly Service Design, by Alzheimer's Society
DEEP Guide: Language and Dementia
W3C Cognitive Accessibility Guidance (COGA)

How We Brainstorm And Choose UX Ideas

Vitaly Friedman — Thu, 15 Jan 2026 00:00:00 +0000

Many brainstorming sessions are an avalanche of unstructured ideas. They are mostly based on hunches, assumptions and grandiose but impossible ideas.

Just like we need constraints to be intentional in our design decisions, we need structure to mold realistic and viable ideas. But how do we do that? Well, let's figure it out.

From collecting data to HMW to prioritizing concepts: a detailed visualization of the brainstorming process by Booking.com. Large view.

Giving People Time To Think #

In the messiness of idea generation, we often forget that people need time to think to come up with good ideas. Different people think differently, and they need different amount of time.

Some people think better at home in early mornings, others think best at their workspace, and others just before falling asleep or walking outside. Their ideas can be vastly different and vastly divergent — and that's exactly what we aim for with brainstorming.

Yet in many companies ideation sessions limit these explorations by running collaborative exercises too early.

Silent Brainstorming #

One of the impactful changes I've noticed is just how helpful it is to give people time to think about a problem in silence, on their own, alone with their own thoughts — before jumping into groupthink and collaborative work.

A helpful thing to do is to give people time and space to come up with ideas without enforcing physical or spacial boundaries on them. We could send them an overview of what to brainstorm on ahead of time, along with the context and established goals.

Once everybody has thought about a problem independently, bring all the ideas together. We can then run collaborative exercises to find the direction, and perhaps synthesize ideas or resolve opposite directions. But: we need to see how it might fit in the overall brainstorming format.

Booking.com's Brainstorming Model #

A few years ago I've stumbled upon Booking.com's model to generate ideas more effectively. It's a quite simple process which actually makes ideation slightly more intentional and less chaotic.

Brainstorming starts with a good preparation. We study past research and gather all relevant data for the following 3 pillars:

3 pillars of brainstorming: users, business and competition. Large view.

User pain points and needs
Past research, user needs relevant to the topic.
Business goals and needs
Perspective from PMs, business leaders on main product and business goals.
Competitive landscape
Competitors' features and their product reviews, social media.

All these insights land on a Miro board, with one note per data point and one unique color fo each pillar. It makes sorting and grouping them later much easier.

Once all data points are collected, we send invitations to people who need to be involved in brainstorming — not just designers, but also product, marketing, engineering folks who can contribute relevant insights and perspectives.

Individual Thinking First #

The brainstorming session starts by reiterating context about the problem and the goals. We read all notes, one by one, discuss collected data points and then invite participants to form themes around them silently, independently first.

Personally, I'd love participants to already have them ready, and already have it on the Miro board before the start of the session. But it's useful to give people time to think about it a bit more before moving to ideation.

Clustering data points into themes, by relevance. Large view.

Once it's done, we build small groups of 3–4 people max to discuss proposed theme names and where data belongs to. The goal is to have the smallest meaningful number of themes.

How Might We" (HMW) statements #

Next, we could reframe each theme as a "How Might We" (HMW) statement. We start with the problems or insights we've uncovered during your research, and then focus on ideas with desired outcomes, rather than just symptoms.

Reframing every theme as a HMW statement and ideating on ways to work at the intersection of the three pillars. Large view.

That's also what participants might already have before the session. But because not everybody will have had the time to complete it, giving time to put it all together, or perhaps explore other themes and other ideas is useful.

For every theme, grouping by relevance ideas from different participants of the ideation session. Large view.

Then, for every theme, we then collect and group ideas by relevance, prioritize and visualize them. There, using visuals and storyboards helps make complex ideas more accessible and engaging for the whole team.

In the end, all participants take turns in sharing their ideas to the group. It also gives time for other participants to build upon what they have been thinking of, and double check if their direction is meaningful to a broader audience.

Some teams build small groups for collaborative revision of ideas, others build groups based on themes they've chosen. However, often ideas get dismissed too quickly, without having a chance to be publicly discussed. Personally, I would go with giving everyone the time to do the work independently, and then present their ideas for discussion.

It's a simple but very helpful approach — without too much rigidity but just enough structure to generate, prioritize and eventually visualize effective ideas with the entire team.

Wrapping Up #

The goal of effective brainstorming is to come up with feasible next steps to pursue. To do that, we need to move beyond assumptions, trying to build ideas upon what we know, rather than what we believe to be true.

Brainstorming often appears chaotic, but it doesn't have to be. Best results come from a workshop that gives people the freedom to think in their own time at their own pace — and in their comfortable space, without biases or self-imposed limitations.

Hopefully, the technique above will help with just that!

Useful Resources #

"How We Brainstorm And Choose UX Ideas", by Evan Karageorgos, Tori Holmes, Alexandre Benitah (Booking.com)
Booking.com UX Ideation Template (Miro) (password bookingcom), by Booking.com
The Rules of Productive Brainstorming, by Slava Shestopalov
On "How Might We" Questions, by Maria Rosala, NN/g
Ideation for Everyday Design Challenges, by Aurora Harley, NN/g
Brainstorming Exercises for Introverts, by Allison Press
How To Run Successful Product Design Workshops, by Gustavs Cirulis, Cindy Chang
Edward de Bono's 6 Thinking Hats (PDF Cheatsheet), by Edward de Bono

Inclusive Design Patterns For 2025 (Free Video + Slides)

Vitaly Friedman — Mon, 12 Jan 2026 00:00:00 +0000

Meet Inclusive Design Patterns For 2025, a free 3h 30mins-workshop with yours truly on accessibility — with all videos, slides and examples, recorded yesterday. Feel free to share with your friends and colleagues — no strings attached!

Google Doc (feel free to share as well!)
All workshop slides (1150 slides, PDF, 378MB)
Full video recording (incl. captions) (backup: YouTube)
Smart Interface Design Patterns, a practical video library, 15% off with the code INCLUSIVE.

Product Designer's Career Paths

Vitaly Friedman — Fri, 09 Jan 2026 00:00:00 +0000

As the new year begins, I often find myself in a strange place — reflecting back at the previous year, or looking forward at the year ahead. And as I speak with colleagues and friends at the time, typically it doesn't take long until a conversation about career trajectory emerges. So I thought I'd share a few thoughts on how to shape your career path as we are looking ahead in 2026. Hopefully you'll find it useful.

Run A Retrospective For Last Year #

To be honest, for many years, I was mostly reacting. The life was happening to me, rather than me shaping the life that I was living. I was making progress reactively and I was looking out for all kinds of opportunities. It was easy and quite straightforward — I was floating and jumping between projects and calls and making things work as I was going along.

Career Decision Map for UX Designers, put together by Lily Yue.

Years ago, my wonderful wife introduced one little annual ritual which changed that dynamic entirely. By the end of each year, we sit with nothing but paper and pencil, and run a thorough retrospective of the past year — successes, mistakes, good moments, bad moments, things we loved and things we wanted to change. We look back at our memories, projects and events that stood out that year. And then we take notes for where we stand in terms of personal growth, professional work and social connections — and how we want to grow.

These are the questions I'm trying to answer there:

What did I find most rewarding and fulfilling last year?
What fears and concerns slowed me down the most?
What could I leave behind, give away or simplify?
What tasks would be good to delegate or automate?
What are my 3 priorities to grow this upcoming year?
What times do I block in my calendar for my priorities?

It probably sounds quite cliche, but these 4-5h of our time every year set a foundation for changes to introduce for the next year. This little exercise shapes the trajectory that I'll be designing and prioritizing next year. I can't recommend it enough.

UX Skills Self-Assessment Matrix #

Another little tool that I found helpful for professional growth is UX Skills Self-Assessment Matrix (Figma template) by Maigen Thomas. It's a neat little tool that's designed to help you understand what you'd like to do more of, what you'd prefer to do less, and where your current learning curve lies vs. where you feel confident in your expertise.

A neat little tool to identify where you stand, what you want to do less of, more of and what you'd like to learn.

The exercise typically takes around 20–30 minutes, and it helps identify the UX skills with a sweet spot – typically the upper half of the canvas. You'll also pinpoint areas where you're improving, and those where you are already pretty good at. It's a neat reality check — and a great reminder once you review it year after year. Highly recommended!

Find Your Product Design Career Path #

When we speak about career trajectory, it's almost always assumed that the career progression inevitably leads to management. However, this hasn't been a path I preferred, and it isn't always the ideal path for everyone. Personally, I prefer to work on intricate fine details of UX flows, and deep dive into complex UX challenges. However, eventually it might feel like you've stopped growing — perhaps you've hit a ceiling in your organization, or you have little room for exploration and learning. So where do you go from there?

The Mirror Model (PDF) is a helpful way to visualize creative and managerial paths with equivalent influence and compensation.

A helpful model to think about your next steps is to consider Ryan Ford's Mirror Model. It explores career paths and expectations that you might want to consider to advocate for a position or influence that you wish to achieve next. That's typically something you might want to study and decide on your own first, and then bring it up for discussion. Usually there are internal opportunities out there. So before changing the company, you can switch teams, or you could shape a more fulfilling role internally. You just need to find it first. Which brings us to the next point.

Proactively Shaping Your Role #

I think that one powerful, yet often overlooked, strategy is to establish new UX roles that align with business priorities. Many companies aren't aware they need a specific role until you discover a critical gap that needs to be addressed.

Diverse Career Paths For UX Designers, a helpful overview by Lili Yue.

Sometimes these roles might involve acting as a "translator" between design and engineering, specializing in UX and accessibility. They could also involve automating design processes with AI, improving workflow efficiency, or focusing on internal search UX or legacy system.

These roles are never advertised, but they have a tremendous impact on a business. If you spot such a gap and proactively bring it to senior management, you might be able shape a role that brings your strengths into spotlight, rather than trying to fit into a predefined position.

Wrapping Up #

The most important thing about all these little tools and activities is that they help you get more clarity. Clarity about where you currently stand, and where you actually want to grow towards.

These are wonderful conversation starters to find a path that you'd love to explore, on your own or with your manager. However, just one thing I'd love to emphasize: absolutely feel free to refine the role to amplify your strengths, rather than finding a way to match a particular role perfectly.

Don't forget: you bring incredible value to your team and to your company. Sometimes it just needs to be highlighted or guided to the right spot to bring it into spotlight. You've got this — and happy 2026! ✊🏼✊🏽✊🏾

Useful Resources #

UX Skills Self-Assessment Matrix (Figma template), by Maigen Thomas
Product Designer's Career Levels Paths + PDF, by Ryan Ford
Career Decision Map For UX Designers (PNG), by Lily Yue
Diverse Career Paths For UX Designers (PNG), by Lily Yue
Shaping Designers and Design Teams, by Jason Mesut
UX Skills Self-Assessment Map template (Miro), by Paóla Quintero
UX Skill Mapping Template (Google Sheets), by Rachel Krause, NN/g
Design Team's Growth Matrix, by Shannon E. Thomas
Figma Product Design & Writing Career Levels, by Figma
Content Design Role Frameworks, by Tempo
UX Research Career Framework, by Nikki Anderson
UX Career Ladders (free eBook), by Christopher Nguyen
Product Design Level Expectations, by Aaron James

How To Design For (And With) Deaf People

Vitaly Friedman — Tue, 23 Dec 2025 00:00:00 +0000

When we think about people who are deaf, we often assume stereotypes, such as "disabled" older adults with hearing aids. However, this perception is far from the truth, and often leads to poor decisions and broken products.

Let's look at when and how deafness emerges, and how to design better experiences for people with hearing loss.

Sign language is 4-dimensional: including 3D space and time — and often includes facial expressions, too. From a wonderful talk by Marie van Driessche.

Deafness Is A Spectrum #

Deafness spans a broad continuum, from minor to profound hearing loss. Around 90–95% of deaf people come from hearing families, and deafness often isn't merely a condition that people are born with. It frequently occurs due to exposure to loud noises, and it also emerges with age, disease and accidents.

A chart showing sound frequencies and decibel levels, illustrating types of hearing loss and common everyday sounds.

The loudness of sound is measured in units called decibels (dB). Everybody is on the spectrum of deafness, from normal hearing (up to 15 dB) to profound hearing loss (91+ dB):

Slight Hearing Loss, 16-25 dB: At 16 dB hearing loss, a person can miss up to 10% of speech when a speaker is at a distance greater than 3 feet.
Mild hearing loss, 26-40 dB: Soft sounds are hard to hear including whispering, which is around 40 dB in volume. It's more difficult to hear soft speech sounds spoken at a normal volume. At 40dB hearing loss, a person may miss 50% of meeting discussions.
Moderate hearing loss, 41-55 dB: A person may hear almost no speech when another person is talking at normal volume. At a 50dB hearing loss, a person may not pick up to 80% or speech.
Moderately Severe Hearing Loss, 56-70 dB: A person may have problems hearing sounds of a dishwasher (60dB). At 70 dB, they might miss almost all speech.
Severe Hearing Loss, 71-90 dB: A person will hear no speech when a person is talking at a normal level. They may hear only some very loud noises: vacuum (70 dB), blender (78 dB), hair dryer (90 dB).
Profound Hearing Loss, 91+ dB: Hear no speech and at most very loud sounds such as a music player at full volume (100 dB), which would be damaging for people with normal hearing, or car horn (110 dB).

It's worth mentioning that loss of hearing can also be situational and temporary, as people with “normal” hearing (0 to 25 dB hearing loss) will always encounter situations where they can't hear — e.g. due to noisy environments.

Useful Things To Know About Deafness #

Assumptions are always dangerous, and in the case of deafness there are quite a few that aren't accurate. For example, most deaf people actually do not know a sign language — it's only around 1% in the US.

Also, despite our expectations, there is actually no universal sign language that everybody uses. For example, British signers often cannot understand American signers. There are globally around 300 different sign languages actively used. Still, as Johanna Steiner wrote, we never question making content available in different written or spoken languages, and the same should apply to signed languages.

Heardio concept: making podcasts accessible for deaf people — with live transcription and sign language avatars.

Sign languages are not just gestures or pantomime. They are 4D spatial languages with their own grammar and syntax, separate from spoken languages, and they don't have a written form. They rely heavily on facial expression to convey meaning and emphasis. And: they are also not universal — every country has its own sign language and dialects.

You can only understand 30% of words via lip-reading.
Most deaf people do not know any sign language.
Many sign languages have local dialects that can be hard to interpret.
Not all deaf people are fluent signers and often rely on visual clues.
For many deaf people, a spoken language is their second language.
Sign language is 4-dimensional, incorporating 3D space, time and also facial expressions.

How To Communicate Respectfully #

Keep in mind that many deaf people use spoken language of their country as their second language. So to communicate with a deaf person, it's best to ask by writing down. Don't ask how much a person can understand, and if they can lip read you.

However, as Rachel Edwards noted, don't assume someone is comfortable with written language because they are deaf. Sometimes their literacy may be low, and so providing information as text and assuming that covers your deaf users might not be the answer.

Also, don't assume that every deaf person can lip read. You can see only about 30% of words on someone's mouth. That's why many deaf people need additional visual cues, like text or cued speech.

7 accessibility symbols for people with hearing loss. Universal signs for hearing aid.

It's also crucial to use respectful language. Deaf people do not always see themselves as disabled, but rather as a cultural linguistic minority with a unique identity. Others, as Meryl Evan has noted, don't identify as deaf or hard of hearing, but rather as "hearing impaired". So, it's mostly up to an individual how they want to identify.

Deaf (Capital 'D'): Culturally Deaf people who have been deaf since birth or before learning to speak. Sign language is often first language, written language is second.
deaf (Lowercase 'd'): People who developed hearing loss later in life. Used by people who feel closer to the hearing/hard of hearing world and prefer to communicate written and/or orally.
Hard of Hearing: People with mild to moderate hearing loss who typically communicate orally and use hearing aids.

In general, avoid hearing impairment if you can, and use Deaf (for those deaf for most of their lives), deaf (for those who became deaf later), or hard of hearing (HoH) for partial hearing loss. But either way, ask politely first and then respect person's preferences.

Practical UX Guidelines #

When designing UIs and content, consider these key accessibility guidelines for deaf and hard of hearing users:

How to design for users who are deaf or hard of hearing, a Gov.uk-inspired poster by Prospect.org.uk. Download a printable PDF.

Don't make the phone required or the only method of contact.
Provide text alternatives for all audible alerts or notices.
Add haptic feedback on mobile (e.g. vibration patterns).
Ensure good lighting to help people see facial expressions.
Circular seating usually works bet so everyone can see each other's face.
Always include descriptions of non-spoken sounds (e.g., rain, laughter) in your content.
Add a transcript and closed captions for audio and video.
Clearly identify each speaker in all audio and video content.
Design multiple ways to communicate in every instance (online + in-person)
Invite video participants to keep camera on to facilitate lip-reading and the viewing of facial expressions, which convey tone.
Always test products with the actual community, instead of making assumptions for them.

Wrapping Up #

I keep repeating myself like a broken record, but better accessibility always benefits everyone. When we improve experiences for some groups of people, there are always ways of how it improves experiences for entirely different groups as well.

As Marie Van Driessche rightfully noted, to design a great experience for accessibility, we must design with people, rather than for them. And that means always include people with lived experience of exclusion into the design process — as they are the true experts.

Accessibility never happens by accident. There must be a deliberate effort to make products and services more accessible. It doesn't have to be challenging if it's considered early. No digital product is neutral. Accessibility is a deliberate decision, and a commitment. Not only does it help everyone; it also shows what a company believes in and values.

And once you do have a commitment, it will be so much easier to retain accessibility, rather than adding it last minute as a crutch — because that's where it's way too late to do it right, and way too expensive to make it well.

Useful Resources #

Designing For Deaf People Helps Everyone, by Marie Van Driessche
Design considerations for the Deaf, deaf, and hard of hearing, by Paul Roberts
Beyond Video Captions and Sign Language, by Svetlana Kouznetsova
Best Practices For CC and Subtitles UX, by Vitaly Friedman
Web Accessibility for Deaf Users
Inclusive Design Toolkit: Hearing
What It's Like To Be Born Hard of Hearing, by Twanna A. Hines, M.S.
Accessibility: Podcasts for the deaf, by Mubarak Alabidun

Useful Books #

Sound Is Not Enough, by Svetlana Kouznetsova
Mismatch: How Inclusion Shapes Design, by Kat Holmes
Building for Everyone: Extend Your Product's Reach Through Inclusive Design (+ free excerpt), by Annie Jean-Baptiste

How To Stop Endless Stakeholder Reviews

Vitaly Friedman — Sun, 21 Dec 2025 00:00:00 +0000

You've been there before. Overlapping deadlines, conflicting stakeholder priorities, and design reviews turning into endless cycles of feedback without clear decisions. It's frustrating, inefficient, and often leads to poor UX compromises.

Yesterday I stumbled upon Parvaneh Toghiani's honest case study on how to deal with exactly this challenge. Parvaneh outlines a very practical framework to make design reviews much more systematic and productive. Let's see how it works.

We often see design reviews as just a path to approval. They are also opportunities for alignment and growth. Illustration from Parvaneh Toghiani.

The Goal Is Not Just A Sign-Off #

One of the mistake I frequently made is assuming that the goal of a design review is to simply get a sign-off. As a result, often I'd focus way too much on presenting and defending my design choices, my way of thinking, my big vision. Just like Parvaneh, I often talked about consistency and alignment, showed too many alternate solutions, focused too much on fine little details that didn't matter that much yet.

Breaking down reviews into Alignment, Evaluation, and Sign-off helps set clear expectations for every meeting. Large view.

In most design reviews, the goal is actually different. It's to be aligned about the direction, and the next steps the team is committed to taking on next. Troubles always start when we guide our work based on big assumptions and wrong expectations from both sides. Parvaneh suggests breaking reviews into 3 distinct categories:

Alignment (Problem definition) Align on the PRD and discuss concept sketches early.
Evaluation (Design iteration) Get actionable feedback on 2–3 tangible proposals.
Sign-off (Solution space) Review final design, priorities, implementation details.

When in a meeting with senior stakeholders, we need first to be clear about the type of design review, and then confirm the phase, the purpose and the desired outcome of that review first. It migght sound like a small detail, but it can make quite a difference and avoid misunderstandings down the line.

Use Different Lenses For Different Stakeholders #

It's not surprising, but worth remembering: different stakeholders typically view design through a very different lens. UX language is overloaded with ambiguous terms and labels, so senior stakeholders rarely understand the deliverables and workflows that we present.

Businesses rarely understand the impact of UX work. UX language is overloaded with ambiguous terms/labels. Large view.

For executives, we need to focus on business impact or company priorities. For cross-functional leads, the focus should be on the problem space and how our work addresses it. And for the core team, we dive deep into execution and details.

Before presenting work, it's helpful to always reflect on previous reviews and what has changed since then. Having clear decision criteria and a design recommendation ready is often very much needed to move the conversation forward.

Always Show Ideas on a Spectrum #

One point from the article that I loved is to always show design ideas and concepts on a spectrum: Most Practical ↔ Blue Sky — with the preferred concept in the middle. This framing helps stakeholders understand the trade-offs between options, and why some requirements or late changes might be risky, expensive and cause delays.

Present concepts on a spectrum — from ambitious to practical, with your preferred concept in the middle.

One thing I keep reminding myself of is that there is rarely a need to show all the the fine details for each UX concept. Most design reviews are about finding a direction, not pixel-pushing on the spot.

Define the Meeting Type #

One little thing that has helped me in any meeting is to always start by explaining the completeness of our work. There are vast differences between 50%, 75%, 90% done, so we need to set right expecations first. I also try to explain the desired outcome of that design review, and what we actually need. It's also very practical to illustrate a specific meeting type in email invitations, perhaps with a custom emoji:

I love the meeting taxonomy suggested by Rich Watkins:

📣 Broadcast Meetings for announcements, townhalls,
🥁 Rhythm Meetings for regular status updates,
🏗️ Planning Meetings to set timelines, estimates,
🛠 Problem-Solving for workshops, solutions finding,
🏕️ Exploration for big questions and complex problems,
💚 Team Building Meetings for team spirit and collaboration,
🪴 Catch-Up Meetings for connecting without agenda,
🏆 Review Meetings for retros, 1:1's, perf reviews.

It's a little changes that sets expectation right early, and I'd rather have everything clear before we even start, rather than when we have to undo, redo or start from scratch.

Wrapping Up #

There is no single way to run a design review. During the different phases of the project, we will need different types of design reviews — with different purposes and different goals.

As Parvaneh writes, design reviews aren't just for approvals. They are where influence, trust, and alignment are built. They are incredible opportunities to grow as a designer — to test your storytelling, explain and defend your thinking, and learn how senior stakeholders make their decisions.

Understanding this helps avoid big misunderstandings too late, and giving a bit more confidence to move forward from the very start.

Useful Resources #

How To Run Effective Design Critiques (+ Figma template), by Jeremy Bird
How To Defend Your Design Decisions, by yours truly
"How We Run Design Critiques At Figma", by Noah Levin

Useful Books #

Articulating Design Decisions, by Tom Greever
Discussing Design: Improving Communication and Collaboration Through Critique, by Adam Connor and Aaron Irizarry
Meeting Design, by Kevin M. Hoffman

Designing Effective Dashboards UX With Action Dots

Vitaly Friedman — Sat, 06 Dec 2025 00:00:00 +0000

Many dashboards aren't actionable enough to be useful. They are designed to display all important metrics in one single place, but then it's rarely clear which of these metrics require immediate attention — and if so, which actions would be needed to actually address these issues. That's where action dots can help. Let's see how it works.

Action dots allow users to spot metrics requiring attention immediately. Discovered via Nick Desbarats.

Why Dashboards Fail #

One of the most challenging UX issues with dashboards is that it takes time for users to find relevant, or perhaps even critical insights. Dashboards bring data together in one place, but often they create very little understanding around that data.

Often call center dashboards display data, but much of this data isn't actionable, and requires effort to create understanding.

According to Nick Desbarats, there are a few frequent reasons why dashboards are abandoned:

One dashboard trying to do too much,
No action or sentiment indicators,
Data requires too much time to scan,
Every day looks very similar at a glance,
Metrics aren't always directly comparable,
Metrics requiring action aren't on a dashboard,
"Buried problems" (hidden behind filters),
Tactical and strategic dashboards merged.

Poor Types of Action Indicators #

Often action indicators are misleading, flag false positives, or bury existing problems. They don't show the full picture but instead focus on what has changed. However, a trend upwards doesn't always mean success (failure rates), and a trend downwards doesn't necessarily mean a crisis (resolution time).

Moving from thresholds to action dots. A colorblind-friendly version would include blue/green or blue/red color scheme. By Nick Desbarats.

⚠️ Some Indicators Don't Work Well #

Sometimes these indicator types might provide insufficient context or fail to drive meaningful action:

% change vs. previous period (e.g., 7.3%🔺)
% deviation from target (e.g., 10% ❌)
% deviation from trailing average (e.g., 8% 🔺)
Single-threshold (e.g., 97.3% uptime 🟩)
Good/Satisfactory/Poor ranges (e.g., 2% 🟢 / 8% 🟡 / 15% 🔴)

Once all these elements are put together, often they don't work well. Common indicators don't clearly communicate what is a crisis and what is a regular day.

It's never obvious how bad a change actually is — it might be worse than yesterday or a week ago, but is it seasonal? Is it temporary? Has the issue been addressed already?

Alternative: Action Dot Dashboards #

To make dashboards more actionable, we first look at key metrics (KPIs) we need to feature. For each KPI, we define key threshold values — from crisis to best case scenario. And then, we add an action dot depending on where the value for a metric currently falls.

Action dot dashboard in Power BI. Full image.

Unlike single-value targets (which can be problematic), we define thresholds for four specific states:

For each KPI, we define a metrics threshold to understand which values pose a problem, and which don't:

🔴 Crisis (e.g. -15% ↔ -10%): Improving it would become the user's top priority.
🟡 Actionably Bad (-10% ↔ -5%): Bad enough for the user to do something.
⚪ Neutral (-5% ↔ 5%): "Everything is OK".
🔵 Actionably Good (+5% ↔ +8%): Good enough for the user to do something.
🟣 Best Case (+8% ↔ +15%): The best a user thinks it could realistically get.

Action dots are essentially alert icons. On dashboards with action dots, problematic metrics "pop out" because metrics that don't require attention (the Neutral zone, ⚪) don't have any indicators at all. They make crises very noticeable, easy to learn, easy to spot, and easy to understand.

For each KPI, we define a metrics threshold to understand which values pose a problem, and which don't. A colorblind-friendly version would include blue/green or blue/red color scheme. By Nick Desbarats.

Accessibility Considerations #

Using red and green colors to indicate negative and positive ranges for a threshold is problematic as it makes it difficult for people who experience colorblindness or colorweakness to understand these numbers.

In Nick's implementation, users can switch to a colorblind-friendly version, with blue and red indicators instead of red and green.

Relying on colorblind-friendly color palettes would help, and perhaps even should be a default — and I'm happy to see Nick's work support this option as well.

Bonus: Dashboard Design Patterns #

By the way, talking about dashboards: I often keep coming back to Dashboard Design Patterns, a wonderful website by Benjamin Bach and his colleauges at the University of Edinburgh to visualize design patterns and components of dashboards. It's a (very!) helpful resource to keep in the bookmarks for any work around dashboards.

Common types of indicators and display. Some of them don't work well wenn put together: e.g. % change vs. previous period, % deviation from target. Full image.

Wrapping Up #

What I love most about action dots dashboards is that they immediately communicate what requires attention, based on preferences that a user has expressed and the range they prioritized. It doesn't highlight what doesn't need highlighting, and shows what requires attention.

Huge thanks to Nick Desbarats for bringing this into the spotlight and putting it all together — and I can only wholeheartedly recommend checking Nick's upcoming book and courses on dashboards as well! 🙏🏾

Useful Resources #

Action Dots Dashboards, by Nick Desbarats
Practical Charts and Dashboards (Books + Courses), by Nick Desbarats
Design Tradeoffs in Dashboard Design
Dashboard Design Patterns, by Benjamin Bach
DataViz Clarity, Dashboard Design, by Aurélien Vautier
Data Dashboard UX Benchmarking, by Creative Navy UX Agency
My Crazy Crusade Against Single-Number KPI Targets, by Nick Desbarats

Useful Books #

Practical Dashboards, by Nick Desbarats
Design for Information, by Isabel Meirelles
The Big Book of Dashboards, by Steve Wexler
Books by Stephen Few and Edward Tufte

How To Build A UX Team From Scratch

Vitaly Friedman — Thu, 27 Nov 2025 00:00:00 +0000

A while back I stumbled upon an honest, practical guide on how to scale a design team in a high-growth company, including a team's evolution, roles, meetings, processes and systems. Kindly shared by Andrew Coyle.

Andrew raised a few useful points that I never thought of, and they I always try to consider when we need to grow the design team. Let’s see what they are — hopefully it will help you grow your design team, too.

First Steps: Scope The Design Work #

There is no universal blueprint for a team setup that works everywhere. Often we might think about a good foundation that every team needs, but it shouldn’t be defined by roles, but rather by the work that needs to be done.

Scaling a design team starts with defining the immediate challenges and hiring to solve them. Large view.

A good way to start is by listing all the design work that must be done, and figuring out what challenges you need to solve first. Your first hire ideally would be a person who is able to tackle that specific challenge well. From there, you can decide on the necessary design roles to cover the rest of the work well.

Hiring Strategy: Hire Slowly, People First #

When you start hiring, hire slowly. Choose the strengths that you want to see in your team — and the ones that are very much needed for the project. It requires identifying blindspots that need to be addressed — visual design, research, accessibility or anything-in-between.

For example, you might have a very poorly performing search that many people rely on daily. It would be wise to find a person who has a good understanding of IA, metadata, indexing and design around search UX.

It’s always incredibly valuable to hire with diversity in mind to get a wide range of perspectives. Always hire slowly, and hire for roles that you actually need. Once new members join, discuss and distribute responsibilities and ownership clearly.

Team Structure and Processes #

As the team grows, eventually you will need to establish the design team’s ways of working, including meetings, rituals, and 1:1s. Every new hire increases the need and the cost of communication. Building a set of shared design principles can help structure conversations and guide decisions.

It’s important to remember that every centralized team eventually hits its limitations. When that happens, you might need to break up the team by assigning product designers to specific product teams, but also put them together by setting up a design guild for ongoing collaboration.

Centralized UX Team #

In early days, most teams start with a centralized model where the entire UX team acts as a single, in-house agency working for existing product teams. UX team often spends a lot of time in discovery as it’s detached from a specific unit, and eventually they become a bottleneck.

In a centralized UX team, team members report to the same UX manager and are part of the same core team.

Pro: Consistent, unified UX across products.
Pro: Resources can be easily prioritized for key projects.
Con: Eventually slows down product teams that are waiting for UX resources.
Con: Designers lack specialized knowledge of any single product or domain.
Con: UX teams can be detached from the practical realities and constraints of product teams.

Decentralized UX Team #

The decentralized model distributes designers across verticals, or product teams. There, designers are often integrated in existing product lifecycle and have deep understanding about the product and domain.

In decentralized UX teams, designers and researchers are embedded in multiple product teams throughout the organization.

Pro: Designers gain deep product knowledge and work more closely to their teams.
Pro: Designers have clear responsibility for the product they are working on, which eliminates UX bottlenecks.
Con: Design often becomes inconsistent across verticals unless designers have an active design guild.
Con: It becomes difficult to establish and enforce company-wide UX standards.

Matrix UX Team #

A matrix model is a combination of previous models where designers work in product teams but also report to a central UX lead. Often faces conflicting priorities from different teams and stakeholders.

In a Matrix UX team, designers are distributed across many product teams and report both to a centralized UX manager and an individual team lead.

Pro: A design guild is a way of working, with designers frequently sharing best practices and design patterns.
Con: Conflicting priorities drive designers in different directions.
Con: Require alignment between product managers and UX lead.
Con: Often needs high UX maturity in organization to work well.

There Is No “Right” UX Team Model #

As Kate Kaplan and Kara Pernice have noted, there is no single model that works best across different team setups. In small teams, designers are typically all over the place — decentralized. They don’t have a dedicated team, but are firefighters, resolving tickets as they occur. There aren’t enough design and research staff to support a decentralized model.

As the company grows, designers tend to move across verticals — centralized — at least having a specific team they are working with on a project-by-project basis. It also happens with in-house product teams as some realize that they need a first UX hire.

Eventually, as teams grow, many teams lean towards the matrix model, but often with various degree of attachment to product teams. Often they rotate between teams or move back and forth betwen decentralized and centralized models, depending on business pressure.

Quick Summary #

Start by listing all design work that must be done.
Figure out what challenges you need to solve first.
First hire should be able to tackle that challenge.
Decide on necessary design roles to cover it well.
Choose strengths that you want to see in your team.
E.g. visual/interaction design, research, accessibility.
Hire slowly, and hire for roles that you actually need.
Distribute and refine responsibilities and ownership.
Design team’s ways of working, meetings, rituals, 1:1s.
Every centralized team eventually hits its limitations.
Break up: assign product designers to product teams.
Put together: set up a design guild for collaboration.

Wrapping Up #

Among the many models and articles about the “perfect” team setup, personally, I absolutey love Andrew’s point about first hiring a UI engineer to bridge the gap between design and engineering. In many teams, that’s what usually causes friction, and having a dedicated person who understands both sides can help enormously.

Also, some teams seek established, first-class designers with a wide portfolio of big brands. But usually what they actually need are friendly, diverse folks who deeply care, are eager to learn, and are team players.

And: hire slowly, and for the roles that you actually need. If you give good people an opportunity and ownership for their work, you might be surprised just how quickly they will evolve in a new role, and move mountains for you and for your customers.

Useful Resources #

How To Structure And Manage A UX Team, by Giada Gastaldello
UX Team Models, by Kate Kaplan, Kara Pernice
Figma Case Study, by Noah Levin
Spotify Case Study, by Nicole Burrow
Shopify Case Study, by Alaine Mackenzie
How To Assemble A Winning UX Design Team, by Dovetail

Useful Books #

The User Experience Team Of One, by Leah Buley, Joe Natoli
Building and Managing In-House Design Teams, by Peter Merholz, Kristin Skinner
How Top Design Leaders Build and Grow Successful Organizations, by Richard Banfield

How To Become A Senior Designer

Vitaly Friedman — Sat, 22 Nov 2025 00:00:00 +0000

Many years ago, I assumed that simply by doing good design work, my efforts would be noticed, my work recognized, my attention to detail appreciated — and then surely I would get noticed, resulting in some sort of a promotion, or new projects, or more impactful work.

What I didn't realize is that career growth doesn't happen automatically by simply doing more good work. As Yutong Xue writes in her honest, sincere, and practical guide, "How To Become A Senior Designer", growth must be intentional.

To grow in your career, you must be proactive and take your growth into your hands. Image source: Yutong Xue.

According to Yutong, growth must be goal-oriented. Of course, we must be reliable and accountable in our work, but we also must be proactive — and I can't emphasize enough just how important that is.

In fact, some of the most ambitious projects I've worked with came through a fine combination of visibility, networking and proactive work. The latter doesn't mean being a loud voice in the room, but finding where you can make a tangible difference.

To me, being proactive means knowing what's stopping you from success and working on that. It also means taking the time to think about what slows down the team, the unit, the company, and what opportunities aren't explored yet.

Eventually, it will mean engaging proactively with stakeholders, sales, customer success, product managers on other teams, and understanding how exactly the business works and where opportunities for improvement are.

It's incredibly useful to step out and zoom out from your scope of work and explore if your project is even meaningful at scale. It also means raising a red flag once you spot it. Image source: Yutong Xue.

Almost every company has blind spots. These are neglected areas that aren't really on an agenda but have tremendous potential to drive success or reduce frustrations. And I'm not talking about AI or automation, but rather things that are often forgotten but are remarkably impactful:

Poor quality search, without ownership (often #1 complaint)
Messy categorization of data records
Broken workarounds people use to get work done
Tons of duplication and messy documentation
Redundant entry in many different places
Poorly selected defaults and presets
Confusing labels, hints and notifications
Poor, generic and unhelpful error messages

Now, these features are surely not as exciting as AI features are, but they are usually the ones that people — sooner or later — have to rely on. And for me, focusing on that — the true fundamentals of good UX and accessibility — has made it possible to jump from smaller projects to bigger projects.

It's surely not going to work for everyone, but I wish I'd known earlier that instead of chasing the big, shiny, trendy project, I should shift my focus towards blind spots. Those little and big things that many companies don't have on their agenda at all — until you come in and bring them into the spotlight.

A wonderful reminder by Yutong Xue, and a highly recommended read if you're looking for a very honest guide to grow as a designer.

Useful Books #

The User Experience Team Of One, by Leah Buley, Joe Natoli
The Making of a Manager: What to Do When Everyone Looks to You, by Julie Zhuo
The Path To Senior Product Designer, by Artiom Dashinsky
The Path To Staff Product Designer, by Artiom Dashinsky

Six Key Components of UX Strategy

Vitaly Friedman — Thu, 20 Nov 2025 00:00:00 +0000

For years, "UX strategy" felt like a confusing, ambiguous and overloaded term to me. To me, it was some sort of a roadmap or a grand vision, with a few business decisions attached to it. And looking back now, I realize that I was wrong all along.

UX Strategy isn't a goal; it's a journey towards that goal. A journey connecting where we are today with a desired future state of UX. And as such, it guides our actions and decisions, things we do and don't do. And its goal is very simple: to maximize our chances of success.

Let's explore the components of UX strategy, and how it works with product strategy and business strategy to deliver user value and meet business goals.

Strategy vs. Goals vs. Plans #

When we speak about strategy, we often speak about planning and goals — but they are actually quite different. While strategy answers "what" we're doing and "why", planning is about "how" and "when" we'll get it done. And goal is merely a desired outcome of that entire journey.

Goals establish a desired future outcome,
That outcome typically represents a problem to solve,
Strategy shows a high-level solution for that problem,
Plan is detailed low-level steps on getting solution done.

Good strategy isn't a goal or a big objective; it's a solution to a problem posed by a goal. Via Alex H Smith. Image source.

A strong strategy requires making conscious, and oftentimes tough, decisions about what we will do — and just as importantly, what we will not do, and why.

🎯 Business Strategy #

At the highest level, business strategy is about the distinct choices executives make to set the company apart from its competitors. They shape the company's positioning, objectives, and (most importantly!) competitive advantage.

We shouldn't underestimate our impact. UX affects many segments of the Business Model Canvas: user segments, relationships, channels, activities, revenue streams.

Typically, this advantage is achieved in 2 ways: through lower prices (cost leadership) or through differentiation. And that's exactly where UX impact steps in.

Top-line vision, basis for core offers,
Shapes positioning, goals, competitive advantage,
Must always adapt to the market to keep a competitive advantage.

🚀 Product Strategy #

Product strategy is how a high-level business direction is translated into unique positioning of a product. It defines what the product is, who its users are, and how it will contribute to the business's goals. It's also how we bring a product to market, drive growth and achieve product-market fit.

Unique positioning and value of a product,
How to establish and keep product in the marketplace,
How to keep competitive advantage of the product.

🧠 UX Strategy #

UX strategy is about shaping and delivering product value through UX. Good UX strategy always stems from UX research and answers to business needs. It focuses on what to focus on, what our high-value actions are, how we'll measure success, and what risks we need to mitigate.

Components of UX Strategy are Vision, Goals and a Plan. Tactical steps are part of the execution. Image source.

Most importantly, it's not a fixed plan or a set of deliverables; it's a guide that informs our actions, but also must be prepared to change when things change.

How we shape and deliver product value through UX,
Priorities, focus + why, actions, metrics, risks,
Isn't a roadmap, intention or deliverables.

Six Key Components of UX Strategy #

The impact of good UX typically lives in differentiation. It's not about how "different" our experience is, but the unique perceived value that users associate with it. And that value is a matter of clear, frictionless, accessible, fast and reliable experience wrapped into the product.

UX strategy works best in discovery, and is useful when risk and uncertainty are high. Image source.

I always try include 6 key components in any strategic UX work — so we don't end up following a wrong assumption that won't bring any impact:

🚀 Vision
The desired, improved future state of UX.

👩🏻‍💼 User segments
Primary users that we are considering.

🥇 Priorities
What we will and, crucially, what we will not do, and why.

🎯 High-value actions
How we drive value and meet user and business needs.

🗂️ Feasibility
Realistic assessment of people, processes, resources.

🎲 Risks
Bottlenecks, blockers, legacy constraints, big unknowns.

It's worth noting that it's always dangerous to be designing a product with everybody in mind. As Jamie Levy noted, by being very broad too early, we often reduce the impact of our design and messaging. It's typically better to start with a specific, well-defined user segment and then expand, rather than the other way around.

Practical Example (by Alin Buda) #

UX strategy doesn't have to be big 40-pages long PDF report or a Keynote presentation. A while back Alin Buda kindly left a comment on one of my LinkedIn posts giving a great example of what a concise UX strategy could look like:

UX Strategy (for Q4)
Our UX strategy is to focus on high-friction workflows for expert users, not casual usability improvements. Why? Because retention in this space is driven by power-user efficiency, and that aligns with our growth model.

To succeed, we'll design workflow accelerators and decision-support tools that will reduce time-on-task. As a part of it, we'll need to redesign legacy flows in the Crux system. We won't prioritize UI refinements or onboarding tours, because it doesn't move the needle in this context.

UX strategy works best in discovery, and is useful when risk and uncertainty are high. Image source.

What I like most about this example is just how concise and clear it is. Getting to this level of clarity takes quite a bit of time, but it creates a very precise overview of what we do, what we don't do, what we focus on and how we drive value.

Wrapping Up #

The best path to make a strong case with senior leadership is to frame your UX work as a direct contributor to differentiation. This isn't just about making things look different; it's about enhancing the perceived value.

A good strategy ties UX improvements to measurable business outcomes. It doesn't speak about design patterns, or consistency or neatly organized components. Instead, it speaks the language of product and business strategy — OKRs, costs, revenue, business metrics and objectives.

Design can succeed without a strategy. In wise words of Sun Tzu, strategy without tactics is the slowest route to victory. And tactics without strategy are the noise before defeat.

Useful Resources #

Business Thinking For Designers (free eBook), by Second Wave Dive
How To Engage With Stakeholders (free eBook), by Productboard
What is UX Strategy?, by Nomensa
UX Strategy: A 5-Component Framework, by Nielsen Norman Group
UX Strategy Canvas, by Miroverse
UX ROI Calculators, by Human Factors International
Design System ROI Calculator, by Knapsack

Useful Books #

UX Strategy, by Jaime Levy
No Bullsh*t Strategy, by Alex M H Smith
The Growth Equation, by Andy Budd
The Path To Staff Product Designer, by Artiom Dashinsky
UX for Business, by Joel Marsh
Pricing Design, by Dan Mall

How To Make Your UX Research Hard To Ignore

Vitaly Friedman — Tue, 18 Nov 2025 00:00:00 +0000

In the early days of my career, I believed that nothing wins an argument more effectively than strong and unbiased research. Surely facts speak for themselves, I thought.

If I just get enough data, just enough evidence, just enough clarity on where users struggle — well, once I have it all and I present it all, it alone will surely change people’s minds, hearts, and beliefs. And, most importantly, it will help everyone see, understand, and perhaps even appreciate and commit to what needs to be done.

Well, it’s not quite like that. In fact, the stronger and louder the data, the more likely it is to be questioned. And there is a good reason for that, which is often left between the lines.

Research Amplifies Internal Flaws #

Throughout the years, I’ve often seen data speaking volumes about where the business is failing, where customers are struggling, where the team is faltering — and where an urgent turnaround is necessary. It was right there, in plain sight: clear, loud, and obvious.

Good research doesn't just uncover troubles; it also amplifies internal flaws and poor decisions. Wonderful illustration by José Torre

But because it’s so clear, it reflects back, often amplifying all the sharp edges and all the cut corners in all the wrong places. It reflects internal flaws, wrong assumptions, and failing projects — some of them signed off years ago, with secured budgets, big promotions, and approved headcounts. Questioning them means questioning authority, and often it’s a tough path to take.

As it turns out, strong data is very, very good at raising uncomfortable truths that most companies don’t really want to acknowledge. That’s why at times research is deemed “unnecessary,” or why we don’t get access to users, or why loud voices always win big arguments.

UX Research in B2B: when you don’t have access to users. Large view.

So even if data is presented with a lot of eagerness, gravity, and passion in that big meeting, it will get questioned, doubted, and explained away. Not because of its flaws, but because of hope, reluctance to change, and layers of internal politics.

This shows up most vividly in situations when someone raises concerns about the validity and accuracy of research. Frankly, it’s not that somebody is wrong and somebody is right. Both parties just happen to be right in a different way.

What To Do When Data Disagrees #

We’ve all heard that data always tells a story. However, it’s never just a single story. People are complex, and pointing out a specific truth about them just by looking at numbers is rarely enough.

When data disagrees, it doesn’t mean that either is wrong. It’s just that different perspectives reveal different parts of a whole story that isn’t completed yet.

What to do when qual and quant disagree, a very practical guide by Archana Shah.

In digital products, most stories have 2 sides:

Quantitative data ← What/When: behavior patterns at scale.
Qualitative data ← Why/How: user needs and motivations.
↳ Quant usually comes from analytics, surveys, and experiments.
↳ Qual comes from tests, observations, and open-ended surveys.

Risk-averse teams overestimate the weight of big numbers in quantitative research. Users exaggerate the frequency and severity of issues that are critical for them. As Archana Shah noted, designers get carried away by users’ confident responses and often overestimate what people say and do.

And so, eventually, data coming from different teams paints a different picture. And when it happens, we need to reconcile and triangulate. With the former, we track what’s missing, omitted, or overlooked. With the latter, we cross-validate data — e.g. finding pairings of qual/quant streams of data, then clustering them together to see what’s there and what’s missing, and explore from there.

And even with all of it in place and data conflicts resolved, we still need to do one more thing to make a strong argument: we need to tell a damn good story.

Facts Don’t Win Arguments, Stories Do #

Research isn’t everything. Facts don’t win arguments — powerful stories do. But a story that starts with a spreadsheet isn’t always inspiring or effective. Perhaps it brings a problem into the spotlight, but it doesn’t lead to a resolution.

Presenting research is more than presenting findings. It must be wrapped inside of an actionable story. Wonderful illustration by José Torre.

The very first thing I try to do in that big boardroom meeting is to emphasize what unites us — shared goals, principles, and commitments that are relevant to the topic at hand. Then, I show how new data confirms or confronts our commitments, with specific problems we believe we need to address.

When a question about the quality of data comes in, I need to show that it has been reconciled and triangulated already and discussed with other teams as well.

A good story has a poignant ending. People need to see an alternative future to trust and accept the data — and a clear and safe path forward to commit to it. So I always try to present options and solutions that we believe will drive change and explain our decision-making behind that.

A useful little helper to understand what stakeholders truly care about. User Centered Design Canvas could be applied to stakeholders.

They also need to believe that this distant future is within reach, and that they can pull it off, albeit under a tough timeline or with limited resources.

And: a good story also presents a viable, compelling, shared goal that people can rally around and commit to. Ideally, it’s something that has a direct benefit for them and their teams.

These are the ingredients of the story that I always try to keep in my mind when working on that big presentation. And in fact, data is a starting point, but it does need a story wrapped around it to be effective.

Wrapping Up #

There is nothing more disappointing than finding a real problem that real people struggle with and facing the harsh reality of research not being trusted or valued.

We’ve all been there before. The best thing you can do is to be prepared: have strong data to back you up, include both quantitative and qualitative research — preferably with video clips from real customers — but also paint a viable future which seems within reach.

And sometimes nothing changes until something breaks. And at times, there isn’t much you can do about it unless you are prepared when it happens.

“Data doesn’t change minds, and facts don’t settle fights. Having answers isn't the same as learning, and it for sure isn't the same as making evidence-based decisions.” — Erika Hall

Useful Resources #

How to Present Research So Stakeholders Sit Up and Take Action, by Nikki Anderson
What To Do When Data Disagrees, by Subhasree Chatterjee, Archana Shah, Sanket Shukl and Jason Bressler
Mixed-Method UX Research, by Raschin Fatemi
A Step-by-Step Framework For Mixed-Method Research, by Jeremy Williams
The Ultimate Guide To Mixed Methods, by Ben Wiedmaier
Survey Design Cheatsheet, by yours truly 👍
Useful Calculators For UX Research, by yours truly 👍
Beyond Measure, by Erika Hall 👍

Useful Books #

Just Enough Research, by Erika Hall
Designing Surveys That Work, by Caroline Jarrett
Designing Quality Survey Questions, by Sheila B. Robinson

Useful UX Research Calculators and Guides

Vitaly Friedman — Mon, 06 Oct 2025 00:00:00 +0000

UX research doesn’t have to be expensive or time-consuming. Yet very often it’s perceived as a huge, blocking effort, requiring weeks and months of work, often without a clear timeline in mind.

In practice, we can get meaningful insights without significant delays. Let’s see what UX research calculators and guides we can use to estimate just the right number of participants — for surveys, card sorting and usability testing. Let’s jump in.

Quick Cheatsheet #

Testing isn’t about finding universal truths, but key blockers where people struggle. And for that, you don’t need many people to start gathering insights:

Iterate with 5 people at a time: test, adjust, test again.
Surveys: aim confidence level 95%, margin of error 2–5%.
10,000 users → you will need ≥567 answers to reduce bias.
Assume the response rate of 20–30% (incl. no-show-rate).
For reliable survey results, we need to invite 2835 people.
For card sorting, get 15–30+ people to sort independently.
For tree testing, invite at least 25 (better: 50) participants.
Nothing matters more than a targeted and diverse sample.

Useful Calculators and Guides #

👥 Qualitative Sample Size Calculator, by UserInterviews
💸 Research Incentive Calculator, by UserInterviews
🔘 Survey Sample Size Calculator, by CheckMarket
💯 Bonus: Design System ROI Calculator, by Knapsack
📱 UX Work ROI Calculator, by Paul Boag
🚀 UX Research Project Launch Kits, by UserInterviews
🌲 UX Research Field Guide, by UserInterviews

Scale ≠ Clarity #

A while back I stumbled upon Nikki Anderson’s point about big sample sizes often wrongfully viewed as the “safest” way to discover insights. I love Nikki's argument that scale can’t fix vague goals, at times answer wrong or misleading questions, and often skip the difficult part of framing the problem first. Scale sounds impressive, but it doesn’t map to clarity.

Nikki suggests starting with a very simple path:

Decide on what you want to know,
↳ Then choose the right questions to ask,
↳ Then choose the research method to use,
↳ Then decide on the sample size.

So we start with a decision of what we’re trying to learn first, then the question, then the method, and then the sample size. But we must know — and be committed — to what we want to know first. And very often we don’t need statistically significant results to notice and act on critical blockers.

“But Is It Statistically Significant?” #

Now, for UX designers, that’s an incredibly difficult question to answer. Again, as Nikki has pointed out, statistical significance was never designed for qualitative research. And with UX work, we’re not trying to publish academic research or prove universal truths.

What we are trying to do is reach theoretical saturation, the point where additional research doesn’t give us new insights. Research isn’t about proving something is true. It’s about preventing costly mistakes before they happen.

Five users per iteration often surface major issues, and 10–15 users per segment usually reach saturation. If we’re still getting new insights after that, our scope is too broad.
“If five people hit the same pothole and wreck their car, how many more do you need before fixing the road?”
“If three enterprise customers say onboarding is confusing, that’s a churn risk.”
“If two usability tests expose a checkout issue, that’s abandoned revenue.”
“If one customer interview reveals a security concern, that’s a crisis waiting to happen.”
“How many user complaints exactly do we need to take this seriously?”
“How much revenue exactly are we willing to lose before fixing this issue?”

Wrapping Up #

It might not be necessary to focus on the number of participants, but instead, argue about users consistently struggling with a feature, a mismatch of expectations, and a clear pattern emerging around a particular pain point.

Research doesn’t have to be expensive or time-consuming. In the worst case, I start with 5×45 mins interviews to spot critical blockers and unmet user needs. As we run sessions, I mark critical areas and record short screen share snippets — with consent — and make them visible in the company.

Once you’ve built enough confidence in the work that you are doing, it will be much easier to ask for bigger commitments — in fact, you might be surprised by how quickly your research work will be requested, rather than merely applied to design work.

Useful Articles #

How Many Participants For a UX Interview?, by Maria Rosala
Sample-Size Recommendations, by Raluca Budiu and Kate Moran

How To Design Bulk Import UX (+ Figma Prototypes)

Vitaly Friedman — Mon, 06 Oct 2025 00:00:00 +0000

Friendly note: get a friendly UX bundle for Smart Interface Design Patterns 🍣 and Measuring UX 🍎 — with live UX training coming up. Jump to table of contents.

Bulk operations are heavily underused in most products. The term refers to running repetitive tasks in large batches, which enables fast iterations and updates across large data sets. This, in turn, reduces time on task, human errors, and manual actions.

But, as you probably know, bulk operations aren’t easy to design. We need to think about missing metadata, matching columns and fixing errors. We need to help people understand what’s missing and what’s wrong to avoid poor imports. Let’s see what exactly it requires.

A good bulk import UX has a validation step that allows users to identify and fix issues directly within the interface. UX Case Study: Bulk Import.

The Art of Bulk Operations #

Bulk operations come in many flavors: bulk import, bulk editing, disable, move, update, archive and so many others. When designing an import, it’s a good idea to first define core bulk attributes for mapping. Then for each attribute, define a data profile and whether it’s optional or required.

Then, we study file types, encodings, max file sizes and metadata. Users often expect bulk features to support Excel and CSV — but also the ability to copy/paste data, along with a preview and auto-fill.

An often overlooked part is refined error messages for broken files and unmatched columns, which are very much needed to help people recover. Things will go wrong, and mostly it’s just a matter of time until it happens. We must be prepared for it.

Being prepared requires a process.

Five Stages of Bulk Workflow #

Almost every bulk workflow will include (at least) the following 5 steps:

🚦 1. Pre-import
Set up guardrails and give an example or an Excel template.

✂️ 2. File Upload
Support drag-and-drop, keyboard-only, and copy/paste.

🚎 3. Mapping
Map header columns, check values, and add inline editing for corrections.

🧰 4. Repair
Flag duplicates and allow users to see only rows with errors.

🗂️ 5. Import
Show a final summary and support adding tags, labels, or categories to the batch.

In that light, again, probably the most challenging part about bulk operations is helping users fix issues — be it column mismatches, missing data, or contradictory details — within the bulk feature itself. Many interfaces simply dismiss the file with generic and technical jargon, labeling it as “corrupt”, “invalid”, “incompatible”, or “wrong”.

We can prepare users by setting expectations on data format, sizes, and attributes ahead of time. We could provide a sample template to consult or use. Map column headers but then allow users to fix errors. Look ahead: there might be duplicate records already, so before overwriting them, flag them and ask users to confirm how they’d like to manage them.

A wireframe of a file import interface showing options for choosing a file and mapping CSV columns to database fields.

And: once an import has completed, it’s usually very difficult to reverse the process. So, help users categorize, tag, or add extra metadata (e.g., source) to tell the “new” data apart from the “old”. You might not be able to reverse the process, but you can help users navigate around it if’s needed.

Useful Resources #

Bulk Upload Feature UX, by Livinda Christy Monica
Making A Bulk of Payouts, by Divya Kotian (see also the Figma prototype)
Bulk Import UX For CSV & XLXS, by Yooshan Chandran (see also the Figma prototype)
Building a Seamless CSV Import, by David Bonilla

UX Job Interview Helpers

Vitaly Friedman — Mon, 14 Jul 2025 00:00:00 +0000

When talking about job interviews for a UX position, we often discuss how to leave an incredible impression and how to negotiate the right salary. But it’s only one part of the story. The other part is to be prepared, to ask questions and to listen carefully.

Below, I’ve put together a few useful resources on UX job interviews — from job boards to Notion templates and practical guides. I hope you or your colleagues will find it helpful.

The Design Interview Kit #

As you are preparing for that interview, get ready with the Design Interview Kit (Figma), a helpful practical guide that covers how to craft case studies, solve design challenges, write cover letters, present your portfolio and negotiate your offer. Kindly shared by Oliver Engel.

The Product Designer’s (Job) Interview Playbook (PDF) #

The Product Designer’s (Job) Interview Playbook (PDF) is a practical little guide for designers through each interview phase, with helpful tips and strategies on things to keep in mind, talking points, questions to ask, red flags to watch out for and how to tell a compelling story about yourself and your work. Kindly put together by Meghan Logan.

The Product Designer’s Interview Handbook, by Meghan Logan.

From my side, I can only wholeheartedly recommend to not only speak about your design process. Tell stories about the impact that your design work has produced. Frame your design work as enabler of business goals and user needs. And include insights about the impact you’ve produced — on business goals, processes, team culture, planning, estimates, testing.

Also, be very clear about the position that you are applying for. In many companies, titles do matter. There are vast differences in responsibilities and salaries between various levels for designers, so if you see yourself as a senior, review if it actually reflects itself in the position.

A Guide To Successful UX Job Interviews (+ Notion template) #

Catt Small’s Guide To Successful UX Job Interviews, a wonderful practical series on how to build a referral pipeline, apply for an opening, screening, prepare for the interview, present your work and manage salary expectations. You can also download a Notion template.

A Guide to Design Interview Journey, by (wonderful!) Catt Small.

30 Useful Questions To Ask In UX Job Interviews #

In her wonderful article, Nati Asher has suggested many useful questions to ask in a job interview when you are applying as a UX candidate. I’ve taken the liberty to revise some of them, and added a few more questions that might be worth considering for your next job interview.

Best interviews include questions from both sides. A wonderful illustration by José Torre.

What are the biggest challenges the team faces at the moment?
What are the team’s main strengths and weaknesses?
What are the traits and skills that will make me successful in this position?
Where is the company going in the next 5 years?
What are the achievements I should aim for over the first 90 days?
What would make you think “I’m so happy we hired X!”?
Do you have any doubts or concerns regarding my fit to this position?
Does the team have any budget for education, research etc.?
What is the process of onboarding in the team?
Who is in the team and how long are they in that team?
Who are the main stakeholders I will work with on a day-to-day basis?
Which options do you have for user research and accessing users or data?
Are there analytics, recordings or other data sources to review?
How do you measure the impact of design work in your company?
To what extent does management understand the ROI of good UX?
How does UX contribute strategically to the company’s success?
Who has the final say on design, and who decides what gets shipped?
What part of the design process does the team spend most time on?
How many projects do designers work on simultaneously?
How has the organization overcome challenges with remote work?
Do we have a design system, and in what state is it currently?
Why does a company want to hire a UX designer?
How would you describe the ideal candidate for this position?
What does a career path look like for this role?
How will my performance be evaluated in this role?
How long do projects take to launch? Can you give me some examples?
What are the most immediate projects that need to be addressed?
How do you see the design team growing in the future?
What traits makes someone successful in this team?
What’s the most challenging part of leading the design team?
How does the company ensure it’s upholding its values?

Before a job interview, have your questions ready. Not only will they convey a message that you care about the process and the culture, but also that you understand what is required to be successful. And this fine detail might go a long way.

Don’t Forget About The STAR Method #

Interviewers closer to business will expect you to present examples of your work using the STAR method (Situation – Task – Action – Result), and might be utterly confused if you delve into all the fine details of your ideation process or the choice of UX methods you’ve used.

🗂️ Situation: Set the scene and give necessary details.
🦸‍♀️ Task: Explain your responsibilities in that situation.
🪜 Action: Explain what steps you took to address it.
🎯 Result: Share the outcomes your actions achieved.

As Meghan suggests, the interview is all about how your skills add value to the problem the company is currently solving. So ask about the current problems and tasks. Interview the person who interviews you, too — but also explain who you are, your focus areas, your passion points and how you and your expertise would fit in a product and in the organization.

Wrapping Up #

A final note on my end: never take a rejection personally. Very often the reasons you are given for rejection are only a small part of a much larger picture — and have almost nothing to do with you. It might be that a job description wasn’t quite accurate, or company is undergoing restructuring, or the finances are too tight after all.

Don’t despair and keep going. Write down your expectations. Job titles matter: be deliberate about them and your level of seniority. Prepare good references. Have your questions ready for that job interview. As Catt Small says, “once you have a foot in the door, you’ve got to kick it wide open”.

You are a bright shining star 🌟 — don’t you ever forget that. 🤞🏼🤞🏾

💠 Job Boards #

Useful Resources #

How To Be Prepared For UX Job Interviews, by yours truly
UX Job Search Strategies and Templates, by yours truly
How To Ace Your Next Job Interview, by Startup.jobs
Cracking The UX Job Interview, by Artiom Dashinsky
The Product Design Interview Process, by Tanner Christensen
10 Questions To Ask in a UX Interview, by Ryan Scott,
Six questions to ask after a UX designer job interview.

Design Patterns For AI Interfaces

Vitaly Friedman — Thu, 10 Jul 2025 00:00:00 +0000

Friendly note: get a friendly UX bundle for Smart Interface Design Patterns 🍣 and Measuring UX 🍎 — with live UX training coming up. Jump to table of contents.

So you need to design a new AI feature for your product. How would you start? How do you design flows and interactions? And how do you ensure that that new feature doesn’t get abandoned by users after a few runs?

In this newsletter, I’d love to share a very simple but systematic approach of how I think about designing AI experiences. Hopefully it will help you get a bit more clarity about how to get started.

Design Patterns for AI Interfaces, a practical guide by Sharang Sharma.

The Receding Role of AI Chat #

One of the key recent shifts is a slow move away from traditional “chat-alike” AI interfaces. As Luke Wroblewski wrote, when agents can use multiple tools, call other agents and run in the background, users orchestrate AI work more — there’s a lot less chatting back and forth.

Messaging UI slowly starts feeling dated, and chat UI fades into background. By Luke Wroblewski.

In fact, chatbots are rarely a great experience paradigm — mostly because the burden of articulating intent efficiently lies on the user. But in practice, it’s remarkably difficult to do well, and very time-consuming.

Chat doesn’t go away of course, but it’s being complemented with task-oriented UIs — temperature controls, knobs, sliders, buttons, semantic spreadsheets, infinite canvases — with AI providing predefined options, presets and templates.

Agentic AI design patterns, with more task-oriented UIs, rather than chat. By Luke Wroblewski.

There, AI emphasizes the work, the plan, the tasks — the outcome, instead of the chat input. The result are experiences that truly amplify value for users by sprinkling a bit of AI in places where it delivers real value to real users.

To design better AI experiences, we need to study 5 key areas that we need to shape.

✍️ 1. Input UX: Expressing Intent #

Conversational AI is a very slow way of helping users expressing and articulating their intent. Usability tests show that users often get lost in editing, reviewing, typing and re-typing. It’s painfully slow, often taking 30-60s for input.

As it turns out, people have a hard time expressing their intent well. In fact, instead of writing prompts manually, it's a good idea to ask AI to write a prompt to feed itself.

Flora AI allows you to modify images and videos via nodes.

With Flora AI, users can still write prompts, but they visualize their intent with nodes by connecting various sources visually. Instead of elaborately explaining to AI how we need the pipeline to work, we attach nodes and commands on a canvas.

With Krea.ai, users can move abstract shapes (on the left) to explain their goal to AI and study the outcome (on the right).

With input for AI, being precise is slow and challenging. Instead, we can abstract away the object we want to manipulate, and give AI precise input by moving that abstracted object on a canvas. That’s what Krea.ai does.

In summary, we can minimize the burden of typing prompts manually — with AI-generated pre-prompts, prompt extensions, query builders and also voice input.

🗂️ 2. Output UX: Displaying Outcomes #

AI output doesn't have to be merely plain text or a list of bullet points. It must be helpful to drive people to insights, faster. For example, we could visualize output by creating additional explanations, based on user’s goal and motivations.

Visualizing outcome through style lenses. By Amelia Wattenberger.

For example, Amelia Wattenberger visualized AI output for her text editor PenPal by adding style lenses to explore the content from. The output could be visualized in sentence lengths and scales Sad — Happy, Concrete — Abstract etc.

Aino.ai, an AI GIS Analyst for urban planning.

The outcome could also be visualized on a map, which of course is expected for an AI GIS analyst. Also, users can access individual data layers, turn them on and off and hence explore the data on the map.

We can also use forced ranking and prioritizations to suggest best options and avoid choice parallysis — even if a user asks for top 10 recommendations. We can think about ways to present results as a data table, or a dashboard, or a visualization on a map, or as a structured JSON file, for example.

Users often need to cherry-pick some bits from the AI output and bring them together in a new place — and often they need to expand on one section, synthesize bits from another section, or just refine the outcome to meet their needs.

Adobe Firefly suggests options and sliders to adjust the outcome.

Refinement is usually the most painful part of the experience, with many fine details being left to users to explain elaborately. But we can use good old-fashioned UI controls like knobs, sliders, buttons etc. to improve that experience, similar to how Adobe Firefly does it (image above).

Presets living on the side in Elicit, an example by Maggie Appleton.

We can also use presets, bookmarks and allow users to highlight specific parts of the outcome that they’d like to change — with contextual prompts acting on highlighted parts of the output, rather than global prompts.

Tweaking specific parts of the outcome, on Grammarly.

🗓️ 4. AI Actions: Tasks To Complete #

With AI agents, we can now also allow users to initiate tasks that AI can perform on their behalf, such as scheduling events, planning and deep research. We could also ask to sort results or filter them in a specific way.

Suggesting actions on Elicit, an example by Maggie Appleton.

But we can also add features to help users use AI output better — e.g. by visualizing it, making it shareable, allowing transformations between formats, or also posting to Slack, Jira etc.

⚙️ 5. AI Integration: Where Work Happens #

Many AI interactions are locked within a specific product, but good AI experiences happen where the actual work happens. It would be quite unusual to expect a dedicated section for Autocomplete, for example, but we do so for AI features.

DoveTail AI integrates in plenty of platforms, from Jira and Notion to Slack and Teams, where the actual work happens.

The actual boost in productivity comes when users rely on AI as a co-pilot or little helper in the tools they use daily for work. It's seamless integrations into Slack, Teams, Jira, GitHub etc. — the tools that people use anyway. Dia Browser and Dovetail are great examples of it in action.

Wrapping Up #

Along these 5 areas, we can explore ways to minimize the cost of interaction with a textbox, and allowing users to interact with the points of interest directly, by tapping, clicks, selecting, highlighting, bookmarking.

Many products are obsessed by being AI-first. But you might be way better off by being AI-second instead. The difference is that we focus on user needs and sprinkle a bit of AI across customer journeys where it actually adds value.

And: AI products don't have to be AI-only. There is a lot of value in mapping into the mental models that people have adopted over the years, and enhance them with AI, similar to how we do it with browser's autofill, rather than leaving users in front of a frightening and omnipresent text box.

Useful Resources #

Where Should AI Sit In Your UI?, by Sharang Sharma
Shape of AI: Design Patterns, by Emily Campbell 👍
AI UX Patterns, by Luke Bennis 👍
Design Patterns For Trust With AI, via Sarah Gold 👍
AI Guidebook Design Patterns, by Google
Usable Chat Interfaces to AI Models, by Luke Wroblewski
The Receding Role of AI Chat, by Luke Wroblewski
Agent Management Interface Patterns, by Luke Wroblewski
Designing for AI Engineers, by Eve Weinberg

Design Guidelines For Better Notifications UX

Vitaly Friedman — Tue, 08 Jul 2025 00:00:00 +0000

Friendly note: get a friendly UX bundle for Smart Interface Design Patterns 🍣 and Measuring UX 🍎 — with live UX training coming up. Jump to table of contents.

In many products, setting notification channels on mute is a default, rather than an exception. The reason for that is their high frequency which creates disruptions and eventually notifications fatigue, when any popping messages get dismissed instantly.

There is a good reason for it: high frequency of notifications. In usability testing, it’s the most frequent complaint, yet every app desperately tries to capture a glimpse of our attention, sending more notifications our way. Let’s see how we could make the notifications UX slightly better.

Decision tree for when to send and not to send a notification, on Slack.

A Guide to Design Interview Journey, by (wonderful!) Catt Small.

1. The Many Faces of Notifications #

Notifications are distractions by nature; they bring a user’s attention to a (potentially) significant event they aren’t aware of or might want to be reminded of. As such, they can be very helpful and relevant, providing assistance, and bringing structure and order to the daily routine. Until they are not.

Not every communication option is a notification. As Kim Salazar rightfully noted, status communication often relies on validation, status indicators and notifications. While they are often considered to be similar, they are actually quite different.

Notifications are informational messages that alert the user of general occurrences within a system.

In general, notifications can be either informational (calendar reminders, delay notifications, election night results) or encourage action (approve payment, install an update, confirm a friend request). They can stream from various sources, and can have various impact.

UI notifications appear as subtle cards in UIs as users interact with the web interface — as such, they are widely accepted and less invasive than some of their counterparts.
In-browser push notifications are more difficult to dismiss, and draw attention to themselves even if the user isn’t accessing the UI.
In-app notifications live within desktop and mobile apps, and can be as humble as UI notifications, but can take a more central role with messages pushed to the home screen or the notifications center.
OS notifications such as software updates or mobile carrier changes also get in the mix, often appearing together with a wide variety of notes, calendar updates, and everything in between.
Finally, notifications can find their way into email, SMS, and social messaging apps, coming from chatbots, recommendation systems, and actual humans.

But: we don’t pay the same amount of attention to every notification. It can take weeks until they eventually install a software update prompted by their OS notification, or just a few hours to confirm or decline a new LinkedIn request.

2. Not Every Notification Is Equal #

The level of attention users grant to notifications depends on their nature, or, more specifically, how and when notifications are triggered. People care more about new messages from close friends and relatives, bank transactions and important alerts, calendar notifications and any actionable and awaited confirmations or releases.

A variety of triggers (or) origins of information, from a Critical Analysis of Notification Systems by Shankar Balasubramanian (Gmail team).

People care less about news updates, social feed updates, announcements, new features, crash reports, promotional and automated messages in general. Most importantly, a message from another human being is always valued much higher than any automated notification.

3. Design For Levels Of Severity #

As Sara Vilas suggests, we can break down notification design across three levels of severity: high, medium, and low attention. And then, notification types need to be further defined by specific attributes on those three levels, whether they are alerts, warnings, confirmations, errors, success messages, or status indicators.

A variety of triggers (or) origins of information, from a Zendesk Mapping Tone by Shankar Balasubramanian (Gmail team).

High Attention

Alerts (immediate attention required)
Errors (immediate action required)
Exceptions (system anomalies, something didn’t work)
Confirmations (potentially destructive actions that need user confirmation to proceed)

Medium Attention

Warnings (no immediate action required)
Acknowledgments (feedback on user actions)
Success messages

Low Attention

Informational messages (aka passive notifications, something is ready to view)
Badges (typically on icons, signifying something new since last interaction)
Status indicators (system feedback)

Taking it one step further, we can map the attention against the type of messaging we are providing — very similar to Zendesk's mapping tone above, which plots impact against the type of messaging, and shows how the tone should adjust — becoming more humble, real, distilled or charming.

So: notifications can be different, and different notifications are perceived differently; however, the more personal, relevant, and timely notifications are, the higher engagement we should expect.

4. Start Sending Notifications Slowly But Steadily #

It’s not uncommon to sign up, only to realize a few moments later that the inbox is filling up with all kinds of irrelevant messages. That’s exactly the wrong thing to do. A study by Facebook showed that sending fewer notifications improved user satisfaction and long-term usage of a product.

Initially, once the notification rate was reduced, there was indeed a loss of traffic, but it has “gradually recovered over time”, and after an extended period, it had fully recovered and even turned out to be a gain.

A good starting point is to set up a slow default notification frequency for different types of customers. As the customer keeps using the interface, we could ask them to decide on the kind of notifications they’d prefer and their frequency.

Send notifications slowly, and over time slowly increase and/or decrease the number of notifications per type of a customer. This might work much better for our retention rates.

5. Don’t Rely On Generic Defaults: Set Up Notification Modes #

Typically users can opt in and opt out from every single type of notification in their settings. In general, it’s a good idea, but it can also be very overwhelming — and not necessarily clear as of how important each notification is. Alternatively, we could provide predefined recommended options, perhaps with a “calm mode” (low frequency), a “regular mode” (medium frequency), and a “power-user mode” (high frequency).

How Slack decides to send a notification, incredible documentation on when to trigger a notification on Slack.

As time passes, the format of notifications might need adjustments as well. Rather than having notifications sent one by one as events occur, users could choose a “summary mode,” with all notifications grouped into a single standalone message delivered at a particular time each day or every week.

That’s one of the settings that Slack provides when it comes to notifications; in fact, the system adapts the frequency of notifications over time, too. Initially, as Slack channels can be quite silent, the system sends notifications for every posted message.

As activities become more frequent, Slack recommends reducing the notification level so the user will be notified only when they are actually mentioned.

6. Make Notification Settings A Part Of Onboarding #

We could also include frequency options in our onboarding design. A while back Basecamp, for example, has introduced “Always On” and “Work Can Wait” options as a part of their onboarding, so new customers can select if they wish to receive notifications as they occur (at any time), or choose specific time ranges and days when notifications can be sent.

On Basecamp, new customers can select if they wish to receive notifications as they occur, or choose specific time ranges and days when notifications can be sent.

Or, the other way around, we could ask users when they don’t want to be disturbed, and suspend notifications at that time. Not every customer wants to receive work-related notifications outside of business hours or on the weekend, even if their colleagues might be working extra hours on Friday night on the other side of the planet.

7. Allow Users To Snooze Or Pause Notifications #

User’s context changes continuously. If you notice an unusual drop in engagement rate, or if you’re anticipating an unusually high volume of notifications coming up (a birthday, wedding anniversary, or election night, perhaps), consider providing an option to mute, snooze, or pause notifications, perhaps for the next 24 hours.

This might go very much against our intuition, as we might want to re-engage the customer if they’ve gone silent all of a sudden, or we might want to maximize their engagement when important events are happening. However, it’s easy to reach a point when a seemingly harmless notification will steer a customer away, long term.

In “Designing Notifications For Apps”, Shashank Sahay explores different notification models and when to use which.

Another option would be to suggest a change of medium used to consume notifications. Users tend to associate different levels of urgency with different channels of communication.

In-app notifications, push notifications, and text messages are considered to be much more intrusive than good ol’ email, so when frequency exceeds a certain threshold, you might want to nudge users towards a switch from push notifications to daily email summaries.

Wrapping Up #

As always in design, timing matters, and so do timely notifications. Start slowly, and evolve your notification frequency depending on how exactly a user actually uses the product. For every type of user, set up notification profiles — frequent users, infrequent users, one-week-experience users, one-month-experience users etc.

And: whenever possible, allow your users to snooze and mute notifications for a while, and eventually you might even want to suggest a change of medium used to consume notifications. And when in doubt, postpone, rather than sending through.

Designing Better UX For Left-Handed People

Vitaly Friedman — Mon, 02 Jun 2025 00:00:00 +0000

In times when we are figuring out how to design AI interfaces, it’s important to stay focused on what truly matters — people. After all, no technology is useful without real value for real people — and inclusive design is the foundation of it.

In the world today, roughly 10% of people are left-handed. Yet most products — digital and physical — aren’t designed with it in mind. Let’s change that, and explore what it means for us.

The best option to support interaction for both hands is by placing key actions at the bottom center of the screen. An illustration, based on Steven Hoober's research.

Left-Handedness ≠ “Left-Only” #

It’s easy to assume that left-handed people are usually left-handed users. However, that’s not necessarily the case. Because most products are designed with right-handed use in mind, many left-handed people have to use their right hand to navigate physical word.

From very early childhood, left-handed people have to rely on their right hand to use tools and appliances like scissors, openers, fridges etc. That's why left-handed people tend to be ambidextrous, sometimes using different hands for different tasks, and sometimes using different hands for the same tasks interchangeably.

Challenges for left-handed people: when a foldable desk for writing is located on the right. Better: pull it up to the center.

In the same, right-handed people aren’t necessarily right-handed users. It’s common to be using a mobile device in both left and right hands, or both, perhaps with a preference for one. But when it comes to writing, a preference is stronger.

Challenges For Left-Handed Users #

With digital products, most left-handed people tend to adapt to right-handed tools which they use daily. Unsurprisingly, many use their right hand to navigate the mouse. However, it’s often quite different on mobile where left hand often preferred.

Challenges for left-handed people: using “regular” scissors with the left hand can be difficult for left-handed users.

✅ 13% of people in NL, US, UK, Canada are left-handed.
🤔 Most products are designed exclusively for the right hand.
🤔 Less demand for left-handed items → they cost more.
🤔 Many left-handed users don’t keep their mouse on the left.
✅ 1% people use both hands equally well (ambidextrous).

🚫 Don’t make design decisions based on left/right-handedness.
✅ Allow customizations based on user’s personal preferences.
✅ Allow users to re-order columns (incl. the Actions column).
✅ In forms, place action buttons next to last user’s interaction.
✅ Keyboard accessibility helps everyone move faster (Esc).

Usability Guidelines To Support Both Hands #

As Ruben Babu writes, we shouldn’t design a fire extinguisher that can’t be used by both hands. Think pull up and pull down, rather than swipe left or right. Minimize distance to travel with the mouse. And when in doubt, align to the center.

🤔 Bottom left → better for lefties, bottom right → for righties.
🚫 With magnifiers, users can’t spot right-aligned buttons.
✅ On desktop, align buttons to the left/middle, not right.
🤔 On mobile, most people switch both hands when tapping.
✅ Key actions → put in middle half to two-thirds of the screen.

Opposite-Handed UX test can be helpful to test how good the UI is — also known as “left-handed oil test” for physical products.

A simple way to test the mobile UI is by trying to use the opposite-handed UX test. For key flows, we try to complete them with your non-dominant hand use the opposite hand to discover UX shortcomings.

For physical products, you might try the oil test. It might be more effective than you might think.

Good UX Works For Both #

Our aim isn’t to degrade the UX of right-handed users by meeting the needs of left-handed users. The aim is to create an accessible experience for everyone. E.g. a better experience for left-handed people also helps right-handed people who have a temporary arm disability.

And that's an often-repeated but also oftern overlooked universal principle of usability: better accessibility is better for everyone, even if it might feel that it doesn’t benefit you directly in the moment.

Useful Resources #

Discover Hidden UX Flaws With the Opposite-Handed UX Test, by Jeff Huang
Right-Aligned Buttons Aren’t More Efficient For Right-Handed People, by Julia Y.
Mobile Accessibility Target Sizes Cheatsheet, by Vitaly Friedman
Why The World Is Not Designed For Left-Handed People, by Elvis Hsiao
Usability For Left Handedness 101, by Ruben Babu
Book: Touch Design For Mobile Interfaces, by Steven Hoober

No, AI Will Not Replace You

Vitaly Friedman — Wed, 28 May 2025 00:00:00 +0000

You can find techniques for UX strategy in Measure UX 🧭 — with live UX training later this year. Jump to table of contents.

We see many debates about designers being replaced by AI. About designers having to relearn their craft entirely to work with AI. And of course if you don’t learn how to use AI, other people who do use it well, will replace you.

But personally, I don't think either of it is true. And here are a few reasons why.

AI Is Unreliable Software #

First of all, don’t get me wrong: I’m not against the spirit of AI. If it can reduce waste and minimize unnecessary time on screen for humans (while being sustainable), I'm all for it.

With AI, trust erodes rather quickly. Designing For Trust Catalogue features helpful design patterns for products to build up trust.

However, at the point in time, most AI tools hallucinate approximately 10–20% of the time. Now sure people make mistakes, too. But we shouldn't forget that AI tools are software. And people expect software to be reliable and predictable.

But AI isn't. Now, there is still value in AI, of course. And perhaps it's not a problem if you need a summary of a report. But it's a problem if you give financial advice in a banking application. It needs humans to verify the quality in these scenarios.

AI can cause the Product-Market-Fit threshold to “inflect”, causing product market fit collapse.

Unsurprisingly, so many AI products out there experience product fit collapse. And so every time I see people speaking about AI replacing humans, I shrug. I’m taking many discussions and bold statements about that with a big pinch of skepticism.

Missing Human Component of AI #

Now, it’s not that AI can’t solve problems, although it does have some severe limitations in doing so. It’s that we always focus so intensely on the benefits of AI, often forgetting, overlooking or pushing aside the human experience with it.

A helpful framework to design AI experiences: Task Expertise vs. AI Performance. Features that require nearly-perfect AI performance to be useful are impossible to build.

Experience created by humans, with attention to human’s needs and intentions, designed and built and tested with humans, embedding human values and working well for humans. If anything, we should be more obsessed with humans, not with AI.

If anything, AI amplifies the need for 4 things:

Authenticity
A shift from generic and fast high-fidelity prototypes to actual products with embedded values, beliefs, opinions.
Curation
Content, features, priorities, reviewed and approved by humans.
Critical thinking
Ability to raise uncomfortable questions and raise red flags.
Strategy
Briding the gap between the current state and future state, considering user needs and business needs.

Surely, AI can spin up rough prototypes quickly, but getting it to an actual working product requires work. Somebody must orchestrate the process and finesse the experience. And it requires thorough strategic work.

And that's a big change upon us.

We're Moving From Tactics to Strategy #

Yes, designer’s tasks will surely change. We probably won't be pushing pixels around and hunt annoying bugs for hours, but perhaps that's a good thing. Instead, we'll be more strategic — shaping the vision of the project, planning for success, and curating experiments to run.

Still, with many AI experiences, we will need to rely on people in the loop — orchestrating the design, the development, the product management, and everything in-between — instead of moving pixels or fixing annoying bugs. And perhaps that's a good thing.

No technology can create clarity, structure, trust and care out of poor content, poor metadata, and poor value for end users. Personally, I don’t think that any AI can out-care, out-love or out-trust that level of attention that humans bring to the table.

If we design with humans in mind, consider human's needs and wants and struggles, we can help users and businesses bridge that gap in a way AI never could.

Sad Truths On What It’s Like To Be A Designer

Vitaly Friedman — Mon, 19 May 2025 00:00:00 +0000

Earlier today I stumbled again upon a wonderful short piece on Sad Truths On What It’s Like To Be A Designer by Michael McWatter. It’s an honest and on-point overview of some little sad truths that many of us experience in our careers. As it has turned out, being a designer isn’t particularly easy.

Sad Truths On What It’s Like To Be A Designer, a concise and funny summary by Michael McWatters.

The delta between what you designed and what gets shipped can be measured in light years.
You will redo your late-night work from scratch first thing the next morning.
Many senior designers are survivors of internal politics, rather than evolvers.
Your stakeholders will probably choose the option you like the least: so be careful what you show.
If you run OS upgrade on a workday, you’ll be asked for urgent changes immediately.
Perfect is the enemy of good, but it won’t stop you from trying.
You will never convince anyone to use a proper em-dash.
Naming things will be the most nerve-wrecking part of your job.
Brainstorming is about gathering ideas, then ignoring most of them.
All the research in the world is no match for your stakeholder’s opinion.
Agency designers had their souls crushed, but they never miss a deadline.
No one will ever review your UX copy until it’s live and wrong.
You haven’t shipped your work until stakeholders decide that you did.
Files stored under “Experiments” will usually hold your best work.
You’ll spend hours solving problems that shouldn’t even exist.

Many items above feel so relatable, and hit home for me — in fact, most of them happened multiple times, or hold true this very day. Yet still, despite all these sad moments, being a designer isn’t sad — it’s exhilarating! It’s full of moments of joy and craftsmanship and playing and tweaking the pieces of a puzzle.

Design Is About Care and Love #

Over the weekend I also stumbled upon a wonderful post by Bob Baxley, in which Bob hinted at an interview with Jony Ive, and argued about the challenges of reducing the value of design to a number. Because truly good design is more than that: it’s about care and love.

If you have around 50 mins this weekend, I highly recommend you to watch the interview — it had a profound effect on me, reminding me again about why I’m in this industry in the first place.

Interview with Jony Ive, about the value and the impact of design.

Ironically, I have launched a whole course about reducing design to metrics, and so I replied to Bob in the comments:

Vitaly: “For the last few years, I've been trying to advocate for just what you are mentioning — speaking the language of the business, measuring the impact of UX, and making strong arguments on business value of accessibility and research efforts.

Now, looking back, I realize that this is probably the only way that I've discovered over the years to effectively articulate the significance of good design. There has been very little understanding of the value of emotional impact of design beyond loyalty, retention and NPS scores.

And so I used UX metrics to open the door for broader initiatives, to get buy-ins and budgets and commitments to UX. Without it, all design efforts appear to be uncomfortably mysterious and barely noticeable, and hence — unfortunately — often not worth an investment.

Once I open the door, I try to do the best work I can to not just solve a functional imperative (as Jony eloquently puts it), but to bring along trust, joy, optimism, hope, pleasure — and to make people feel valued, understood, noticed, thought of.

It's just, unfortunately, that magical part usually comes later, rather than sooner. But to me, that’s the essence of truly great design.”

Bob then answered with something that I found very difficult to disagree with:

Bob: “If you bring a spreadsheet to a design review you’ve already lost. If you try to argue the value of design on the basis of business, you’ve already ceded the battlefield. And if you give up on the deep, emotional, human reason you got into Design in the first place, you’re going to end up in a place you don’t recognize.”

In my gut, I wholeheartedly agree with Bob.

Yet in some other way, I felt defeated for years. I felt stuck, blocked, dismissed, rejected in many projects as my aspirations for accessibility and good UX work weren’t heard or understood. I simply couldn’t get anywhere, often dismissed even before the very first meeting.

Surely it has been changing over the years, but speaking to the emotional impact of design proved to be remarkably difficult. And the explanation I could bring would be around loyalty and customer satisfaction, which then worked much better.

UX Can Be Measured, But It’s More Than Metrics #

I still believe that we should be able to measure UX to understand how well we are performing, and to show the incredible impact we are producing on business. But it’s never the full story.

No business can be successful without successful customers. And my job is to do both. And despite every political powerplay, arguing about UX metrics, impossible requests, or vague design briefs, there’s always an opportunity to shape something meaningful. Something that might actually change somebody’s life for the better.

Frankly, if that’s not a superpower, I don’t know what is.

And that’s exactly what keeps me going every day.

Happy designing, everyone! 🎉🥳

Data vs. Findings vs. Insights in UX

Vitaly Friedman — Wed, 14 May 2025 00:00:00 +0000

In many companies, data, findings and insights are all used interchangibly. Slack conversations circle around convincing data points, statistically significant findings, reliable insights and emerging trends. Unsurprisingly, often conversations mistake sporadic observations for consistent patterns.

But how impactful is the weight that each of them carries? And how do we turn raw data into meaningful insights to make better decisions? Well, let's find out.

Data ≠ Findings ≠ Insights. Short video by NN/g explains the differences between them.

Why It All Matters #

At first, it might feel like the differences are very nuanced and merely technical. But when we review inputs and communicate outcomes of our UX work, we need to be careful not to conflate terminology — to avoid wrong assumptions, wrong conclusions and early dismissals.

Raw data points is random and inconclusive. For it to be valuable, it must be turned into insights. Cartoon by Hugh MacLeod.

When strong recommendations and bold statements emerge in a big meeting, inevitably there will be people questioning decision making process. More often than not, they will be the loudest voices in the room, often with their own agenda and priorities that they are trying to protect.

As UX designers, we need to be prepared for it. The last thing we want is to have a weak line of thinking, easily dismantled under the premise of “weak research”, “unreliable findings”, “poor choice of users” — and hence dismissed straight away.

Data ≠ Findings ≠ Insights #

People with different roles — analysts, data scientists, researchers, strategists — often rely on fine distinctions to make their decisions. The general difference is easy to put together:

Data is raw observations (logs, notes, survey answers) (what was recorded).
Findings describe emerging patterns in data, but aren’t actionable (what happened).
Insights are business opportunities (what happened + why + so what).
Hindsights are reflections of past actions and outcomes (what we learned in previous work)
Foresights are informed projections, insights with extrapolation (what could happen next)

Business value emerges from turning hindsights into insights, then then insights into foresights. From: The Hidden Truth of Business.

Here’s what it then looks like in real-life:

Data ↓
6 users were looking for ”Money transfer” in “Payments”, and 4 users discovered the feature in their personal dashboard.
Finding ↓
60% of users struggled to find the “Money transfer” feature on a dashboard, often confusing it with the “Payments” section.
Insight ↓
Navigation doesn’t match users’ mental models for money transfer, causing confusion and delays. We recommend to rename sections or reorganize the dashboard to prioritize “Transfer Money”. It could make task completion more intuitive and efficient.
Hindsight ↓
After renaming the section to “Transfer Money” and moving it to the main dashboard, task success increased by 12%. User confusion dropped in follow-up tests. It proved to be an effective solution.
Foresight ↓
As our financial products become more complex, users will expect more simple task-oriented navigation (e.g., “Send Money”, “Pay Bills“) instead of categories like “Payments”. We should evolve the dashboard towards action-driven IA to meet user expectations.

Only insights create understanding and drive strategy. Foresights shape strategy, too, but are always shaped on bets and assumptions. So unsurprisingly, steakholders are interested in insights, not findings. They rarely need to dive into raw data points. But often they do want to make sure that findings are reliable.

That’s when eventually the big question about statistical significance comes along. And that’s when ideas and recommendations often get dismissed without a chance to be explored or explained.

“But Is It Statistically Significant?” #

Now, for UX designers, that’s an incredibly difficult question to answer. As Nikki Anderson pointed out, statistical significance was never designed for qualitative research. And with UX work, we’re not trying to publish academic research or prove universal truths.

What we are trying to do is reach theoretical saturation, the point where additional research doesn’t give us new insights. Research isn’t about proving something is true. It’s about preventing costly mistakes before they happen.

Consequence cheat sheet for turning findings into insights. By Nikki Anderson.

Here are some useful talking points to handle the question:

5 users per segment often surface major issues, and 10-15 users per segment usually reach saturation. If we’re still getting new insights after that, our scope is too broad.
“If 5 people hit the same pothole and wreck their car, how many more do you need before fixing the road?”
“If 3 enterprise customers say onboarding is confusing, that’s a churn risk.”
“If 2 usability tests expose a checkout issue, that’s abandoned revenue.”
“If 1 customer interview reveals a security concern, that’s a crisis waiting to happen.”
“How many user complaints exactly do we need to take this seriously?”
“How much revenue exactly are we willing to lose before fixing this issue?”

And: it might not be necessary to focus on the number of participants, but instead, argue about users consistently struggling with a feature, mismatch of expectations and a clear pattern emerging around a particular pain point.

How To Turn Findings In Insights #

Once we notice patterns emerging, we need to turn them into actionable recommendations. Surprisingly, this isn’t always easy — we need to avoid easy guesses and assumptions as far as possible, as they will invite wrong conclusions.

To do that, you can rely on a very simple but effective framework to turn findings in insights: What Happened + Why + So What:

“What happened” covers observed behavior and patterns.
“Why” includes beliefs, expectations, or triggers.
“So What” addresses impact, risk, business opportunity.

To better assess the “so what” part, we should pay close attention to the impact of what we have noticed on desired business outcomes. It can be anything from high-impact blockers and confusion to hesitation and inaction.

I can wholeheartedly recommend to explore Findings → Insights Cheatsheet in Nikki Anderson’s wonderful slide deck, which has examples and prompts to use to turn findings into insights.

When presenting the outcomes of your UX work, focus on actionable recommendations and business opportunities, rather than patterns that emerged during testing.

To me, it’s all about telling a good damn story. Memorable, impactful, feasible, convincing. Paint the picture of what the future could look like, and the difference it would produce. That’s where the biggest impact from UX work emerges.

Useful Resources #

How To Deal With “Is This Statistically Significant?”, by Nikki Anderson
Data vs. Findings vs. Insights: Differences Explained (+ video), by Sara Paul, NN/g
Research Findings vs Insights vs Actionable Suggestions, by Debbie Levitt

Design System in 90 Days

Vitaly Friedman — Wed, 30 Apr 2025 00:00:00 +0000

So we want to set up a new design system for our product. How do we get it up and running from scratch? Do we start with key stakeholders, UI audits, or naming conventions? And what are some of the critical conversations we need to have early to avoid problems down the line?

Fortunately, there are a few useful little helpers to get started — and they are the ones I tend to rely quite a bit when initiating any design system projects.

Design System In 90 Days Canvas #

Design System in 90 Days Canvas (FigJam template) is a handy set of useful questions to start a design system effort. Essentially it’s a roadmap to discuss everything from the value of a design system to stakeholders to teams involved to components to start with.

A neat little helper to get a design system up and running — and adopted! — in 90 days. Created for small and large companies that are building a design system or plan to set up one. Kindly shared by Dan Mall.

Practical Design System Tactics #

Design System Tactics is a practical overview of tactics to help designers make progress with a design system at every stage — from crafting system principles to component discovery to design system office hours to cross-brand consolidation. Wonderful work by one-and-only Ness Grixti.

Design System Worksheet (PDF) #

Design System Checklist by Nathan Curtis (download the PDF) is a practical 2-page-worksheet for a 60-mins team activity, designed to choose the right parts, products and people for your design system.

Of course, the point of a design system is not to be fully comprehensive or cover every possible component you might ever need. It’s all about being useful enough to help designers produce quality work faster, and be flexible enough to help designers make decisions, rather than make decisions for them.

Useful Questions To Get Started With #

The value of a design system lies in it being useful and applicable — for a large group of people in the organization. And, according to Dan, a good start is to identify where exactly that value would be most helpful to tackle company’s critical challenges and goals:

What is important to our organization at the highest level?
Who is important to our design system effort?
What unofficial systems already exist in design and code?
Which teams have upcoming needs that a system could solve?
Which teams have immediate needs that can grow our system?
Which teams should we and have we talked to?
Which stakeholders should we and have we talked to?
What needs, desires, and concerns do our stakeholders have?
What components do product or feature teams need now or soon?
What end user problems/opportunities could a system address?
What did we learn about using other design systems?
What is our repeatable process for working on products?
What components will we start with?
What needs, desires, and concerns do our stakeholders share?
Where are our components currently being used or planned for?
What data do our customers need from a reference website?
When will we be working on each component?
How does our team make decisions?
How do we name our system to make people smile when they hear it?
What housekeeping items will we do in Systems Week?

Useful Resources #

Here are a few other useful tools that might help you in your design system efforts:

Design System Questions To Answer In First 90 Days, by Dan Mall
Design System Canvas (PDF / Figjam), by Paavan Buddhdev
LeanDS Framework (Figma), by Marianne Ashton-Booth
Useful UX Templates For Designers (Figma Kits), by yours truly Vitaly Friedman
Design System Guide, by Romina Kavcic

Wrapping Up #

A canvas often acts as a great conversation starter. It’s rarely complete, but it brings up topics and issues that one wouldn’t have discovered on spot. We won’t have answers to all questions right away, but we can start moving in the right direction to turn a design system effort into a success.

Happy crossing off the right tickboxes! 🎉🥳

How To Launch Big Complex Projects

Vitaly Friedman — Wed, 23 Apr 2025 00:00:00 +0000

Think about your past projects. Did they finish on time? Did they get delivered without cutting corners? Chances are high that they haven’t. Perhaps they got delayed, moved, cancelled, “refined” or postponed. As it turns out, in many teams, shipping on time is an exception, rather than the rule.

Things almost never go according to the plan — and on complex projects, they don’t even come close. So how can we prevent it from happening? Well, let's find out.

99.5% Of Big Projects Overrun Budgets And Schedules #

As people, we are inherently over-optimistic and over-confident. It’s hard to study and process everything that can go wrong, so we tend to focus on the bright side. However, unchecked optimism leads to unrealistic forecasts, poorly defined goals, better options ignored, problems not spotted, no contingencies to counteract the inevitable surprises.

The blue line follows a normal distribution, the red line follows “fat tails” — sometimes big outliers are quite common. Image source.

Hofstadter’s Law states that the time needed to complete a project will always expand to fill the available time — even if you take into account the Hofstadter’s Law. Put differently, it always takes longer than you expect, however precautious you might be.

As a result, only 0.5% of big projects make the budget and the schedule — e.g. big relaunches, legacy re-dos, big initiatives. We might try to mitigate risk by adding 15–20% buffer — but it rarely helps. Many of these projects don’t follow “normal” (Bell curve) distribution, but are rather “fat-tailed”.

And there, overruns of 60–500% are typical and turn big projects into big disasters.

Reference-Class Forecasting (RCF) #

We often assume that if we just thoroughly collect all the costs needed and estimate complexity or efforts, we should get a decent estimate of where we will eventually land. Nothing could be further from the truth.

Complex projects have plenty of unknown unknowns. No matter how many risks and dependencies and upstream challenges we identify, there are many more we can’t even imagine. The best way to be more accurate is to define a realistic anchor — for time, costs and benefits — from similar projects done in the past.

IT projects are more likely to have a fat-tailed distribution, with extreme outliers.

Reference-class forecasting follows a very simple process:

First, we find the reference projects that have most similarities to our project,
If the distribution follows the Bell curve, use the mean value + 10–15% contingency.
If the distribution is fat-tailed, invest in profound risk management to prevent big challenges down the line.
Tweak the mean value only if you have very good reasons to do so.
Set up a database to track past projects in your company (for cost, time, benefits).

Think Slow + Act Fast #

In spirit of looming deadlines, many projects rush into delivery mode before the scope of the project is well-defined. It might work for fast experiments and minor changes, but that’s a red flag for larger projects. The best strategy is to spend more time in planning before designing a single pixel on the screen.

But planning isn’t an exercise in abstract imaginative work. Good planning should include experiments, tests, simulations, refinements. It must include the steps of how we reduce risks and how we mitigate risks when something unexpected (but frequent in other similar projects) happens.

In IT, mean cost overrun is around 73%, and 18% have >50% overruns (fat-tailed distribution). Mean overruns of these projects are 447% (!).

Black Swan Management #

Every other project encounters what's called a Black Swan — a low probability, high-consequence event that is more likely to occur when projects stretch over longer periods of time. It could be anything from restructuring teams to change of priorities, which then lead to cancellations and re-scheduling.

Little problems have an incredible capacity to compound to large, disastrous problems — ruining big projects and sinking big ambitions at a phenomenal scale. The more little problems we can design around early, the more chances we have to the project out of the door successfully.

So we make projects smaller and shorter. We mitigate risks by involving stakeholders early. We provide less surface for Black Swans to emerge. One good way to get there is to always start every project with a simple question: “Why are we actually doing this project?” The answers often reveal not just motivations and ambitions, but also the challenges and dependences hidden between the lines of the brief.

And as we plan, we could follow a “right to left thinking”. We don’t start with where we are, but rather where we want to be. And as we plan and design we move from the future state towards the current state, studying what’s missing or what’s blocking us from getting there. The trick is: we always keep our end goal in mind and our decisions and milestones are always shaped by that goal.

Manage Deficit of Experience #

Complex projects start with a deep deficit of experience. To increase the chances of success, we need to minimize the chance of mistakes even happening. That means trying to make the process as repetitive as possible — with smaller “work modules”, repeated by teams over and over again.

🚫 Beware of unchecked optimism → unrealistic forecasts.
🚫 Beware of “cutting-edge” → untested technology spirals risk.
🚫 Beware of unique” → high chance of exploding costs.
🚫 Beware of “brand new” → rely on tested and reliable.
🚫 Beware of “the biggest” → build small things, then compose.

It also means relying on reliable: from well-tested tools to stable teams that have worked well together in the past. Complex projects aren’t a good place to innovate processes, mix-n-match teams and try out more affordable vendors.

Typically, these are extreme costs in disguise, skyrocketing delivery delays and unexpected expenses.

Good Design Is Good Risk Management #

When speaking about design and research to senior management, position it as a powerful risk management tool. Good design that involves concept testing, experimentation, user feedback, iterations and refinement of the plan is cheap and safe.

Eventually it might need more time than expected, but it's much — MUCH! — cheaper than delivery. Delivery is extremely cost-intense, and if it relies on wrong assumptions and poor planning, then that's when the project becomes vulnerable and difficult to move or re-route.

Wrapping Up #

The insights above come from a wonderful book on “How Big Things Get Done” by Prof. Bent Flyvbjerg and Dan Gardner. It goes in all the fine details of how big project fails and when they succeed. It’s not a book about design, but a fantastic book for designers who want to plan and estimate better.

Not every team will work on a large, complex project, but sometimes these projects become inevitable — when dealing with legacy, projects with high visibility, layers of politics or an entirely new domain where the company moves towards.

Good projects that succeed have one thing in common: they dedicate a majority of time in planning and maneuvring risks and unknown unknowns. They avoid big-bang revelations, but instead test continuously and repeatedly.

That's your best chance to succeed — work around these unknowns as you won't be able to prevent them from emerging entirely anyway.

UX and Design Organization Templates

Vitaly Friedman — Fri, 18 Apr 2025 00:00:00 +0000

🔥 UX & Design Files Organization Template (Google Doc + .zip-file), with an overview of little helpers to neatly organize UX assets in sensible folders ↓

UX & Design Files Organization Template, by Courtney Pester

Full folder structure template (Google Doc)

Compressed .zip file folder structure

Probably the most underrated problem in any type of file structure organization is duplications and versioning. Before we start the project, we need to be very clear about what types of files should end up in the shared drive, and which not. You might or might not need intermediate versions of some documents, but you definitely want to keep the final ones.

These are typically the questions I would be raising:

Do we need to restrict access to some sections of the folder (e.g. sensitive data)?
What naming conventions do we use for files/folders (e.g. semantic versioning, V1, V2, --FINAL)
How do we manage deprecated or outdated files? Do we archive or delete them?
What would be the main communication channel for stakeholders/clients?
Are there any legal requirements for storing and sharing some specific files?
What will happen to the shared space once the project has finished?

And: don’t feel compelled to replicate any file structure entirely. Use it as a foundation to be inspired by and build upon. Customize away for the specific needs of your projects and your team. What works for you works for you. There is really no perfect and universal way that works out of the box.

How do you organize your files and assets? What folder structures and organization systems do you use? What works best for you?

Happy organizing, everyone! 👏🏼👏🏽👏🏾

Your vs. My? UX Writing Guidelines

Vitaly Friedman — Mon, 07 Apr 2025 00:00:00 +0000

When you design an interface, which pronouns do you usually use to address your users? Do you write “My account” or “Your account”? “My drafts” or “Your drafts” — or only “Drafts”? And does it actually matter?

In this newsletter, we’ll shine some light on the different meanings that pronouns carry, so you can choose the one that best reflects the personality of your product.

Shaping Personality With Pronouns #

Pronouns might seem like a fine little detail. But the pronouns we use in our interfaces shape a user’s relationship with the product, and it does matter. In general, users perceive products either as tools or assistants. Tools suggest a higher degree of ownership; assistants suggest that the UI speaks to the user.

A good example of how the choice of pronouns creates meaning. Netflix uses “Your” for recommendations (assistant) and “My” for the watchlist that the user curates themselves (tool).

If there is no ambiguity, you might not need a pronoun at all. However, if you want to emphasize a user’s ownership of content or actions, “My” works better (“My account”). And if you want to strike a more conversational tone, speak directly to the user (“Your places”).

As John Saito wrote, using “My” in an interface implies that the product is labelling things on behalf of the user. “My” feels personal, and it feels that you can fully customize and control it. Hence, it’s more suitable for privacy settings and personalization.

Different UIs suggest different perspective on pronouns: Google Drive (“my”), YouTube (“Your”) and Dropbox (no pronoun).

When we think about “Your” in an interface, it’s like a product is walking a user through the tasks they have to perform — paying bills, scheduling an appointment, filling in a long-winded form. Typically, if tasks are mechanical and less user-owned, “Your” works well. However, you will find many products using “Your” everywhere, by default (see below).

Many products adapt “Your” by default, taking a role of an assistant. Examples: Amazon and Spotify.

While there are occasions where we can remove pronouns entirely, sometimes, we do need them for clarity — e.g., “Stories” alone doesn’t make it obvious if it’s user’s stories, curated highlights, or related stories. In such a case, “Recommended Stories” or “Top Highlights” works better.

Pronouns might not sound like a big deal, but they communicate volumes about your perspective and the personality of your product. So be deliberate in shaping and finetuning it. Because if you don’t, users will imagine your personality for you — and it might be not at all what you imagined it to be.

Different Pronouns, Different Nuances #

The first question to ask before choosing a pronoun is what voice and tone your product and its features should communicate to users. Should it communicate ownership and control (“My”)? Or should it feel like an assistant speaking to a user (“Your”)? Or should it be concise and straight-to-the point (no pronouns)?

1st Person: “My” #

Suggests a higher degree of ownership.
Works best for user-created content, actions, preferences.
E.g. personal inbox, dashboard, delivery orders, purchases (“My profile”, “My preferences”, “My saved items”, etc.).
Effect: Users perceive the UI as an extension of their identity.

2nd Person: “Your” #

Suggests the UI is speaking to the user.
Works best for system-initiated content for a user.
E.g., onboarding, instructions, buttons, error messages, help text, labels (“Your recommendations”, “Your local events”, “Your activity summary”, etc.).
Effect: Users perceive the UI as a separate entity speaking to them.

No Pronoun #

Neutral, keywords-based labels that communicate the purpose directly.
Works when there is no ambiguity.
E.g. “Settings”, “Profile”, “Drafts”.

Never mix different pronouns, because it will confuse the users. They need to understand if they have control and your product is just an extension of them or if you want to guide them and help them complete their tasks.

Who Else Is In The Room? #

I've found one helpful trick to keep in mind when deciding which pronoun to choose in an article by Diana MacDonald. Diana suggests that if you are unsure whether to use “My” or “Your,” ask yourself: “Who else is in the room?”

A: There’s no one in the room except the user.
↳ Skip the pronoun altogether.

B: The product is talking to the user.
↳ Use “Your” (e..g., “Your Presets”).

C: The user is talking to the product.
↳ Use “My” (e.g., “Save My Draft”).

When choosing a pronoun, be careful to never misrepresent the system’s decisions as the user’s decisions. And remember, if there is no ambiguity, you might not need a pronoun at all.

Useful Resources #

Write Better User Interfaces by Asking “Who Else is in the Room?”, by Diana MacDonald
Is This My Interface Or Yours?, by John Saito
Proper Possessive Pronouns in UX, by Vitaly Santana
‘I’ or ‘You’? — Exploring The Use Of Person In Content Design, by Pearl Xu
Yours vs. Mine, by Dustin Curtis

Wrapping Up #

Every detail, as small or as obvious as it might seem, contributes to the story you tell with your product. And pronouns are one such mighty little detail that shapes a product’s personality and how users perceive it.

We hope that the tips in this newsletter will help you back up that gut feeling you had when choosing pronouns with facts so that you can make more informed decisions and resolve never-ending discussions for your interfaces.

UX Guidelines For Better URL Design

Vitaly Friedman — Mon, 31 Mar 2025 00:00:00 +0000

When it comes to URLs, there’s a common assumption that most people don’t pay attention to them. That people don’t even notice URLs, don’t remember them, and that they can always re-find what they are looking for anyway. But this couldn’t be further from the truth.

People do still read URLs in search engines every day, and although AI is changing user behavior, URLs continue to play an important role for the user experience. So, what makes an effective URL? Let’s take a closer look.

Three Key Tasks Of Good URLs #

Good URLs support 3 key tasks: they explain to users where they will go or where they are, they support sharing in social networks, and they serve as strong signal for search engines. The best way to achieve all of this is by keeping URLs short and simple.

The anatomy of a URL. Originally put together by Semrush.

At this point, we don’t need to stuff URLs with keywords to perfectly match the title. They must be unique, but consider if one or two keywords would be enough to communicate their purpose.

Remove what you can remove (e.g., www, home.html, etc.) and be consistent about trailing slashes to prevent URL duplication (i.e., choose between /news/ and /news, and create 301 redirects from the one you don’t use).

Checklist For A Well-Designed URL #

Make It Short And Readable #

A good URL is a mini description of a page. It needs to be both human- and machine-readable.

Shorter is better, max. 60–75 characters.
Lowercase only, not mixedCase and not UPPERCASE.
Use hyphens (-) to separate words, not underscores (_).
Use stems of verbs (e.g., /make-thing rather than /making-thing).
Stop words (“the”, “and”, “in”, “a”) are not needed but won’t hurt SEO.

Make It Logical #

People send URLs via email, WhatsApp, or print them in PDFs, so a logical structure is key to ensuring they can easily make sense of a URL.

Use logical hierarchies that tell a story (e.g., /en/topics/ukraine).
Include dates for date-specific documents.
Multilingual sites need language-specific subfolders (e.g., /en/, /fr/, etc.).

Make It Easy To Type #

Typing simple words is easier than typing a string of random characters.

Avoid empty spaces as / text/ is turned into /%20text/.
Avoid special and reserved characters (e.g., #, ?, &, =, +, %, /).
Avoid accent characters like ü, ö, ß, é (e.g., ü turns into %C3%BC in an URL).
Avoid repeating keywords and complex shorteners.
Set up short links for important pages (e.g., europarl.eu/go/DMA2025).

Examples Of Good URL Design #

A great test for the brevity and clarity of URLs is if you can spell a chosen URL on a mobile phone or write it on a piece of paper. And sometimes, it might be a good idea to set up aliases that people can use — to make the URL more marketable and more memorable.

Here are some examples of how we can tweak an existing URL to make it more user-friendly:

https://www.un.com/plenary/en/home.html → live.un.com/plenary
/about-our-company/ → company.com/about
/frequently-asked-questions/ → company.com/faq
/locations/us/nebraska/lincoln/havelock → locations/havelock
/press-releases-announcements/ → company.com/press
/designing-digital-products/ → /product-design/
/delivering-new-features/ → /deliver-features/

URLs In Times Of AI #

With AI assistants like ChatGPT, Claude, Perplexity, and AI search (including Google’s) on the rise, there is a strong sentiment that URLs are irrelevant these days as people don’t navigate to pages any longer. However, the effect isn’t as noticeable as one might think.

There is definitely a shift happening, but according to Rand Fishkin’s research, users perform 126 searches per month on Google (new record!), and Google has been growing steadily from year to year, including in 2024.

In 2024, the number of searches with Google Search was approximately 373 times larger than searches with ChatGPT. (Credit: Rand Fishkin)

We don’t know how much time is spent clicking through pages and how much reading AI responses. But it’s wrong to say that AI is troubling Google — users just search more. As of March 2025, Google’s market share is at 93.57% and ChatGPT is only at 0.25%. So let’s give our URLs a bit of extra love to make them more effective — for our users, but also to boost the SEO of our pages.

URL Guidelines In Design Systems #

Setting up guidelines for URL design is a good idea to ensure everyone on the team follows the same logic. Here are some great examples from how real-world design systems document their URL standards.

Useful Resources #

URL Design Checklist, by Gov.au
Google SEO Guidelines
Your Website’s URLs Can and Should Be Beautiful, by Jason Morehead
The Hidden UX of URLs, by Michael Soriano
A Complete Guide to URL Design, by Christine Skopec, Zach Paruch

Wrapping Up #

A URL might be a small detail and one that easily falls through the cracks given the more obvious user experience challenges that we need to solve in our work every day. However, URLs play a critical role in providing orientation for users, simplifying sharing, and serving as SEO for search engines.

Luckily, designing better URLs isn’t a big commitment once you’ve understood what to watch out for. We hope that the tips above will inspire you to take another look at your URLs and to tweak them if needed to make them even more useful.

How To Argue Against AI-First Research

Vitaly Friedman — Wed, 12 Mar 2025 00:00:00 +0000

With AI upon us, companies have recently been turning their attention to “synthetic” user testing — AI-driven research that replaces UX research. There, questions are answered by AI-generated “customers”, human tasks “performed” by AI agents.

However, it’s not just for desk research or discovery that AI is used for; it’s an actual usability testing with “AI personas” that mimic human behavior of actual customers within the actual product. It’s like UX research, just... well, without the users.

One of the tools to conduct “synthetic testing”, or AI-generated UX research, without users.

If it sounds worrying, confusing and outlandish, it is — but it doesn’t stop companies from adopting AI “research” to drive business decisions. Unsurprisingly, it’s dangerous, risky and expensive — and usually diminishes user value.

Fast, Cheap, Easy... And Imaginary #

Erika Hall famously noted that “design is only as human-focused as business model allows for it”. If a company is heavily driven by hunches, assumptions and strong opinions, there will be little to no interest in properly done UX research in the first place.

The opportunity for business value is in delivering user value when users struggle. By Erika Hall.

But unlike UX research, AI research (conveniently called synthetic testing) is fast, cheap and easy to re-run. It doesn’t raise uncomfortable questions, and it doesn’t flag wrong assumptions. It doesn’t require user recruitment, much time or long-winded debates.

And: it can manage thousands of AI personas at once. By studying AI-generated output, we can discover common journeys, navigation patterns and common expectations. We can anticipate how people behave and what they would do.

Well, that’s the big promise. And that’s where we start running into big problems.

LLMs Are People Pleasers #

Good UX research has roots in what actually happened — not what might have happeend, or what might happen in the future.

By nature, LLMs are trained to provide the most “plausible”, or most likely output based on patterns captured in its training data. These patterns, however, emerge from expected behaviors by statistically “average” profiles extracted from the content on the web. But these people don’t exist, they never have.

By default, user segments are not scoped and not curated. They don’t represent the customer base of any product. So to be useful, we must eloquently prompt AI by explaining who users are, what they do and how they behave. Otherwise, the output won’t match user needs, and won’t apply to our users.

Every LLM hallucinates, but newer models perform better at some tasks, such as summarizing. By Nature.com.

When “producing” user insights, LLMs can’t generate unexpected things beyond what we’re already asking about.

In comparison, researchers are only able to define what’s relevant as the process unfolds. In actual user testing, insights can help shift priorities or radically reimagine the problem we’re trying to solve, as well as potential business outcomes.

Real insights come from unexpected behavior, from reading behavioral clues and emotions, from observing a person doing the opposite of what they said. We can’t replicate it with LLMs.

AI User Research Isn’t “Better Than Nothing” #

Pavel Samsonov articulates that things that sound like customers might say them are worthless. But things that customers actually have said, done or experienced carry inherent value (although they could be exaggerated). We just need to interpret them correctly.

AI user research isn’t “better than nothing”, or “more effective”: it creates an illusion of customer experiences that never happened, and are at best good guesses, but at worst misleading and non-applicable. Relying on AI-generated “insights” alone isn’t much different than reading tea leaves.

Cost Of Mechanical Decisions #

We often hear about the breakthrough of automation and knowledge generation with AI. Yet we often forget that automation often comes at a cost — the cost of mechanical decisions that are typically indiscriminate, favor uniformity and erode quality.

Some research questions generated by AI could be useful, others useless. By Maria Rosala.

As Maria Rosala and Kate Moran write, the problem with AI research is that it most certainly will be misrepresentative, and without real research, you won't catch and correct those inaccuracies. Making decisions without talking to real customers is dangerous, harmful and expensive.

Beyond that, synthetic testing assumes that people fit in well-defined boxes, which is rarely true. Human behavior is shaped by our experiences, situations, habits that can’t be replicated by text generation alone. AI strengthens biases, supports hunches and amplifies stereotypes.

Triangulate Insights, Not Verify Them #

Of course AI can provide useful starting points to explore erly in the process. But inherently it also invites false impressions and unverified conclusions — presented with an incredible level of confidence and certainty.

Starting with human research is just much more reliable — conducted with real customers using a real product. Then we could apply AI to see if we perhaps missed something critical in user interviews. AI can enhance, but not replace UX research.

Triangluate linear customer journeys by layering them on top of each other to identify most frequent areas of use. By John Cutler.

Also, when we do use AI for desk research, it can be tempting to try to “validate” AI “insights” with actual user testing. However, once we plant a seed of insight in our head, it’s easy to recognize its signs everywhere — even if it really isn’t there.

Instead, we study actual customers, then triangulate data: track clusters, or most heavily trafficked parts of the product. It might be that analytics and AI desk research confirm your hypothesis. That would give you a much stronger standing to move forward in the process.

Wrapping Up #

I might sound like a broken record, but I keep wondering why we feel the urgency to replace UX work with automated AI tools. Good design requires a good amount of critical thinking, observation and planning observation.

To me personally, cleaning up after AI-generated output takes way more time than doing the actual work. There is an incredible value in talking to people who actually use your product.

I would always choose 1 day with a real customer instead of 1 hour with 1000 synthetic users pretending to be humans.

Useful Resources #

Synthetic Users, by Maria Rosala, Kate Moran
Synthetic Users: The Next Revolution in UX Research?, by Carolina Guimarães
AI Users Are Neither AI Nor Users, by Debbie Levitt 🐦‍🔥
Planning Research with Generative AI, by Maria Rosala
Synthetic Testing, by Stéphanie Walter, Nikki Anderson, MA
The Dark Side of Synthetic AI Research, by Greg Nudelman

Useful Customer Journey Maps (+ Figma & Miro Templates)

Vitaly Friedman — Mon, 10 Mar 2025 00:00:00 +0000

User journey maps are a remarkably effective way to visualize user’s experience for the entire team. Instead of pointing to documents scattered across remote fringes of Sharepoint, we bring key insights together — in one single place.

Let’s explore a couple of helpful customer journey templates to get started, and how companies use it in practice.

AirBnB Customer Journey Blueprint #

AirBnB Customer Journey Blueprint (also check Google Drive example) is a wonderful practical example of how to visualize the entire customer experience for 2 personas, across 8 touch points, with user policies, UI screens and all interactions with the customer service — all on one single page.

AirBnB's Customer Journey Blueprint, mapping policies and customer service against a customer journey. Watch a video preview.

Now, unlike AirBnB, your product might not need a mapping against user policies. However, it might need other lanes that would be more relevant for your team. E.g. include relevant findings and recommendations from UX research. List key actions needed for next stage. Relevant UX metrics and unsuccessful touchpoints.

Whatever works for you, works for you — just make sure to avoid assumptions and refer to facts and insights from research.

Spotify Customer Journey Map #

Spotify Customer Journey Blueprint (high resolution) breaks down customer experiences by distinct user profiles, and for each includes mobile and desktop views, pain points, thoughts and actions. Also, notice branches for customers who skip authentication or admin tasks.

Spotify Customer Journey Blueprint, mapping mobile and desktop screens against a customer journey. Large preview.

Getting Started With Journey Maps #

To get started with user journey maps, we first choose a lens: are we reflecting the current state or projecting a future state? Then, we choose a customer who experiences the journey — and we capture the situation/goals that they are focusing on.

A practical guide to customer journey mapping, with free Miro/Figma templates by Steph Walter.

Next, we list high-level actions users are going through. We start by defining first and last stage, and fill in-between. Don’t get too granular: list key actions needed for next stage. Add user’s thoughts, feelings, sentiment, emotional curves.

A guide to customer journey mapping, a practical guide by Taras Bakusevych.

Eventually, add user’s key touchpoints with people, services, tools. Map user journey across mobile and desktop screens. Transfer insights from other research (e.g. customer support). Fill in stage after stage until the entire map is complete.

Then, identify pain points and highlight them with red dots. Add relevant jobs-to-be-done, metrics, channels if needed. Attach links to quotes, photos, videos, prototypes, Figma files. Finally, explore ideas and opportunities to address pain points.

Free Customer Journey Maps Templates (Miro, Figma) #

You don’t have to reinvent the wheel from scratch. Below you will find a few useful starter kits to get up and running fast. However, please make sure to customize these templates for your needs as every product will require its own specific details, dependencies and decisions.

User Journey Map Template (Figma), by Estefanía Montaña B.
Customer Journey Mapping (PDF), by Taras Bakusevych
End-To-End User Experience Map (Figma), by Justin Tan
Customer Journey Map Template (Figma), by Ed Biden
Customer Journey Map Template (Miro), by Matt Anderson
Customer Journey Map (Miro), by Hustle Badger
Customer Experience Map Template (Miro), by Essense
The Customer Journey Map (Miro), by RSPRINT

Wrapping Up #

Keep in mind that customer journeys are often non-linear, with unpredictable entry points, and integrations way beyond the final stage of a customer journey map. It’s in those moments when things leave a perfect path that a product’s UX is actually customer-journey-blueprints tested.

So consider mapping unsuccessful touchpoints as well — failures, error messages, conflicts, incompatibilities, warnings, connectivity issues, eventual lock-outs and frequent log-outs, authentication issues, outages and urgent support inquiries.

Also, make sure to question assumptions and biases early. Once they live in your UX map, they grow roots — and it might not take long until they are seen as the foundation of everything, which can be remarkably difficult to challenge or question later. Good luck, everyone!

How To Build Confidence In Your UX Work

Vitaly Friedman — Sat, 08 Mar 2025 00:00:00 +0000

When I start any UX project, typically there is very little confidence in the successful outcome of my UX initiatives. In fact, there is quite a lot of reluctance and hesitation, especially from teams that have been burnt by empty promises and poor delivery in the past.

Good UX has a huge impact on business. But often we need to build up confidence in our upcoming UX projects. For me, an effective way to do that is to address critical bottlenecks and uncover hidden deficiencies — the ones that affect the people I’ll be working with.

Let’s take a closer look at what this can look like.

UX Doesn’t Disrupt, It Solves Problems #

Bottlenecks are usually the most disruptive part of any company. Almost every team, every unit, and every department has one. It’s often well-known by employees as they complain about it, but it rarely finds its way to senior management as they are detached from daily operations.

The Iceberg of Ignorance: Sidney Yoshida discovered that leadership is usually unaware of the organization's real problems.

The bottleneck can be the only senior developer on the team, or a broken legacy tool, or a confusing flow that throws errors left and right — there’s always a bottleneck, and it’s usually the reason for long waiting times, delayed delivery, and cutting corners in all the wrong places.

We might not be able to fix the bottleneck. But for a smooth flow of work, we need to ensure that non-constraint resources don’t produce more than the constraint can handle. All processes and initiatives must be aligned to support and maximize the efficiency of the constraint.

So before doing any UX work, look out for things that slow down the organization. Show that it’s not UX work that disrupts work, but it’s internal disruptions that UX can help with. And once you’ve delivered even a tiny bit of value, you might be surprised how quickly people will want to see more of what you have in store for them.

The Work Is Never Just “The Work” #

Meetings, reviews, experimentation, pitching, deployment, support, updates, fixes — unplanned work blocks other work from being completed. Exposing the root causes of unplanned work and finding critical bottlenecks that slow down delivery is not only the first step we need to take when we want to improve existing workflows but it is also a good starting point for showing the value of UX.

The work is never just “the work.” In every project — as well as before and after it — there is a lot of invisible, and often unplanned, work going on. (Credit: Dave Stewart)

To learn more about the points that create friction in people’s day-to-day work, set up 1:1s with the team and ask them what slows them down. Find a problem that affects everyone. Perhaps there is too much work in progress that results in late delivery and low quality? Or lengthy meetings stealing precious time?

One frequently overlooked detail is that we can’t manage work that is invisible. That’s why it is so important that we visualize the work first. Once we know the bottleneck, we can suggest ways to improve it. It could be to introduce 20% idle times if the workload is too high, for example, or to make meetings slightly shorter to make room for other work.

The Theory Of Constraints #

The idea that the work is never just “the work,” is deeply connected to the Theory of Constraints discovered by Dr. Eliyahu M. Goldratt. It showed that any improvements made anywhere beside the bottleneck are an illusion.

Any improvement after the bottleneck is useless, because it will always remain starved, waiting for work from the bottleneck. And any improvements made before the bottleneck results in more work piling up at the bottleneck.

Components of UX Strategy: it’s difficult to build confidence in your UX work without preparing a proper UX strategy ahead of time.

Wait Time = Busy ÷ Idle #

To improve flow, sometimes we need to freeze the work and bring focus to one single project. Just as important as throttling the release of work is managing the handoffs. The wait time for a given resource is the percentage that resource is busy, divided by the percentage it’s idle. If a resource is 50% utilized, the wait time is 50/50, or 1 unit.

If the resource is 90% utilized, the wait time is 90/10, or 9 times longer. And if it’s 99% of time utilized, it’s 99/1, so 99 times longer than if that resource is 50% utilized. The critical part is to make wait times visible, so you know when your work spends days sitting in someone’s queue.

The exact times don’t matter, but if a resource is busy 99% of the time, the wait time will explode.

Avoid 100% Occupation #

Our goal is to maximize flow: that means exploiting the constraint but creating idle times for non-constraint to optimize system performance.

One surprising finding for me was that any attempt to maximize the utilization of all resources — 100% occupation across all departments — can actually be counterproductive. As Goldratt noted, “An hour lost at a bottleneck is an hour out of the entire system. An hour saved at a non-bottleneck is worthless.”

Wrapping Up #

People don’t like sudden changes and uncertainty, and UX work often disrupts their usual ways of working. Unsurprisingly, most people tend to block it by default. So before we introduce big changes, we need to get their support for our UX initiatives.

We need to build confidence and show them the value that UX work can have — for their day-to-day work. To achieve that, we can work together with them. Listening to the pain points they encounter in their workflows, to the things that slow them down.

Once we’ve uncovered internal disruptions, we can tackle these critical bottlenecks and suggest steps to make existing workflows more efficient. That’s the foundation to gaining their trust and showing them that UX work doesn’t disrupt but that it’s here to solve problems.

T-Shaped vs. V-Shaped Designers

Vitaly Friedman — Thu, 06 Mar 2025 00:00:00 +0000

Many job openings in UX assume very specific roles with very specific skills. Product designers should be skilled in Figma. Researchers should know how to conduct surveys. UX writers must be able to communicate brand values.

The Many Roles In UX #

Successful candidates must neatly fit within established roles, and excel at tools and workflows that are perceived as the best practice in the industry — from user needs to business needs, and from the problem space to the solution space.

Depending on where your strengths are, you’ll be finding yourself between business, user, problem and solution spaces. By Bas Wallet.

There is nothing wrong with that, of course. However, many companies don’t exactly know what expertise they actually need until they find the right person who actually has it. But: too often job openings don’t allow for any flexibility unless the candidate checks off the right boxes.

In fact, typically UX roles have to fit into some of those rigorously defined and refined boxes:

The many roles and “boxes” in UX, illustrated by Bas Wallet.

“V”-Shaped Designers Don’t Fit Into Boxes #

Job openings typically cast a very restrictive frame for candidates. It comes with a long list of expectations and requirements, mostly aimed at T-shaped designers — experts in one area of UX, with a high-level understanding of adjacent areas, and perhaps a dash of expertise in business and operations.

But as Brad Frost noted, people don’t always fit squarely into a specific discipline. Their value comes not from staying within the boundaries of their roles, but from intentionally crossing these boundaries. They are “V”-shaped — experts in one or multiple areas, with a profound understanding and immense curiosity in adjacent areas.

T-shaped employee vs. V-shaped employee, illustrated by Jeroen Kraaijenbrink.

In practice, they excel at bridging the gaps and connecting the dots. They establish design KPIs and drive accessibility efforts. They streamline handoff and scale design systems. But to drive success, they need to rely on specialists, their T-shaped colleagues.

Shaping Your Own Boxes #

I sincerely wish more companies would encourage their employees to shape their own boxes instead of defining confined boxes for them — their own, unique boxes of any form and shade and color and size employees desire, along with deliverables that other teams would benefit from and could build upon.

🏔️ Hiring? → Maybe replace a long list of mandatory requirements with an open invitation to apply, even if it’s not a 100% match — as long as a candidate believes they can do their best work for the job at hand.

🎢 Seek a challenge? → Don’t feel restricted by your current role in a company. Explore where you drive the highest impact, shape this role and suggest it.

✅ Searching for a job? → Don’t get discouraged if you don’t tick all the boxes in a promising job opening. Apply! Just explain in fine detail what you bring to the table.

You’ve got this — and good luck, everyone! ✊🏽

Decision Trees For UI Components

Vitaly Friedman — Thu, 06 Mar 2025 00:00:00 +0000

How do you know what UI component to choose? 🌳 Decision trees offer a systematic approach for design teams to document their design decisions. Once we’ve decided what UI components we use and when, we can avoid never-ending discussions, confusion and misunderstanding.

Let’s explore a few examples of decision trees for UI components, and how we can get the most out of them.

A fantastic example of a form design component decision trees comes from the Doctolib team.

Doctolib Design System is a very impressive design system with decision trees, B2B navigation paths, photography, PIN input, UX writing and SMS notifications — and thorough guides on how to choose UI components.

One of the many decision trees on Doctolib: from B2B navigation to help components.

I love how practical these decision trees are. Each shows an example of what a component look like, but I would also add references to real-life UI examples and flows of where and how these components are used. A fantastic starting point that documents design decisions better than any guide would.

Decision Trees For UI Components: Workday #

The team behind Workday’s Canvas design system created a fantastic set of design decision trees for notifications, errors and alerts, loading patterns, calls to action, truncation and overflow — with guidelines, examples and use cases, which can now only be retrieved from the archive:

Design never exists in isolation — it must fit user’s context and their expectations to do its job. (Image credit: Engine And Power Dashboard)

For each decision tree, the Workday team has put together a few context-related questions to consider first when making a decision, before even jumping into the decision tree. Plus, there are thorough examples for each option available as well and a very detailed alternative text for every image.

Form Components Decision Tree: Lyft #

A choice of a form component can often be daunting. When to use radio buttons, checkboxes or dropdowns? Runi Goswami from Lyft has shared a detailed form components decision tree that helps their team choose between form controls.

A decision tree for form controls: notably, use dropdown as a method of last resort, with many long options. (Large preview)

We start by exploring if a user can select more than one option in our UI. If it’s indeed multi-select, we use toggles for short options and checkboxes for longer ones.

If only one option can be selected, then we use tabs for filtering, radios for shorter options, switch for immediately applicable options, and checkbox if only one option can be selected. Dropdowns are used as a method of last resort.

Choosing Onboarding Components: NewsKit #

Onboarding comes in various forms and shapes. Depending on how subtle or prominent we want to highlight a particular feature, we can use popovers, badges, hints, flags, toasts, feature cards or design a better empty state. The Newskit team has put together a Onboarding Selection Prototype in Figma.

A decision toolkit for onboarding UX: the more integrated the onboarding is, the more effective it is.

The choice depends on whether we want to interrupt the users to display details (usually isn’t very effective), show a feature subly during the the experience (more effective), or enable discovery by highlighting a feature within the context of a task a user tries to accomplish.

The toolkit asks a designer a couple of questions about the intent of onboarding, and then suggests options that are likely to perform best. A fantastic little helper for streamlined onboarding decision.

Design System Process Flowcharts: Nucleus #

How do you decide to add new component to a design system or rather extend an existing one? What’s the process for contributions, maintenance and the overall design process? Some design teams codify their design decisions as design system process flowcharts, as shown below.

The design system maintenance process by British Gas design system. Large view.

And here are helpful decision trees for adding new components to a design system:

New Component Decision Tree at Boston Scientific
Handling New Patterns at GitHub
Design System Governance Process by Brad Frost
New Component Decision Tree by Louis Ouriach
Design System Contribution Template by Chad Bergman
How To Launch A New Component + Figma template, by Rama Krushna Behera

Make Decision Trees Visible #

What I absolutely love about the decision tree approach is not only that it beautifully visualizes design decisions, but that it also serves as a documentation. It establishes shared standards across teams and includes examples to follow, with incredible value for new hires.

Of course, exceptions happen. But once you have codified the ways of working for design teams as a decision tree and made it front and center of your design work, it resolves never-ending discussions about UI decisions for good.

The entire process at GitHub summarized as a flowchart. Large view.

So whenever a debate comes up, document your decisions in a decision tree. Turn them into posters. Place them in kitchen areas and developer’s and QA workspaces. Put them in design critique rooms. Make them visible where design work happens and where code is being written.

It’s worth mentioning that every project will need its own custom trees, so please see the examples above as an idea to build upon and customize away for your needs.

Happy decision planting, everyone! 🎉🥳

Designing For Stress and Emergency

Vitaly Friedman — Thu, 20 Feb 2025 00:00:00 +0000

You can find more details on design patterns and UX strategy in How To Measure UX 🍣 — with a live UX training coming up this year. Free preview.

No design exists in isolation. As designers, we often imagine specific situations in which people will use our product. It might be indeed quite common — but there will also be other — urgent, frustrating, stressful situations. And they are the ones that we rarely account for.

So how do we account for such situations? How can we help people use our products while coping with stress — without adding to their cognitive load? Let’s take a closer look.

Study Where Your Product Fits Into People’s Lives #

When designing digital products, sometimes we get a bit too attached to our shiny new features and flows — often forgetting the messy reality in which these features and flows have to neatly fit. And often it means 10s of other products, 100s of other tabs and 1000s of other emails.

Design never exists in isolation — it must fit user’s context and their expectations to do its job. (Image credit: Engine And Power Dashboard)

If your customers have to use a slightly older machine, with a smallish 22" screen and a lot of background noise, they might use your product differently than you might have imagined — e.g. splitting the screen into halves to see both views at the the same time (as displayed above).

Chances are high that our customers will use our product while doing something else, often with very little motivation, very little patience, plenty of urgent (and way more important) problems and an unhealthy dose of stress. And that’s where out product must do its job well.

What Is Stress? #

What exactly do we mean when we talk about “stress”? As H Locke noted, stress is the body’s response to a situation it cannot handle. There is a mismatch between what people can control, their own skills, and the challenge in front of them.

If the situation seems unmanageable and the goal they want to achieve moves further away, it creates an enormous sense of failing. It can be extremely frustrating and demotivating.

Stress has many levels. The key is to not let it spiral into dangerous zones. (Image credit: Alypain)

Some failures have local scope, but many have a far-reaching impact. Some people can’t choose the products they use for work, so when a tool fails repeatedly, it affects the worker, the work, the colleagues and processes within the organization. Fragility has a high cost — and so does frustration.

How Stress Influences User Interactions #

Stress disrupts attention, memory, cognition, and decision-making, making it difficult to prioritize and draw logical conclusions. In times of stress, we rely on fast, intuitive judgments, not reasoning. Typically it leads to instinctive responses based on established habits.

Poorly designed products can add to the cognitive load and lead to mistakes.

Under pressure, people often make decisions hastily, while others get entirely paralyzed. Either way is a likely path to mistakes — often irreversible ones and often without time for extensive deliberations.

Ideally, these decisions would be made way ahead of time — and then suggested when needed. But in practice, it’s not always possible. As it turns out, a good way to help people deal with stress is by providing order around how they manage it.

Single-Tasking Instead Of Multi-Tasking #

People can’t really multi-task, especially in very stressful situations or emergencies. That’s why more simpler pages might work better than one complex page.

Order means giving users a clear plan of action to complete a task. No distractions, no unnecessary navigation. We ask simple questions and prompt simple actions, one after another, one thing at a time.

Poorly designed products can add to the cognitive load and lead to mistakes.

An example of the plan is the Task List Pattern, invented by fine folks at Gov.uk. We break a task into a sequence of sub-tasks, describe them with actionable labels, assign statuses and track progress.

To support accuracy, we revise default settings, values, presets, and actions. Also, the order of actions and buttons matters, so we put high-priority things first to make them easier to find. Then we add built-in safeguards (e.g., Undo feature) to prevent irreversible errors.

Supporting In Emergencies #

The most effective help during emergencies is to help people deal with the situation in a well-defined and effective way. That means being prepared for and designing an emergency mode. E.g. to activate instant alerts on emergency contacts, distribute pre-assigned tasks and establish line of communication.

Rediplan App to prepare and act in case of emergencies.

Rediplan App by Australian Red Cross is an emergency plan companion that encourages citizens to prepare their documents and belongings with a few checklists and actions — including key contracts, meeting places and medical information, all in one place.

Just Enough Friction #

Not all stress is equally harmful though. As Krystal Higgins points out, if there is not enough friction when onboarding new users and the experience is too passive or users are hand-held even through the most basic tasks, you risk that they won’t realize the personal value they gain from the experience and, ultimately, lose interest.

We need to find the sweet spot between value realization and friction to create experiences that keep users engaged. (Image credit: Krystal Higgins)

Design And Test For Stress Cases #

Stress cases aren’t edge cases. We can’t predict the emotional state in which a user comes to our site or uses our product. A person looking for specific information on a hospital website or visiting a debt management website, for example, is most likely already stressed. Now, if the interface is overwhelming, it will only add to their cognitive load.

Stress-testing your product is key to preventing this from happening. Set up an annual day to stress test your product and refine emergency responses. To check if fallbacks work as expected and if the current UX of the product helps people manage failures and exceptional situations well enough.

Wrapping Up #

Emergencies will happen eventually — it’s just a matter of time. With good design, we can help mitigate risk and control damage, and make it hard to make irreversible mistakes. At its heart, that’s what good UX is exceptionally good at.

Key Takeaways #

People can’t multi-task, especially in very stressful situations.

Stress disrupts attention, memory, cognition, decision-making.
Also, it’s difficult to prioritize and draw logical conclusions.
Under stress, we rely on fast, intuitive judgments — not reasoning.
It leads to instinctive responses based on established habits.

Goal: Design flows that support focus and high accuracy.

Start with better default settings, values, presets, actions.
High-priority first: order of actions and buttons matters.
Break complex tasks down into a series of simple steps (10s–30s each).
Add built-in safeguards to prevent irreversible errors (Undo).

Shift users to single-tasking: ask for one thing at a time.

More simpler pages might work better than one complex page.
Suggest a step-by-step plan of action to follow along.
Consider, design and test flows for emergency responses ahead of time.
Add emergency mode for instant alerts and task assignments.

Useful Resources #

Designing The SOS Emergency System, by Ritik Jayy
Designing For Crisis, by Eric Meyer
Designing For Stressed Out Users (Series), by H Locke
Designing For Stress (Podcast), by Katie Swindler
Designing For Edge Cases and Exceptions, by yours truly
Design For Real Life, by Sara Wachter-Boettcher, Eric Meyer
Optimal Stress Levels For Onboarding, by Krystal Higgins

How To Test And Measure Content In UX

Vitaly Friedman — Wed, 05 Feb 2025 00:00:00 +0000

The goal of the content design is to reduce confusion and improve clarity. Yet often it’s difficult to pin point a problem as user feedback tends to be not specific enough. But: we can use a few simple techniques to assess how users understand and perceive content. Let’s take a look.

As designers, we need to address doubts and concerns before they even happen. Perhaps even without FAQ. Quick mock-up.

Content testing is a simple way to test clarity and understanding of the content on a page — be it a paragraph of text, a user flow, a dashboard, or anything in-between. Our goal is to understand how well users actually perceive the content that we present to them.

It’s not only about being confused or not finding the right answer on a page, but also if our content clearly and precisely articulates what we actually want to communicate.

🍌 Banana Testing #

Banana testing: replace all key actions with the word “Banana”, then ask users to suggest what it could be.

A great way to test how well your design matches user’s mental model is the Banana testing. We replace all key actions with the word “Banana”, then ask users to suggest what each action could prompt.

Not only does it tell you if key actions are understood immediately and if they are in the right place, but also if your icons are helpful, and if interactive elements such as links or buttons are perceived as such.

Content Heatmapping #

Content heatmapping, a simple technique to evaluate content and how well it performs.

One reliable technique to assess content is content heatmapping. The way we would use it is by giving participants a task, then asking them to highlight things that are clear or confusing. We could define any other dimensions or style lenses as well: e.g. phrases that bring more confidence and less confidence.

Then we map all highlights into a heatmap to identify patterns and trends. You could run it with print-outs in-person, but it could also happen in Figjam or in Miro remotely — as long as we have a highlighter feature.

Run Moderated Testing Sessions #

These little techniques above help you discover content issues, but it doesn’t tell you what is missing in the content, and what doubts, concerns and issues users have with it. For that, we need to better uncover user needs.

Too often, users would say that a page is “clear and well-organized”, but when asked specific questions, you notice that their understanding is vastly different from what we were trying to bring into spotlight.

Such insights rarely surface in unmoderated sessions — it’s much more effective to observe behavior and ask questions on spot, in-person or remote.

Test Concepts, Not Words #

Removing doubts before they happen with front-loading key details. Large view.

Before testing, we need to know what we want to learn. First, write up a plan with goals, customers, questions, script. With them, don’t tweak words alone — broader is better. In the session, avoid speak-aloud as it’s usually not how people consume content. Ask questions and wait silently.

After the task is completed, ask users to explain a product, flow and concepts to you. But: don’t ask them what they like, prefer, feel or think. And whenever possible, avoid the word “content” in testing: users often perceive it differently.

Choosing The Right Way To Test #

There are plenty of different tests that you could use:

Bananas test 🍌
Replace key actions with “bananas”, ask to explain.
Cloze test 🕳️
Remove words from your copy, ask users to fill it in.
Reaction cards 🤔
Write up emotions on 25 cards, ask users to choose.
Card sorting 🃏
Ask users to group topics into meaningful categories.
Highlighting 🖍️
Ask users to highlight helpful or confusing words.
Competitive testing 🥊
Ask users to explain competitors’ pages.

When choosing the right way to test, consider the following guidelines:

Do users understand? 💭
Interviews, highlighting, Cloze test
Do we match the mental model?
Banana testing, Cloze test
What word works best?
Card sorting, A/B testing, tree testing
Why doesn’t it work?
Interviews, highlighting, walkthroughs
Do we know user needs?
Competitive testing, process mapping

Wrapping Up #

In many tasks, there is rarely anything more impactful than the careful selection of words on a page. However, it’s not only the words alone that are being used, but the voice and tone that you choose to communicate to customers.

Use the techniques above to test and measure how well people perceive content, but also check how they perceive the end-to-end experience on the site.

Quite often, right words used wrongly on a key page can convey a wrong message or provide a suboptimal experience. Even although the rest of the product might perform remarkably well, if a user is blocked on a critical page, they will be gone before you even blink.

Useful Resources #

Practical Guide To Content Testing, by Intuit,
How To Test Content With Users, by Kate Moran
Five Fun Ways To Test Words, by John Saito
A Simple Technique For Evaluating Content, by Pete Gale

How To Design Complex Data Tables (+ Figma Kits)

Vitaly Friedman — Mon, 03 Feb 2025 00:00:00 +0000

Complex data tables are difficult to get right. They always come along with filters, sorting, customization options, batch actions, cell states, pagination, and a huge amount of data. Their purpose is to help people find insights, by comparing data points across rows and columns.

Yet navigating a table is often painfully slow and frustrating, especially on mobile. Let’s explore practical techniques and useful Figma toolkits to help users find and compare the right data faster, without relying on endless horizontal scroll.

Architecting a complex data table is quite an adventure. Wonderful work by Goldman Sachs team.

Setting Up The Table Architecture #

✅ First, design a feature tree. #

Before we dive into all the fine details, we need to first understand what features, states, and accessories we actually need. Slava Shestopalov has put together a tree of table features — a practical overview of what can go into complex tables, along with all features, states, and accessories that might need to be considered in the design process.

A comprehensive tree of table features. Neatly put together by Slava Shestopalov.

✅ Decide on the functionality you need. #

We start by observing, collecting, and prioritizing user needs. Based on them, we define a full set of complex functionality — such as drag-n-drop, resizing, reshuffling, or multi-sorting. These features will require separate accessibility considerations as all draggable controls must be keyboard-accessible due to WCAG 2.2 AA requirements.

The different types of cells, from the (incredible!) Goldman Sachs Design System.

✅ Define your table cells. #

Then, we define the different types of table cells. Some of them will be available to everyone, others will have restrictions applied to them. So we discuss permissions and logic, such as read-only, comment-only, or editable.

We explore filtering, sorting, and customization features — most notably, showing and hiding columns. We discuss sticky headers and columns. And for each of them, we set default values, presets, and templates.

The different types of data cells in action — from read-only to editable.

✅ Next, interaction design and accessibility. #

Eventually, we move to the fine little details of the data table design. Things like truncation, wrapping, stretching, and resizing rules. We look at interaction design with validation rules and error messages. Some tables might require very long technical titles or localization, so stress test your design with very long and very short titles — this might also require compact, comfortable, and condensed modes.

Data table designs with a dedicated “Actions” button might perform better than hover actions.

Once we are there, consider accessibility — moving within the table with keyboard alone, but also supporting keyboard for drag'n'drop and navigation within the table. And: Whenever possible, you might want to try to avoid row hover actions. They often cause errors and rage clicks. Instead, use a standalone button (“Actions”) or few buttons on each row instead.

✅ Regroup data, add a filter. #

For row actions, you might be better off with a bottom sheet (edit, delete, move). A helpful way to make the content more accessible is by re-grouping data from columns across multiple rows (pivoting).

For nested filters, you might want to consider an overlay with horizontal stacking instead of a tree.

You could also combine columns within vertical accordions (stacked columns) and add a sticky filter in each column to help users navigate faster. Finally, if you do use pagination, show it above and below the data list.

✅ Think about data alone, not structure. #

An exercise I always dive into is to think about the data alone, rather than its tabular structure. We explore how to aggregate data and perhaps span it across fewer columns. We show only what users really need, then show more on tap.

Data table designs with a context menu often has discoverability issues. You will need an indicator or use a select dropdown instead.

While doing so, try to leave out unnecessary data and details and eliminate repetition. For example, we could abbreviate dates, long labels, units of measure, and currency. Replace statuses and permissions with icons and badges.

Adjusting For Mobile #

We often assume that customers expect data tables to appear exactly the same on mobile and on desktop. That’s not necessarily true. What they do expect is that features they heavily rely on for their work exist in all environments — but these features don’t have to work or look exactly the same.

Row-column data tables are terribly inefficient on mobile — you might want to consider cards instead. Example: Goldman Sachs Design System.

In general, row-column data tables are terribly inefficient on mobile — that’s where users often struggle, making mistakes and scrolling back and forth to make sure that they are looking at the right piece of data.

We often assume that users need to rely on the entire data table to make decisions or find insights. But the nature of some tables might require a very different solution. For some tables, users might not need the entire table — they need to navigate between a few filtered rows or columns at a time.

Support navigation within the cells and rows. By Joe Winter.

In that case, you might need to support navigation within the table by helping users explore specificic data points faster. A common way to achieve that is via tabs or dropdown together with cards, as displayed in a case study by Joe Winter.

✅ Allow users to show and hide columns. #

It’s worth noting that users rarely navigate through all columns in the table. So let them show and hide columns, for example with a “Columns” button. There, let them also re-arrange, lock, and reset columns. You could use tabs above the table to change the view, or use tabs within the table to jump between columns.

Clever: Use tabs within the data table to navigate its columns. By Netty Konovalova

Data Tables Figma Kits #

Designing data tables in Figma from scratch is remarkably tedious and time-consuming. You can get off the ground with a few helpful kits, kindly shared and released by the community:

How To Design Data Tables In Figma (+ Figma Kit), by Jordan Hughes
Goldman Sachs Data Grids UI Kit, by Goldman Sachs
Designing Tables In Figma With Real Data, by Christine Vallaure
Figma CSV Table Generator Plugin
Table Creator Figma Plugin, by Gavin McFarland
Table Builder Figma Plugin, by Fabian Nart and Natasha Dudler
Reusable Dynamic Table Components, by Natalia Brochero
Copy-Paste Data From CSV/Excel Figma Plugin
Interactive Data Table Figma Kit, by Alvish Baldha
Table Design System Figma Kit, by Valeriya Desire

Useful Resources #

Designing Data Tables #

Complex Data Table Features Tree, by Slava Shestopalov
Data Grids and Tables Figma Kits, by Goldman Sachs
Carbon Design System: Data Table
NordHealth Design System: Complex Tables
Designing Tables For Reusability, by Ada Rafalowicz and Havana Nguyen
Complex Tables Design Patterns, by Andrew Coyle
How Screen Readers Navigate Data Tables, by Léonie Watson
Enterprise UX: Data Tables, by Stéphanie Walter

Designing Data Tables On Mobile #

Complex Data Tables On Mobile, by GE HealthCare
Designing A Complex Table For Mobile, by Joe Winter
AT&T Enterprise Table On Mobile, by Douglas Kelshaw
Shopify Data Tables On Mobile, by Tetsuro Takara
Designing Mobile Tables, by Steven Hoober

A huge thank you to all the contributors, authors, and designers who spend time and effort and energy into making these resources available for everyone to use! 👏🏼👏🏽👏🏾

Badges vs. Pills vs. Chips vs. Tags

Vitaly Friedman — Fri, 31 Jan 2025 00:00:00 +0000

Sometimes design conversations take slightly more time and effort than needed. One of the frequent conversations is circling around badges, pills, chips and tags.

How are they different? What purpose do they serve? Which ones do we need in our design system? And how to choose the right one? Well, let’s find out.

A collection of badges and tags from Base design system, by Uber.

Badges vs. Tags #

We distinguish between static and interactive UI components. Some of them communicate and visualize data, while others prompt actions — from navigation and selection to input and filtering. While they often appear very similar, to avoid confusion, we need them to be quite distinct, and easy to tell apart.

Badges Are Static Labels #

Badges are always static components. They relay status and updates (e.g. draft, new, pending, -7%↘), they highlight changes and are subtle indicators for main content. As such, they aren’t used for navigation.

The different shades of badges: categorized by status, propagation, priority, sentiment and other attributes as part of the ongoing effort for Emplifi Design System. By Lukas Vilkus.

Tags Can Be Static or Interactive #

Tags, on the other hand, can be static or interactive. Static tags show topics with keywords and labels (e.g. AI, Accessibility). Interactive tags are often used for links, filters, selection and actions.

They come in many different flavors:

Display-only tags ← visually represent categories (keywords, labels, details).
Data tags ← numerical data, reading time, file size (e.g. PDF 262 KB).
Filter tags ← show active filters, with an option to remove and clear.
Selection tags ← filter content and input information (also called chips or pills).

Chips and pills are merely visual style conventions for interactive tags. Their naming comes from their appearance. As it happens, on rare occasions they are static, and that’s where the confusion with badges and static tags comes from.

Design Systems Only Need Badges and Tags #

While there is quite a bit of confusion about the difference between all these variants, design systems typically distinguish between 2 of them — static indicators (usually badges, pills, data tags) and interactive links or buttons (usually action/selection tags, filter tags, chips).

For feedback indicators, notification counts and status updates, we use badges. For interactive indicators and filters that can be edited or removed, we use tags — which are also sometimes called chips. Of course often they function as radio buttons or checkboxes. And most of the time, that’s all you really need.

Badges are static, while tags can be static or interactive. Visualized by Adham Dannaway.

Design Distinct Styles For Both Components #

Confusion comes when static and interactive components share the same or similar visual style. Don’t design non-interactive components to appear like buttons. And don’t design interactive components to appear similar to static labels.

Also, prefer adjectives or nouns for non-interactive tags. Use 48×48px as a minimum touch target size on mobile. And ideally use at least 8px spacing between interactive elements to prevent mistaps.

Avoid Generic Names #

When naming these components, try to be as explicit as possible to avoid confusion down the line. “Filter tags” are more obvious than “filters” or generic “tags”.

Also, “Status badges” are way more obvious than “badges” or “pills”. It should work for everyone — designers, engineers and end users — as long as static labels don’t look like interactive buttons, and the other way around.

Badges and Tags in Design Systems #

Useful Resources #

Designing A System For Badges, by Lukas Vilkus,
Design System Dilemmas: Badges, by Dean Harrison
Guide To Chips and Badges, by Uxcel

Combobox vs. Multiselect vs. Listbox

Vitaly Friedman — Wed, 15 Jan 2025 00:00:00 +0000

Let's see how they differ, what purpose they serve and how to choose the right one — avoiding misunderstandings and wrong expectations along the way.

And the confusion begins: Listbox, Combobox, Multiselect, Dual Listbox.

Not All List Patterns Are The Same #

All the UI components highlighted above have exactly one thing in common — they support user's interactions with lists. However, they do so slightly differently.

Let's take a look at each, one by one:

Dropdown → list is hidden until it's triggered.
Combobox → type to filter + select 1 option.
Multiselect → type to filter + select many options.
Listbox → all list options visible by default (+ scroll).
Dual listbox → move items between 2 listboxes.

Watson design system with grouping inside of its combobox pattern.

Never Hide Frequently Used Options #

MongoDB design system with nested filters and chips.

How To Choose Which? #

A matrix of options, broken down by single- or multi-selection and static or scrollable view. By Anna Kaley, from NN/g.

Dual listbox in action: it can be very helpful when assigning tasks or permissions. That's why it's 'Transfer List'. Example from Mantine.

In fact, dual listbox is often faster, more accurate and more accessible than drag-and-drop.

Usability Considerations #

Keyboard navigation is often in use with any kind of lists. Example: Watson.

Beyond that:

For lists with 7+ options, consider adding "Select All" and "Clear All" functionalities to streamline user interaction.
For lengthy lists with a combobox, expose all options to users on click / tap as otherwise they might never be seen,
Most important, don't display non-interactive elements as buttons to avoid confusion — and don't display interactive elements as static labels.

It should work for everyone — designers, engineers and end users — as long as static labels don't look like interactive buttons, and radio buttons don't act like checkboxes.

Useful Resources #

Autocomplete: UX Guidelines, by Vitaly Friedman
Combobox, by eBay 👍
Combobox, by Elastic
Combobox, by Elisa
Combobox, by MongoDB 👍
Combobox, by Visa 👍
Combobox, by Watson (Docplanner)
Combobox, by Wikimedia
Combobox, by Zendesk
Multiselect (MongoDB Combobox Design Docs), by MongoDB 👍
Multiselect Lookup, by Wikimedia
Multi-select Combo Box, by Vaadin
Multiselect, by Visa
Transfer (Listbox example), by Ant Design
Listbox, by Hopper
List Box, by Vaadin
Listbox, by Visa
Dual List Selector, by Red Hat (PatternFly)
Dual Listbox, by Salesforce (Lightning Design System)
Transfer List, by Mantine
Dual Listbox, by Dashlite
Badges vs. Pills vs. Chips vs. Tags, by Vitaly Friedman
Listboxes vs. Dropdown Lists, by Anna Kaley (NN/g)

Avoid Newsletter Pop-Ups, And What To Do Instead

Vitaly Friedman — Tue, 18 Jun 2024 00:00:00 +0000

Newsletter pop-ups are everywhere. You’ve just landed on a website, yet here it is, a shiny newsletter pop-up, asking for your email address for reminders, updates or an exclusive 15% coupon code. People hate it, businesses love it. But does it work? As it turns out, it’s complicated.

Often newsletter pop-ups are highly ineffective for businesses and frustrating to customers. By Michal Malewicz.

The Many Shades Of Emails #

According to email statistics, on average people have 1.7–1.9 different email accounts. Some people have even more than 3 email accounts, ranging from private and work accounts to emails for newsletters and shopping.

Apparently, best time to send email is on Tuesdays. Let’s see: I’'ve decided to break the rule for this one. Large view.

They all differ significantly in opening rates and attention spans. And especially when it comes to private accounts, users tend to be more cautious and protective to avoid spam, scam and annoying promotional emails.

That’s why for businesses, it’s remarkably difficult to get a first-class email address from customers unless they’ve developed at least some trust and confidence towards that brand.

Disposable and Temporary Emails #

Of course the reason why businesses show a newsletter pop-up in the first place is to get leads. But what they are ultimately after isn’t just random email accounts, but rather getting first-class leads — email accounts that have high delivery rates, high opening rates, low bounce rates and high conversion.

One of the many: TempMail is a popular disposable email service.

Most of the time, that’s the exact opposite of what newsletter pop-ups bring. Many people are hesistant to give away a “good” email address, so they leave an email that they hardly ever use. And some audiences always use temporary or disposable email services like Temp-Mail.org — just to get a coupon code and avoid all the marketing emails.

The outcome is not very surprising: many email lists are overflown with fake, disposable, unusable leads. Even worse, at a certain scale, they are expensive to keep, and due to high bounce crates, can decrease email deliverability.

Ask For Email When It Matters To Users #

How do we solve it? When it comes to newsletters, our task is to find the right timing when customers care most about the quality and accuracy of their email address. It never happens on the homepage, and rarely on category pages. It never happens on search results pages or support pages either.

For users to care, they must feel at least somewhat invested in whatever the company is offering. And, most importantly, they should recognize the value that leaving a “good” email address would bring to them.

An example of integrated newsletter box on a product page. Large view.

Typically it happens on 5 types of pages:

📣 Promotion pages
“We’ll send a confirmation message to that email”.

🍎 Product pages
“Leave email and check out with coupon applied”.

🎟️ Sales page
“Get notified about sales and re-stocked items”.

💳 Final checkout step
“Review your address for confirmation email.”

🎉 Purchase confirmation page
“Didn’t get a confirmation? Edit your email.”

Wrapping Up #

Sprinkle newsletter boxes across these pages and measure impact. Track not just the list growth, but bounce rates, opening rates and conversion. Your goal is to be at least close to the email opening rate of 28–35%, which is a standard goal across industries.

Don’t forget to clean up temporary emails from your list — some businesses aren’t aware how expensive non-existent leads can be. You might be surprised how effective a simple change like that can be.

It’s great for customers and for businesses — without all the frustrations newsletter sign-up pop-ups bring along.

2-Page Login Pattern, And How To Fix It

Vitaly Friedman — Tue, 11 Jun 2024 00:00:00 +0000

Why do we see login forms split into multiple screens everywhere? Instead of typing email and password, we have to type email, move to the next page, and then type password there. This seems to be inefficient, to say the least.

Let’s see why login forms are split across screens, what problem it solves and how to design a better experience for better authentication UX (video).

If there is one thing we’ve learned over the years in UX, it’s that designing for people is hard. This applies to login forms as well. People are remarkably forgetful. They often forget what email they signed up with, or what service the signed in with last time (Google, Twitter, Apple etc.)

One of the many: plenty of login options to choose from, and people usually don't remember their last choice.

One idea is to remind customers what they've signed in with last time, and perhaps make it a default option — however, it reveals directly what user’s account was, which might be a privacy or security issue:

Highlighting what a user has signed in with last time. An example from Spectrum (no longer available). Large view.

What if instead of showing all options to all customers all the time, we ask for email first, and then look up what service they used las time, and redirect customers to the right place automatically? Well, that’s exactly the idea behind 2-page logins.

Meet 2-Page-Logins #

You might have seen them already. If a few years ago most login forms asked for email and password on one page, these days it’s more common to ask only for email first. When the user chooses to continue, the form will ask for password, in a separate step. Brad explores some problems of this pattern.

2-page-login at Shopify: email first, the rest later. Image source: Brad Frost

A common reason for splitting login form across pages is Single Sign-On (SSO) authentication. Large companies typically use SSO for corporate sign-ins of their employees. With it, employees only log in once every day and only use one set of credentials, which improves enterprise security.

The UX Intricacies of Single Sign-On (SSO) #

SSO also helps with regulatory compliance, and it’s much easier to provision users with appropriate permissions, and revoke them later at once. So if an employee leaves, all their accounts and data can be deleted at once.

To support both business customers and private customers, companies use 2-step-login. Users need to type in their email first, then the validator checks what provider the email is associated with, and redirects users there.

Users rarely love this experience. Sometimes they have multiple accounts (private and business) with one service. Also, 2-step-logins often break autofill and password managers. And for most users, login/pass is way faster than 2-step-login.

Of course typically there are dedicated corporate login pages for employees to sign in, but they often head directly to Gmail, Figma etc. instead, and try to sign in there. However, they won’t be able to log in as they must sign in through SSO.

Bottom line: the pattern works well for SSO users, but for non-SSO users it results in a frustrating UX.

Alternative: Conditional Reveal of SSO #

There is a way to work around these challenges (see the image below). We could use a single page look-up with email and password input fields as a default. Once a user has typed in their email, we detect if the SSO authentication is enabled.

An alternative: show email and password by default at first. Large view (+ video preview).

If Single Sign-On (SSO) is enabled for that email, we show a Single Sign-On option and default to it. We could also make the the password field optional or disabled.

An alternative: show email and password by default at first. Large view (+ video preview).

If SSO isn’t enabled for that email, we proceed with the regular email/password login. Not much hassle, but saves trouble both for private and business accounts.

Key Takeaways #

🤔 People often forget what email they signed up with.
🤔 They also forget auth service they signed in with.
🤔 Companies use Single Sign-On (SSO) for corporate sign-in.
🤔 Individual accounts still need email and password for login.
✅ 2-step login: ask for email, then redirect to the right service.

✅ 2-step-login replaces “social” sign-in for repeat users.
✅ It directs users, rather than giving them roadblocks.
🤔 Users still keep forgetting the email they signed in with.
🤔 Sometimes users have multiple accounts with 1 service.
🚫 2-step-logins often break autofill and password managers.
🚫 For most users, login/pass is way faster than 2-step-login.

✅ Better: start with one single page with login and password.
✅ As users type their email, detect if SSO is enabled for them.
✅ If it is, reveal an SSO-login option, and set a default to it.
✅ Otherwise proceed with the regular password login.
✅ If users must use SSO, disable password field — don’t hide it.

Wrapping Up #

Personally I haven’t tested the approach but it might be a good alternative to 2-page logins — both for SSO and non-SSO users. Keep in mind though that SSO authentication might or might not require a password, as sometimes login happens via Yubikey or Touch-ID or third parties (e.g. OAuth).

Also, eventually users will be locked out: it’s just a matter of time. So do use magic links for password recovery or access recovery, but don’t mandate it as a regular login option. Switching between applications is slow and causes mistakes. Instead, nudge users to enable 2FA: it’s both usable and secure.

And most importantly: test your login flow with the tools that your customers rely on. You might be surprised how broken their experience is if they rely on password managers or security tools to log in. Good luck, everyone!

Useful Resources #

When To Use A Two-Page Login, by Josh Wayne
Don’t Get Clever With Login Forms, by Brad Frost
Why Are Email And Password On Two Different Pages?, by Kelley R.
Six Simple Steps To Better Authentication UX, by yours truly

Hidden vs. Disabled In UX

Vitaly Friedman — Wed, 29 May 2024 00:00:00 +0000

Both hiding and disabling features can be utterly confusing to users. And for both, we need very, very good reasons. Let’s take a closer look at what we need to consider when it comes to hiding and disabling — and possible alternatives that help enhance the UX.

Show What’s Needed, Declutter The Rest #

You’ve probably been there before: Should you hide or disable a feature? When we hide a feature, we risk hurting discoverability. When we disable it without any explanation, we risk that users get frustrated. So, what’s the best way to design for those instances when some options might be irrelevant or unavailable to users?

To hide or not to hide? There are very good reasons for hiding or disabling features and options for a user. But we need to be careful when doing so to not harm the UX.

As a rule of thumb, disable if you want the user to know a feature exists but is unavailable. Hide if the value shown is currently irrelevant and can’t be used. But never hide buttons or key filters by default as users expect them to persist.

Unlike hidden features, disabled features can help users learn the UI, e.g., to understand the benefits of an upgrade. So, instead of removing unavailable options or buttons, consider disabling them and allowing the user to “Hide all unavailable options.” Be sure to explain why a feature is disabled and also how to re-enable it.

Another thing to watch out for: When we allow users to switch between showing and hiding a feature, we also need to ensure the switch doesn’t cause any layout shifts.

Disabled state in Carbon Design System, with variations for ready-only, default disabled and hidden.

For both hiding and disabling, we need very thorough considerations of available alternatives, e.g., enabled buttons, read-only state, better empty states, hide/reveal accordions, error messages, and customization. We need to show what’s needed and de-clutter the rest.

Whenever possible, I try to keep buttons and features in their default state — enabled, accessible, and legible. When a user interacts with that feature, we can explain why they can’t use it, how to enable it, and how to keep it enabled. Possible exceptions are confirmation codes and loading/processing states.

Hiding vs. Disabling Roadmap #

As Sam Salomon suggests, if you’re unsure whether hiding or disabling is the best option for your use case, ask yourself the following question: “Will a given user ever be able to interact with this element?” Depending on your answer, follow the steps below.

✅ Yes

→ Disable it (as disabled buttons or read-only state).
↳ For temporary restrictions or filter incompatibility.
↳ When a value or status is relevant but not editable.
↳ When an action isn’t available yet (e.g., “Export in progress…”).

🚫 No

→ Hide it (remove from a toolbar, collapse in accordion).
↳ E.g., due to permissions, access controls, safety, and security.
↳ For inaccessible features: e.g., admin buttons, overrides.
↳ Hide such controls by default and reveal them once a condition is met.

Key Takeaways #

Hiding important features hurts their discoverability.
Disabling features is frustrating without an explanation.
But some options might be irrelevant/unavailable to users.
Users might expect a feature to exist but won’t find it.
We need to show what’s needed and de-clutter the rest.
Avoid disruptive layout shifts as you show and hide features.
Don’t remove unavailable options or buttons automatically.
Instead, disable them and allow it to “Hide all unavailable options.”
Allow users to hide sections with a lot of disabled functionality.
Explain why a feature is disabled and how to re-enable it.

Hidden vs. Disabled In Design Systems #

The design systems below provide useful real-world examples of how products design their hidden and disabled states.

Carbon (disabled state)
Carbon (read-only state)
Unity
Vaadin
SAP
Motif
Emplifi

Useful Resources #

Disabled Buttons And What To Do Instead, by Adam Silver
Hidden vs. Disabled States, by Maria Panagiotidi
Making Disabled Buttons Inclusive, by Sandrina Pereira
Hide or Disable, by Sam Solomon
The Disabled State In UI Design (Sketchnotes), by Krisztina Szerovay
Usability Pitfalls of Disabled Buttons, by yours truly Vitaly Friedman
Alternative Design Patterns For Disabled Features, by Katie Jacquez
Designing Filters UX That Works, by yours truly Vitaly Friedman
UI Traps: Disabled Buttons and Inputs, by James Carleton

Why Designers Aren’t Understood

Vitaly Friedman — Tue, 28 May 2024 00:00:00 +0000

As designers, especially in large enterprises, we often might feel misunderstood and underappreciated. It might feel like every single day you have to fight for your users, explain yourself and defend your work. It’s unfair, exhausting, painful and frustrating.

Let’s explore how to present design work, explain design decisions and get stakeholders on your side — and speak the language that other departments understand.

Business language and design language are often misaligned. That’s why designers are often not understood. Large view.

As designers, we might feel slightly frustrated by the language that often dominates business meetings. As Jason Fried has noted, corporate language is filled with metaphors of fighting. Companies “conquer” the market, they “capture” mindshare, they “target” customers, they “destroy” the competition, they want to attract more “eye-balls, get users “hooked, and increase “life-time value.

Designers, on the other hand, don’t speak in such metaphors. We speak of how to “reduce” friction, “improve” consistency, “empower” users, “enable and help” users, “meet” their expectations, “bridge the gap”, “develop empathy”, understand “user needs, design an “inclusive” experience.

In many ways, these words are the direct opposite of the metaphors commonly used in corporate environments and business meetings. So no wonder that our beliefs and principles might feel misunderstood and underappreciated. A way to solve is to be deliberate when choosing words you use in the big meeting. In fact, it’s all about speaking the right language.

Speaking The Right Language #

As designers, we often use design-specific terms, such as consistency, friction and empathy. Yet to many managers, these attributes don’t map to any business objectives at all, often leaving them utterly confused about the actual real-life impact of our UX work.

One way out that changed everything for me is to leave UX vocabulary at the door when entering a business meeting. Instead, I try to explain design work through the lens of the business, often rehearsing and testing the script ahead of time.

When presenting design work in a big meeting, I try to be very deliberate and strategic in the choice of the words I’m using. I won’t be speaking about attracting “eye-balls” or getting users “hooked”. It’s just not me. But I won’t be speaking about reducing “friction” or improving “consistency” either.

Instead, I tell a story.

A story that visualizes how our work helps the business. How design team has translated business goals into specific design initiatives. How UX can reduce costs. Increase revenue. Grow business. Open new opportunities. New markets. Increase efficiency. Extend reach. Mitigate risk. Amplify word of mouth.

And how we’ll measure all that huge impact of our work.

Typically, it’s broken down into eight sections:

🎯 Goals ← Business targets, KRs we aim to achieve.
💥 Translation ← Design initiatives, iterations, tests.
🕵️ Evidence ← Data from UX research, pain points.
🧠 Ideas ← Prioritized by an impact/effort-matrix.
🕹 Design work ← Flows, features, user journeys.
📈 Design KPIs ← How we’ll measure/report success.
🐑 Shepherding ← Risk management, governance.
🔮 Future ← What we believe are good next steps.

Key Takeaways #

🤔 Businesses rarely understand the impact of UX.
🤔 UX language is overloaded with ambiguous terms.
🤔 Business can’t support confusing initiatives.
✅ Leave UX language and UX jargon at the door.
✅ Explain UX work through the lens of business goals.

🚫 Avoid “consistency”, “empathy”, “simplicity”.
🚫 Avoid “cognitive load”, “universal design”.
🚫 Avoid “lean UX”, “agile”, “archetypes”, “JTBD”.
🚫 Avoid “stakeholder management”, “UX validation”.
🚫 Avoid abbreviations: HMW, IxD, PDP, PLP, WCAG.

✅ Explain how you’ll measure success of your work.
✅ Speak of business value, loyalty, abandonment.
✅ Show risk management, compliance, governance.
✅ Refer to cost reduction, efficiency, growth.
✅ Present accessibility as industry-wide best practice.

Next time you walk in a meeting, pay attention to your words. Translate UX terms in a language that other departments understand. It might not take long until you’ll see support coming from everywhere — just because everyone can now clearly see how your work helps them do their work better.

Useful Resources #

Business Thinking For Designers, by Ryan Rumsey
Business For Designers (d.mba), by Alen Faljic
Corporate Language Metaphors, by Jason Fried
Five Things That Business Cares About, by Jared Spool
Direct Impact Of Design Work, by 👨🏻‍💻 Andy Budd
It’s Time To End The Tyranny Of UX Terminology, by Joe Natoli
How To Use Storytelling In UX Research, by Allison Grayce Marshall
How To Defend Your Design Decisions, by Vitaly Friedman

You can find more details on UX and usability in Smart Interface Design Patterns 🍣 — with a live UX training that’s coming up in 2024. Use the code PUMPKIN to save 15% today. Free preview.

Sustainable Design Patterns For UX Designers

Vitaly Friedman — Mon, 27 May 2024 00:00:00 +0000

Digital sustainability is often seen as a technical concern for engineers. We speak about optimization of assets, and web performance, and server efficiency. In fact, we rarely explore sustainability from the perspective of design and UX. But what if we did?

Let’s explore a few practical techniques to reduce waste, focus on what matters and declutter what doesn’t — that you can apply to your work right away.

Design For Sustainability Checklist, a helpful reminder, put together by the IBM team. Large view.

The Actual Cost Of Digital #

Digital is extraordinarily material- and waste-intense. This doesn’t come through usage, but rather through mining and manufacturing of materials that go into devices.

On average, a modern smartphone has 60–70 materials. These materials have to be mined and delivered and processed and pieced together. In fact, for a new phone to be produced, manufacturing requires 60kg of CO2, 300kg of mined toxic waste and approx. 14.000L of water.

For comparison, a new laptop costs around 300kg of CO2, 1.200kg of waste and 190.000L of water. Summing up the cost of digital together, we produce 100 billions tons of waste per year. This makes for half a Mount Everest of toxic waste, yearly.

We put our hopes in efficiency over time, yet in the past efficiency has never reduced consumption, but rather increased it. In fact, despite efficiency, data storage grows 28% annually, at the peak today, yet 90% of it is never used.

Sustainable Design Patterns #

How do we address it with our work? Well, most of our environmental impact happens on our user’s devices. So we can help our users by reducing waste and focusing on what matters:

✅ Always choose the lightest mode of communication.
✅ Encourage the reuse of existing templates and presets.
✅ Auto-delete after 365 days what hasn’t been used once.
✅ Discourage users from PDF exports in favor of URLs.
✅ Always provide audio-only/transcript for videos.

✅ Be intentional with default settings for your users.
✅ Highlight key insights to create understanding faster.
✅ Skip unnecessary pages: drive users to results faster.
✅ Establish an archiving and deletion policy.
✅ Show filters/presets in autocomplete, not just keywords.

✅ Nudge users to delete old files for 10% off that month.
✅ Encourage and reward users for trying out dark mode.
✅ Aim to reduce session duration instead of increasing it.
✅ Question font weights, stock photos, parallax, 4K-videos.
✅ Question collected data, if it’s used and when it’s deleted.

Sustainable UX Toolkits #

As designers, we often are left wondering how to integrate sustainable design practices into our design work. The repository on Sustainable UX Toolkits and Resources provides useful pointers on how to make sustainability default throughout the entire product design process — from strategy and discovery to UI design and testing.

Repository of sustainable UX resources — from strategy to implementation. Kindly put together by the SUX network.

It includes toolkits, Figma templates, books, case studies, articles and events on sustainable UX — a wonderful growing repository to make big and small gains to align our work with sustainable design practices. One for the bookmarks!

Digital Is Physical and Material #

As Gerry McGovern says, digital is intensely physical and material. It has a severe cost of cooling, mining, water use and toxic waste. So optimize relentlessly. Help people get things done faster.

Individual actions drive changes at scale, but they need a momentum. And often that momentum comes through small changes: new default settings, reduced time on task, or showing key insights, rather than all data. That’s also just good usability that can have tangible impact for users and businesses.

Most importantly: whenever possible, hold on to your devices as long as possible, and encourage your customers to do the same. And if a meeting helps you reduce wasteful work done by 20 people, it’s the time worth taking.

Useful Resources #

Sustainable Web Design Patterns
Sustainable Product Design (+ Template), by Artiom Dashinsky
Getting Started With Sustainability, by Michelle Barker
Sustainable UX, by Thorsten Jonas, SUX
Sustainable Design Toolkits And Frameworks, by Cosima Mielke, Geoff Graham
Design For Sustainability Checklist, by IBM
Sustainable Toolkits For UX Designers, by yours truly

You can find more details on UX and usability in Smart Interface Design Patterns 🍣 — with a live UX training that’s coming up in 2024. Use the code PUMPKIN to save 15% today. Free preview.

A Practical Guide To Design For Children

Vitaly Friedman — Fri, 19 Jan 2024 00:00:00 +0000

Children start interacting with the web when they are 3–5 years old. How do we design for children? What do we need to keep in mind while doing so? And how do we meet the expectations of the most demanding users you can possibly find: parents? Well, let’s find out.

Embrace Playing, Encourage Small Wins #

Designing for children is difficult. Children tend to lose focus and motivation. They quit when they get bored, and they move on if they can’t get anywhere quickly enough. They need steady achievements. So as designers, we need to appreciate, reward, and encourage small wins to develop habits and support learning — with progress tracking and gamification.

Vibrant, colorful and playful: Fiete Math, a well-designed game for children.

As Deb Gelman, author of Design for Kids discovered, children communicate volumes by how they play, what they choose to play with, how long they choose to play with it, and when they decide to play with something else. Yet they don’t get as disappointed when something isn’t working. They just choose to browse or play something else.

Most importantly, we can’t design for children without testing. Even better: bring children to co-design their digital experiences, and bring parents to co-design reliable guardrails. With a fun, smart, and safe product, parents will spread the word about you faster than you ever could.

Always Focus On A Two-Year Age Range #

As designers, we should always keep in mind that “children” represent a very diverse range of behavior and abilities. There are vast differences between age groups (3–5, 6–8, and 9–12) — both in terms of how users navigate, but also how we communicate to them.

In general, when designing for children focus on a two-year age range, max. These days, children start interacting with the web at the age of 3–5. And the very first interactions they learn are swipe, scroll, video controls, and “Home”.

Getting Parents On Board #

Whenever you are designing for children, you always design for parents as well. In fact, parents are the most demanding users you can find. They have absolutely no mercy in reviews, requests, complaints and ratings on the stores.

Something that parents need to rely on: Grace, a parental control app.

That’s not surprising. Parents need safety guarantees, regulations and certifications — a sort of reassurance that you treat their safety and privacy seriously, especially when it comes to third-party integrations or advertising. In fact, they are often willing to pay for apps more just to avoid advertising.

Parents often value reviews from teachers, educators, doctors, and other parents like themselves. And they need to have parental controls to set specific time limits, rules, access and permissions.

As Rodrigo Seoane has pointed out in an email, a major concern to keep in mind is “how the majority of initiatives for kids rely on and create dependencies on extrinsic motivations. The reward model keep their attention in the short term, but as a core gamified mechanic it is problematic in the long run, reducing their cognitive capacity and creating a barrier to develop any intrinsic motivation.” So whenever possible, design to increase intrinsic motivation.

Design Guidelines For Children-Friendly Design #

Design large text (18–19px) with large tap targets (min 75×75px).
Use typefaces that approximate how children learn to write.
Translate text into attractive visuals, icons, sounds, characters.
Avoid bottom buttons as kids tap on them by mistake all the time.
Children expect feedback on every single action they perform.
Don’t patronize: show age-appropriate content for the age range you’re designing for.
Be transparent: children can’t distinguish ads or promotions from real content.
You’re always designing for both children and parents.
Parents are the most demanding users you can find. They have no mercy in reviews and ratings.
Design parental controls for time limits, rules, access.
Instead of extrinsic rewards, design to increase intrinsic motivation.

Useful Resources #

Things to Consider When Designing for Children, by Jasmine Bilham
Design Considerations for Little Fingers, by Andrew Smyk
How to Create a Product Children Will Love, by Mariia Kasym
Designing For Children (7-part series), by Catalina Naranjo-Bock, Jonathan Evans, Paul Osborne
Children’s UX: Usability Issues in Designing for Young People, by Katie Sherwin, Jakob Nielsen
Usability Testing With Children, by Alita Joyce
Designing Web Interfaces For Kids, by Trine Falbe
Designing Apps For Young Kids (Medium paywall), by Rubens Cantuni
Designing For Children (PDF guidelines), by Gerry Gaffney, James Hunter
The Definitive Guide to Building Apps for Kids, by Tanya Junell
Useful Resources When Designing For Children

Digital Toolkits For Children #

UX Research Toolkit For Playtesting With Kids (UX Methods)
Designing With Children (Workshops and Case Studies)
Co-Design With Kids Toolkit
Playful by Design Toolkit
DeCID Handbook For Displaced Children
Designing For Children’s Rights Guide

Books and eBooks #

Designing For Motivation (Pocket Guide), by Anamaria Dorgo, LxD Lab
Designing Digital Products For Kids, by Rubens Cantuni
Design For Kids, by Deb Gelman
Designing Spaces For Children, by Nathalie Dziobek-Bepler

Design Patterns For... Almost Anything!

Vitaly Friedman — Wed, 15 Nov 2023 00:00:00 +0000

So what if you need a bit of inspiration for accordions, or footers, or dashboards, or maps, or perhaps hover states? In this single post, you’ll find all of them — a curated list of design showcases for various design components and themes — from UI components to patterns, in-house branding and presentation decks.

Happy browsing, everyone! 🎉🥳

Design Patterns #

All interface components, by Iain Bean
AI design patterns, (currently down)
Book covers, by Ben Pieratt
Covers/CV
Dark Mode, by Cai Cardenas
Dashboards, by Benjamin Bach
Data visualization, by Yan Holtz
Deceptive patterns to avoid, by Harry Brignull
Design concepts: by Maggie Appleton
Design systems, by Josh Cusick
Email, by Andrew King
Ethical design, by Jon Yablonski
Fonts, by Florian Hardwig
Footers, by Benten Woodring, Matt Cram
Games
Hover states, by Mike Guppy, Daniel Powell
In-house branding
Little details, by Floris Dekker
Localization, by James Offer
Logos
Maps, by Michael Gaigg
Marketing and copywriting
One page designs, by Rob Hope
Open Graph images
Patterns and textures
Personal sites
Presentation decks, by Muharrem Ş.
Privacy, by Michael Colesky, Jaap-Henk Hoepman et al.
Respectful design
Sustainability, by Nick Lewis
Spatial design, by Arun Venkatesan
Video reels, by Ales Nesetril
Visual design, by Veerle Pieters
Visual identity, by Sahkyo
Whimsical websites, by Max Böck

Component.gallery, a growing collection of components from design systems, broken down by category, by Iain Bean.

Designer’s Guide To Redesign, Step-By-Step

Vitaly Friedman — Tue, 14 Nov 2023 00:00:00 +0000

Redesigns are often expensive, time-consuming and incredibly risky. Of course sometimes big-bang-redesigns are necessary, yet more often than not they can be avoided with a series of strategic incremental changes. Here are a few things to keep in mind before launching a big-scale redesign effort.

How to redesign, a step-by-step guide, a comprehensive guide by Taras Bakusevych.

Users Don’t Like Change If They Don’t See Value In It #

Personally, I always suggest to avoid redesign projects whenever possible. They are extremely costly, complex and time-consuming ventures — and too often without valuable outcome for end users. Instead, we need to seek where we can increase the value and apply our design efforts to that area.

As Jared Spool argues, we often think that users don’t like change. Yet users go through small and big changes all day long. What users don’t like are breaking changes. Sudden interruptions. Blockers. Bad surprises. Changes that they don’t understand and can’t see any value in. That’s what we need to avoid.

Redesign Step-By-Step Process #

A few years ago, Taras Bakusevych has written a wonderful practical guide on how to redesign to avoid pitfalls and deliver value fast. If you are getting into a redesign project, that's a fantastic practical guide to follow.

1. Build A Shared Understanding #

We start by building a shared understanding of what we are trying to achieve. We interview stakeholders, check their expectations, interview dev and support teams. We capture insights, thoughts and suggestions and define jobs to be done.

Start with building shared understanding: with stakeholder interviews, user interviews and study of your target audience. From a comprehensive guide by Taras Bakusevych. Large view.

2. Audit and Deconstruct Existing Design #

Then, rather than starting from scratch, we start deconstructing the existing design. We look out for patterns and flows that users understand and use frequently, and we study research and testing that has been done so far.

We deconstruct an existing design by watching out for frequent flows that users understand and rely on. By Taras Bakusevych. Large view.

3. Gather Evidence From UX Research #

Once we know where we stand, we need to explore where we want to head to. We gather evidence from UX research done so far, pain points that we are aware of, the problem areas that we need to address. That's where speaking to customer success and support can also be valuable.

4. Prioritize Key Problem Areas and Features #

It might be a good idea to create a simple prioritization matrix where we list features and pros of competition, identify key problem areas and find improvement opportunities. Before jumping into any design, we map the value vs. the effort on an impact matrix to set priorities.

We create a matrix with features and pros of the competition, identify key problem areas and search for improvement opportunities. By Taras Bakusevych. Large view.

5. Start Ideating and Sketching, But Test Early #

Eventually we start exploring, ideating, sketching. We come up with good candidates for improvements. We create low-fidelity storyboards and test new flows in early stages with actual customers. Then we develop a design language and apply it to critical pages or flows to test again. We iterate and keep testing.

Test early and often. We use storyboarding to sketch out ideas, then test them with actual users or customers. By Taras Bakusevych. Large view.

6. Bring Stakeholders On Board As Early As Possible #

While doing so, it’s a good idea to involve stakeholders in the design process as early as possible. Show them what you are working on. Record a weekly 1-min videos explaining the process. Explain why some decisions are made. Circulate it in your internal newsletter. Listen to the feedback, you will need to show that you’ve considered it later.

7. Design Presentation Shouldn't Have Big Surprises #

Eventually, you'll have to present and get a sign-off on a new design and the new direction. Ideally, by the moment you'll make a big presentation, you will already have an informal green light from your stakeholders. Show results from the testing. Show video snippets and audio clips of people struggling with the current design. Explain how the new design is better.

8. Don't Ask For Opinions, Ask For Agreement #

But: don't ask for opinions. Ask if people in the room agree with the direction the new design is taking, and if not, why not. You will need senior support to carry your new design in action. So as you evolve the new design, keep them in the loop.

9. Roll Out Slowly and Incrementally #

Roll out slowly. Add changes incrementally. Give users control over when change affects them and allow to change back to the old design at least temporarily. Most importantly, show the specific value that a new design brings to them. And then test again, review results and evolve — and prepare your customer service way ahead of time.

You Might Not Need A Redesign #

You might need to revamp email newsletters. Or improve your product pages. Or optimize for repeat business. Or address a new market. Or better cater to older audiences. Or just invest in a better search. These are typically much more urgent issues that everybody will benefit from.

But if you do, break up changes in small increments and roll out gradually. There shouldn’t be any big surprises and revelations with the redesign. Good redesigns are evolutions, not revolutions. Refine slowly as you go, and you’ll be surprised that users might not even notice that you’ve redesigned at all.

Key Takeaways #

Avoid big-bang redesigns unless absolutely necessary.
Always prefer incremental changes over a major overhaul.
Clean-up, archive, delete, update. Simplify first.
Build on top of already existing behavior patterns.
Give users control over when change affects them.
Give an option to try a new design now and later.
Allow to change back to the old design at least temporarily.
Don’t pack a lot of change in all at once.
Users accept changes if they see value in them.
Keep the old way of working first, and transition slowly.
Highlight and explain changes to returning users.
Show to users how the change benefits them.
Prepare your customer service way ahead of time.

A Guide To Designing For Mobile (iOS, Android)

Vitaly Friedman — Tue, 14 Nov 2023 00:00:00 +0000

When it comes to designing for mobile, there is always quite a bit of confusion between all the different units, guidelines and measurements in iOS and Android. Here’s a quick cheat sheet (PDF) to help you get started with your mobile app design.

Key Takeaways #

For Android, the most recent design language is Material 3.
For iOS, it’s Human Interface Guidelines (HIG) for iOS 17.
iOS apps are designed in pt, Android apps in dp.
When designing for iOS, start with 375×812pt.
When designing for Android, start with 360×640dp.

Designing For Mobile (iOS, Android) (PDF), a cheat sheet kindly shared by Isabelle Bamber.

iOS: “Back” is in the bottom left, Android: top left.
iOS: “Add” action is top right, Android: FAB is bottom right.
iOS: Primary text and forms at least 17pt, tab bar at least 10pt.
Android: Primary text and forms at least 14sp, labels at least 11sp.
Tap targets: 11mm+ (31pt/42px) on the top of the screen.
Tap targets: 12mm+ (34pt/46px) at the bottom of the screen.

How To Make A Strong Case For UX Research

Vitaly Friedman — Mon, 13 Nov 2023 00:00:00 +0000

So you want to conduct UX research, yet you find yourself constrained — by wrong assumptions and wrong expectations about what UX research actually entails. Research doesn’t have to be time-consuming. It doesn’t have to be expensive. And it doesn’t have to be disruptive. Let’s see how we can address reluctance and make a strong case for UX research.

Key Takeaways #

Don’t assume that stakeholders don’t see value in research.
They want to avoid disruptions, delays and minimize risk.
They expect research to be expensive and time-consuming.
The reluctance might be a fear of challenging status quo.
Or a fear of uncovering failures and costs of fixing them.
Or a fear of insights that conflict with top-level decisions.

How to measure UX research impact, a multi-level framework by Karin den Bouwmeester. Large view.

Don’t mistake polite nodding for agreement or commitment.
Best timing for research is when risk is high and clarity is low.
Show how research can reduce risk and prevent costly failures.
Design without research is guesswork driven by assumptions.
Showcase previous successes of UX research in the past.
Aim for impact: find similar problems for larger projects across teams.
Don’t advocate for the value of UX research empty-handed.
Pitch a research plan based on stakeholders’ goals and needs.
Show a roadmap, goals, timelines, people involved and related costs.
Explain how you will use the outcomes to guide design decisions.
Ask for small but steady commitments to small-scale research.

Align UX Research With Stakeholders’ Objectives #

When you face reluctance from stakeholders, try to understand where it’s coming from. Study their KPIs, goals, constraints, priorities — and try to align your research with stakeholders’ objectives. As Erika Hall famously suggested, build a strong relationship with a person before trying to change their mind.

Most importantly, study their previous experiences with research initiatives. Try to find specific reasons for reluctance. Chances are high that the outcome of research stirred conflicts or problems that they’d like to avoid. In fact, they might not be against research, but the consequences that come along with it.

There is never enough research. Yet most successful products come from continuous research that informs and guides design and business decisions. Start slowly, get small but steady commitments and progress from there.

It might not take too long for research initiatives to be noticed, appreciated, supported — and perhaps even initiated by top-level management.

Stop Tracking NPS (Net Promotion Score)

Vitaly Friedman — Fri, 03 Nov 2023 00:00:00 +0000

Good research is always rooted in the past, not in the future. Net Promotion Score has many flaws: in how it asks users to predict their future behavior, the Likert scale and the statistically unreliable score calculation. There are better alternatives.

1. How Net Promoter Score (NPS) Works #

The main assumption behind NPS is that business success depends on positive word of mouth. NPS is a number in the range of -100% to 100%. We ask users to answer a question "How likely are you to recommend [X] to a friend or a colleague".

Responders are grouped into detractors (0-6), passives (7-8) and promoters (9-10). NPS score = %Promoters – %Detractors. The higher, the better.

NPS score is originally intended to be an indicator of loyalty to a brand. However, it’s statistically unreliable and flawed. Large view.

2. The Science Behind NPS Is Wacky #

NPS doesn't use the mean average of the numbers received. It raises red flags: NPS leaves a lot of survey data out, it has weak statistical properties and it’s more susceptible to random noise. Also, gaming the values is relatively easy.

3. You Need Large Sample Sizes #

To get to statistical significance, you need to gather feedback literally from thousands of users. Because NPS survey response rate is 4–7%, you need to send it to hundreds of thousands of customers. It’s unpractical and makes NPS mostly irrelevant for experimentation.

4. NPS Is Fragile And Hides UX Success #

Even if the product team has been moving mountains to improve customer experience, NPS won’t accurately reflect it. Small incremental improvements should bring incremental score increases, but NPS doesn’t work that way. It has very high variance and very abrupt jumps in scores.

5. NPS Captures Only Most Recent Activity #

Customer loyalty is a long play. It’s about how someone behaves over a long period of time, yet NPS is skewed to the most recent user’s experience. As Jared Spool suggests, “the best research questions are about past behavior, not future behavior.”

6. We Can’t Reduce UX To A Single Number #

We need to combine qualitative and quantitative insights to capture the quality of UX. We can use top tasks methodology and design KPIs to measure individual interactions with our products, sites and the brand.

7. Choose Metrics That Matter For Your Product #

Itamar Gilad suggests that the core mission of every company is to deliver value and to capture value back. We need to define both. In his article, Itamar reviews the North Star Metric (customer value) and Top KPI (business value).

How To Fix a Bad User Interface

Vitaly Friedman — Fri, 03 Nov 2023 00:00:00 +0000

Every screen you interact with has multiple personalities: blank state, loading state, partial state, error state and ideal state. How To Fix a Bad User Interface highlights strategies to avoid awkward and confusing UIs with the UI Stack, carefully designing personalities for every screen. By Scott Hurff.

UX is not just what happens when everything goes as planned. It’s also what customers experience when things break unexpectedly. Image source.

Five States of User Interface #

We start with the ideal state. It’s the zenith of your product's potential. We then explore the error state, when things go wrong, with unexpected problems, error messages and input validation UX. From there on, we move to the partial state — when the page is sparsely populated. Our job here is to prevent people from getting discourage and giving up on our product.

In the loading state, when users are waiting for an update to come through, we must avoid frustrating rage taps/clicks and allow users to set filters and sorting and search by being mindful on how we represent situations when we're fetching data. We need to avoid an entire page takeover, but rather lazy load content panes or use inline loading.

Finally, we can improve the blank states by using skeleton screens where we show the structure and layout of the page early, or optimistic actions where we assume access by default and hence reduce the perceived speed of uploading data. If it goes unexpectedly wrong, we flag an error and ask users for their input.

Personally, I often start exploring errors and recovery flows early because they often leave users frustrated and disappointed. Looking into "broken" state helps you also figure out how you communicate to your users, your tone and voice, and hence the messaging.

A great reminder that UX is not just what happens when everything goes as planned. It’s also what customers experience when things break unexpectedly.

How To Avoid Misunderstandings In The Design Process

Vitaly Friedman — Thu, 02 Nov 2023 00:00:00 +0000

Often misunderstandings don’t just cause confusion. They bring team members apart, erode trust and produce waste. They often come from wrong assumptions and unrealistic expectations.

Of course every UX task is different. But every task requires a shared understanding about the process, the people involved and the expectations that come with it. To get there, I typically prepare a one-pager with 10 sections — a statement of work that typically includes only bullet points, and nothing else.

The Statement of Work #

This is how we understood the problem.
This is what we think the solution requires (steps and tasks).
These are the assumptions that we’re making.
This is how we work, and how we will work together.
This is where and when we’ll need a (timely) input by stakeholders.
These are the milestones, the timeline and deliverables.
That’s the delivery date we commit to (for that scope of work).
That’s the total cost of the work and how it will be paid.
Late scope changes are expensive and cause delays.
All scope changes are estimated and billed separately.

Just before heading into a project, we set up a call to discuss if we understood the problem correctly, if the process is clear and if we've overlooked something critical. I mention twice the role of UX research and evidence-driven decision making, and that late scope changes are expensive and cause delays.

The goal of that meeting is to iron out anything that might cause confusion or frustration later — and to get a sign off on that 10-sections document.

An overview of all sections that go into a 10-pager for the scope of work. Large view.

We don’t know how our stakeholders work. We don’t know their constraints, their budgets, their timelines. So we shouldn’t expect them to know our design process either. Instead, we should explain how we work, what is important to us, and why last-minute changes are expensive and cause delays.

Stakeholders don’t want to make our lives difficult. They want us to succeed. We want the same. Ask them what is important to them, and tell them what is important to you. It won’t always work, but when it does, you get stakeholders on your side, supporting you and respecting your process from start to finish.

How To Defend Your Design Decisions

Vitaly Friedman — Mon, 30 Oct 2023 00:00:00 +0000

Design decisions are often seen as a matter of opinion or preference. But design solves problems, and so good design decisions shouldn’t be based on hunches or opinions. They have good reasons, they address the problem effectively, and as such, they impact business goals.

We just need to have a strategy on how to defend our design decisions, to protect our work, avoid design by committee and pick battles wisely. Let’s see what it could be.

How to defend your design decisions? It’s always a good idea to prepare research data to backup.

Key Takeaways #

🚫 Avoid big surprises when presenting your work.
✅ Ask for feedback gradually, at different stages of the design.
✅ Strong decisions rely on data and research, not hunches.
✅ Attach your decisions to a goal, metric, or a problem.
✅ Show what’s possible short term, and your plan for the future.

✅ Re-iterate business goals before showing any of your work.
✅ Show the process that led you to your current design.
✅ Explain how your current decision impacts business goals.
✅ Highlight key takeaways from previous rounds of feedback.
✅ Highlight advantages and risks to show they’ve been considered.

🚫 Don’t fight an argument: find the problem brought into spotlight.
✅ You might be wrong: defend the project goals, not your work.
✅ Ask to articulate and explain the argument in detail.
✅ Have alternatives ready, and explain why they were discarded.
✅ Defer the decision: request to review it with your team.
🚫 One suggestion is a goldmine of other ideas waiting to be excavated.

Good Design Isn’t About Winning #

Good design isn’t about being the winner in the big meeting. It’s about finding the flaws and wrong assumptions to make sure your work matches business goals while supporting user’s needs. So be deliberate and meticulous explaining how your decisions impact business goals.

Nothing diffuses argument like agreement. Don’t get defensive — as Tom Greever said, when we become defensive, we fail to focus on the real issues. So avoid big public debates. Avoid speaking about your personal preferences, what you like or dislike.

Don’t ask “What do you think?” as it prompts personal opinions. Instead, ask if attendees agree with the direction (yes/no), and if not, why not. Most importantly, defend your design decisions when you know it’s right, but leave your ego aside when you feel you aren’t.

Useful resources #

Defending UX Design Decisions, by Chris Kiess
The Tyranny of Collaborative Ideation, by Lars Jerichau
Articulating Design Decisions (Book), by Tom Greever
How To Avoid Design By Committee, by Paul Boag
Articulating Design Decisions to Stakeholders
Strategies To Deal With Design By Committee, by Jen Lee

Beautiful, Inclusive, Free Photos of People

Vitaly Friedman — Wed, 25 Oct 2023 00:00:00 +0000

Where would you find inclusive, free-to-use photos of diverse people? There aren’t many resources out there, but the ones that do exist are absolutely fantastic. Here are some useful pointers that you might use in your work.

Beautiful, Inclusive, Free-To-Use Photos of People, a wonderful growing library of photos and illustrations that celebrate disabled Black, Indigenous and people of color (BIPOC). Published under Creative Commons, and you can use it for free with an attribution. Wonderful effort by the Open Collective Foundation.

A Person Touching a Braille Book, a photo by Yan Krukov.

Free Photos of Diverse People #

Free Photos On Disability #

Pexels
Unsplash
Freepik
Rawpixel
FreeImages, (not free)
Disabled Persons Collection, (not free)
SocietyPix, free for editorial purposes, credit required
Small collections: DisabilityIn, Home Safety Best Practices, Pixieset, Stocksnap
Stock Photos of People With Disabilities, by Dennis Lembree
Stock Photo Sites for Inclusion

There are some absolutely incredible photos and illustrations in there — wonderfully suited for presentations, mock-ups, reports and anything in-between. We can use them to prompt and encourage more diverse and inclusive conversations and design decisions.

A huge, HUGE thank you to everyone releasing these photos and illustrations for all of us to use.

🙏🏼🙏🏾🙏🏾

Double Diamond Is Not How Most Companies Work

Vitaly Friedman — Sun, 15 Oct 2023 00:00:00 +0000

Do you actually rely on the well-established Double Diamond process in your design work? Chances are high that you had to cut corners, make tough compromises and keep convincing stakeholders about the right approach to design.

Is there a single, universal, perfect design process? Of course not. But we can try to improve our existing process to better accommodate the complexity and messiness of the world around us. Let’s see how.

Improving Double Diamond Design Process, a wonderful article on a more realistic design framework, by Andy Budd. Large view.

The reason why Double Diamond often fails is simple: too often Double Diamond doesn’t work well in practice. In fact, Andy Budd has shared a more realistic and honest overview of how the work actually gets done in real-life and where design has most leverage.

Design Process In Real-Life #

✅ Stakeholders rarely want you to think outside of the box.
✅ They want a cost-effective implementation of their idea.
✅ Discovery is for finding evidence to back up assertions.
✅ Direction is often chosen before design work happens.

✅ Double Diamond works in theory, but not in practice.
✅ Most companies work with a Reverse Double Diamond.
✅ You accept the work, monitor it, improve it post-launch.
✅ Once it’s launched, gather evidence, iterate, test, refine.

Double Diamond Is Often Not Enough #

Personally, I don’t think that Double Diamond is irrelevant or obsolete. Just as Andy writes, it’s a wonderful concept that helps designers avoid shallow solutions, understand the problem space well and then come up with creative solutions that actually address the problems that customers are facing.

However, too often it’s not enough — and it’s not quite how companies work. Companies often rush to the market to launch something quickly — and Double Diamond is seen at best as unnecessary friction, and at worst as an absolute waste of time.

And as a designer, I don’t want to waste anybody’s time. So before designing a single pixel on the screen, I need to be absolutely certain that I’m designing something that has been tested with actual users and shows promise to reach the impact that we are aiming for.

Meet The “Triple Diamond Process” #

I need to test hypotheses, to experiment back and forth, to refine and adjust and discard and reinvent the wheel if needed. And too often, “Double Diamond” doesn’t provide enough space and time to do that. So my design workflow seems to be closer to what Adam Gray describes as the “Triple Diamond Process”.

Why double diamond isn’t enough, focusing on the missing diamond — experimentation and testing. By Adam Gray. Large view.

As we iterate with hypotheses, we test them meticulously — with tree testing, Kano model surveys, low-fidelity protoypes and interviews with users and stakeholders. Once we have evidence that shows a positive trajectory, we start build a proof of concept, and evolve from there.

As design gets refined and adjusted, we keep testing continuously, with business requirements and user insights informing and guiding design decisions. No decision should be random, or a matter of preference — and there is always enough data to back up and defend design decisions.

Wrapping Up #

You always need allies to carry your design in action. Opposing the existing process is an uphill battle. So frame the task at hand as a design challenge, and explore how to deliver most value for users and business. Measure its impact, refine and post-launch.

You might be surprised by how quickly you might find the support you need to turn the process all around and start designing the right thing, the right way.

You can find more details on design patterns and UX in the video library on Smart Interface Design Patterns — with a live UX training that’s coming up in March 2024.

Useful Resources #

Improving The Double Diamond Process, by Andy Budd
How To Apply Double Diamond From Scratch, by Dan Nessler
Why Double Diamond Isn’t Enough, by Adam Gray
The Best Handoff Is No Handoff, by Vitaly Friedman
Design’s Mid-Life Crisis (talk, 35 mins), by Andy Budd
The Illusion of Different Design Processes, by Maximilian Schmidt
Double Diamond Process at Doodle, by Stephanie Leue

Should Links Open In New Tabs?

Vitaly Friedman — Tue, 26 Sep 2023 00:00:00 +0000

That’s a question that seems to fuel never-ending discussions year after year. Do we open external links in new tabs by default? Do we mark external links? How do we deal with links to PDFs, videos and audios? Let’s figure it out!

Below are some practical UX guidelines on how to open internal and external links without breaking user’s flow and causing frustration.

How To Design Better Links, a wonderful article on how to improve links UX, by Slava Shestopalov. Large view.

Things To Keep In Mind #

🚫 Users often get lost and confused in their browser tabs.
🚫 Some users don’t realize that they landed in a new tab.
🚫 Users can’t easily go back when links open in new tabs.
🚫 New tabs are especially frustrating for mobile users.
✅ Task completion improves when users feel in control.
✅ Abrupt interruptions cause errors and delays.

✅ By default, always open links in the same browser tab.
✅ If there is an external link, make it clear in the link text.
✅ If users are in the middle of a process, warn them.
✅ Explaining links in words is more effective than in icons.

✅ Hubs with externals links could open in new tabs.
✅ PDF documents could open in new tabs (desktop only).
✅ Clearly mark links to PDFs, video/audio files as such.
🚫 Whenever possible, avoid PDFs and use HTML instead.

Should External Links Be Marked With Icons? #

Not necessarily. As Tim Paul suggests, the icon is often ambiguous and unclear to users as they might confuse it with opening a page in a new window. In general, using a text label to explain that a link will be opened in a new tab is more effective than using an icon.

Personally, I have seen external links with external icons working well in the past, but it might be a good idea to explore if they are actually needed as they can pollute the page quite a bit when you have a hub of external links on your page.

Wrapping Up #

When some links open in new tabs while others do not, users typically tend to complete their tasks slower, paying close attention to the UI and how it works. That’s also when they try to “take over control” of the interaction by using the right-click menu to open links in a way that they prefer.

This isn’t surprising. When links always open in the same tab, users can always choose to open them in a new tab or not. But if some links open in a new tab by default, they don’t have that choice until they’ve realized that they are in a new tab, and have to deal win an unintended action.

New windows or tabs also cause accessibility issues for people with poor vision and screen reader users, especially when they open outside of the area that’s magnified or being read out loudly.

Default behavior works best. It’s accessible, obvious and gives people choice. And that’s exactly what a good UX provides.

Useful Resources #

How To Design Better Links, by Slava Shestopalov
WCAG 2.0: Open New Windows and Tabs From a Link Only When Necessary
PDF: Still Unfit for Human Consumption, by Anna Kaley, Jakob Nielsen
Do Not Use An External Icon For Links, by Tim Paul
Links Should Open in the Same Window, by Michael Schofield
Should Your Website’s Links Open in a New Tab?

You can find more details on usability in the chapters of the video library on Smart Interface Design Patterns 🍣 — with a live UX training that’s coming up later this year.

How To Make A Strong Case For Accessibility

Vitaly Friedman — Sun, 17 Sep 2023 00:00:00 +0000

Getting support for accessibility efforts isn’t easy. There are many accessibility myths, wrong assumptions and expectations that make accessibility look like a complex, expensive and time-consuming project. Let’s fix that!

Below are some practical techniques that has been working well for me to convince stakeholders to support and promote accessibility in your company.

Things To Keep In Mind #

🚫 You can’t build empathy with facts, charts or legal concerns.
🚫 People often dismiss concerns that they can’t relate to.
🚫 People often don’t know how accessibility applies to them.
🚫 People often assume that accessibility is dull and boring.
🚫 Business often neglects it as irrelevant edge case.

✅ Nothing is more impactful than seeing users struggle.
✅ Bring users with disabilities for testing to show accessibility.
✅ Ask for small commitments first, then progress from there.
✅ Accessibility isn’t expensive nor tedious if done early.
✅ But it can be very expensive when retrofitted or done late.

🚫 Don’t mistake polite nodding for agreement or commitment.
✅ Anticipate objections about costs, competition, slowdowns.
✅ Make a business case for lower costs and increased revenue.
✅ Create a roadmap with actions, timelines, roles and goals.
✅ Set up regular accessibility testing (e.g. every 6–8 months).

Inclusive Design Toolkit, kindly shared by Microsoft, highlighting permanent, temporary and situational disabilities. Large view.

“But Accessibility Is An Edge Case!” #

❌ ”But accessibility is an edge case. Given the state of finances right now, unfortunately we really can’t invest in it right now.”

🙅🏼‍♀️ “I respectfully disagree. 1 in 6 people around the world experience disabilities. In fact, our competitors [X, Y, Z] have launched accessibility efforts ([references]), and we seem to be lagging behind. Plus, it doesn’t have to be expensive. But it will be very expensive once we retrofit much later.”

“But We Don’t Have Disabled Users!” #

❌ “Why should we prioritize accessibility? Looking at our data, we don’t really have any disabled users at all. Seems like a waste of time and resources.”

🙅🏼‍♀️ “Well, if a product is inaccessible, disabled users can’t and won’t be using it. But if we do make our product more accessible, we open the door for prospect users for years to come. Even small improvements can have a high impact. It doesn’t have to be expensive nor time-consuming.”

“Screen Readers Won’t Work With Our Complex System!” #

❌ Our application is very complex and used by expert users. Would it even work at all with screen readers?”

🙅🏼‍♀️ “It’s not about designing only for screen readers. Accessibility can be permanent, but it can also be temporary and situational — e.g. when you hold a baby in your arms, or if you had an accident. Actually it’s universally useful and beneficial for everyone.”

Wrapping Up #

To many people, accessibility is a big mystery box. They might have never seen a customer with disabilities using their product, and they don’t really understand what it involves and requires. But we can make accessibility relatable, approachable and visible by bringing accessibility testing to our companies — even if it’s just a handful of tests with people with disabilities.

No manager really wants to deliberately ignore the needs of their paying customers — they just need to understand these needs first. Ask for small commitments, and get the ball rolling from there.

Set up an accessibility roadmap with actions, timelines, roles and goals. Frankly, this strategy has been working for me much better than arguing about legal and moral obligations, which typically makes stakeholders defensive and reluctant to commit.

Fingers crossed, and thank you for your incredible work for pushing accessibility forward, everyone!

Useful Resources #

How To Make The Business Case For Accessibility, by R Gregory Williams
Making The Case for Accessibility, by Susanna Zaraysky
Making A Strong Case For Accessibility, by Todd Libby
Accessibility Case Studies and Success Stories, by Deque
Inclusive Design Toolkits and Templates, by yours truly

You can find more details on design systems in the new chapters of the video library on Smart Interface Design Patterns 🍣 — with a live UX training that’s coming up later this year.

How To Design For Autistic People

Vitaly Friedman — Wed, 23 Aug 2023 00:00:00 +0000

Nearly 1% of the global population is autistic. Yet often it’s not obvious how to consider the needs of autistic people in the design process. Let’s change that.

Below are some general UX guidelines, do’s and don’ts to design better UX — for autistic people and everybody else. Most of these guidelines are universal, and improve the experience for everyone.

Design guidelines on how to design for autistic people (PDF), from a wonderful series of inclusive design posters by Gov.uk. Large view.

There Is No Single “Autistic Experience” #

Essentially, autism is a different way of experiencing the world. The experience is usually intense and tangled. However, every person on the autism spectrum experiences the world differently.

Oftentimes with their own superpowers in fast learning or keen attention to details, and sometimes with enormous frustration about the busy and noisy world. In fact, 40% of autistic people have an anxiety disorder.

How To Talk And Write About Autism (PDF), a wonderful resource with examples, do’s and don’ts, by National Autistic Society in the UK.

One can’t grow out of autism, and all autistic children usually grow up into autistic adults. As autists, we usually have a low tolerance to uncertainty and lack of control. Autistic people are also strongly sensitive to bright colors and high contrast — and tend to be very literal, so it’s hard to infer meaning that’s not obvious.

Guidelines To Design For Autistic Users #

🚫 Avoid bright contrasting colors and high luminance.
🚫 Avoid figures of speech and idioms (verbal or visual).
🚫 Avoid animations that are hard to control.
🚫 Avoid non-conventional scrolling behaviour (parallax).
🚫 Avoid time countdowns, time outs, a sense of urgency.
🚫 Don’t rely on jargon, abbreviations, sarcasm, idioms.

✅ Show all content about a subject on a single page.
✅ Use soft, muted colors and avoid pure white or black.
✅ Add text labels to icons and avoid icons-only buttons.
✅ Allow users to save and return to forms later.
✅ Respect user’s reduced motion preferences.
✅ Support email/chat as communication options.
✅ Autistic children tend to be visual learners.
✅ Autistic adults prefer well-structured text.

You can find further guidelines and examples in Designing For Autistic People: A Guide by Irina Rusakova.

Wrapping Up #

We can rarely design one single perfect experience for absolutely everyone. But by involving a diverse group of users in usability testing, we can make our products more accessible for absolutely everyone.

Whenever you can, involve colorblind users, autistic people and people with disabilities into testing — you will always learn useful insights. That might be a few hours of work for us, but it might be absolutely life-changing for other people — and that’s worth it every single time.

Useful Resources #

Designing For Autistic People: A Guide, by Irina Rusakova
How to Talk and Write About Autism (PDF Guide)
Design For Autistic People: Existing Research, by Irina Rusakova
Designing For Users On The Autistic Spectrum (PDF)
Usability Testing with Autistic People, by Varnagy-Toth Zsombor
The Pattern Seekers (Book), by Simon Baron-Cohen
Connecting with the Autism Spectrum (Book), by Casey Remrov Vormer

You can find more details on design systems in the new chapters of the video library on Smart Interface Design Patterns 🍣 — with a live UX training that’s coming up later this year.

How To Name Design Tokens in Design Systems

Vitaly Friedman — Tue, 22 Aug 2023 00:00:00 +0000

Design tokens represent small, repeatable design decisions. Instead of using exact HEX or px-values, we refer to a token which name describes how and where they are used. It makes it much easier to update the design by changing one value in one place and not breaking anything else in-between.

Creating a flexible design token taxonomy for Intuit’s Design System, a thorough case study by Nate Baldwin.

We break apart every single UI component into standalone tokens. The more specific these tokens are, the more confidence we have in using and changing them across the product. But the more generic the tokens, the more flexibility we have in using them. In fact, components tokens is where most design system teams struggle.

Taxonomy and naming conventions, from [type][element] to [state][index].

Naming patterns are exhibited via naming levels — e.g. {namespace}-{category}-{role}-{modifier}-{theme}). Common levels are category, concept, property, variant/scale and state. Regular design systems typically use a few levels, but large multi-platform systems might have as many as 5–6 naming levels.

The Different Flavors of Design Tokens #

Good tokens explain what they do (e.g. badge-background-color-hover). However, tokens come in different flavors and shades, and it’s not uncommon to have multiple levels of design tokens referencing each other:

Raw values are the actual design choices (#147AF3).
Primitives (global tokens) are used across the system (blue-800).
Semantic (alias tokens) reference other tokens (accent-visual-color).
Component tokens apply to UI components (button-accent-color).

Naming Tokens in Design Systems, a very thorough introduction by Nathan Curtis.

Things To Keep In Mind #

We use naming levels to add context to tokens: e.g. {context}-{role}-{modifier}.
Namespaces might help, too: e.g. {namespace}-{concept}-{role}-{modifier}.
E.g. --n-feedback-alert-success, --n-checkbox-control-size-large.
Frequent levels are category, component, property, variant/scale, state, mode.
Namespaces (system, theme, domain) are prepended first.
Base levels (category, property, concept) are a backbone in the middle.
Modifiers (variant, state, scale, mode) tend to be appended last.
Regular systems use 2–4 levels, large systems can use many more.

Supercharge your Design System with Design Tokens, a friendly guide by Jishnu Hari.

Useful Examples of Design Tokens #

The larger the design system, the more likely they designers are to use design tokens. The examples below include very thorough documentation on design tokens, and some guidelines when to use which. Just a few options from my bookmarks.

Design Tokens in the Paste Design System, with a structure chart documenting design decisions.

Useful Resources #

Naming Tokens in Design Systems, by Nathan Curtis
Practical Guide to Naming Design Tokens, by Lukas Oppermann
Supercharge Your Design System with Design Tokens, by Jishnu Hari
Figma Tokens Plugin, by Jan Six
Design Tokens 101, by Romina Kavcic
Guide To Design Tokens and Naming Conventions, by Romina Kavcic
Design Tokens For Intuit’s Design System, by Nate Baldwin
Friendly Guide to Design Tokens (+ Figma template), by Specify
Naming Tokens in Design Systems (Figma Kit), by Marta Conde
Design Tokens in Figma: How to Get Started, Today (Video), by Jan Six
Everything on Design Tokens, by Stuart Robson

You can find more details on design systems in the new chapters of the video library on Smart Interface Design Patterns 🍣 — with a live UX training that’s coming up later this year.

Free Books For Interface & UX Designers

Vitaly Friedman — Thu, 17 Aug 2023 00:00:00 +0000

These books have been kindly shared by the community, with lessons learned by authors for everybody to read and benefit from. A sincere, enormous thank-you to the authors for making their work available to everyone for free. Hopefully you and your friends will find them useful, too.

Free Books For Designers #

The Shape of Design, by Frank Chimero, Mandy Brown
How To Design a Dashboard, by Matt David
A Practical Guide to Information Architecture, by Donna Spencer
The Manager's Handbook, by Alex MacCaw
Business Thinking for Designers, by Ryan Rumsey
Animation in Design System eBook, by Val Head
Shape Up: Stop Running in Circles and Ship Work that Matters, by Ryan Singer
Jobs to Be Done + Starting Up, by Intercom
Combining Typefaces: Free guide to great typography, by Tim Brown
Practical Typography, by Matthew Butterick
Shady Characters, by Keith Houston
Stop Stealing Sheep & Find Out How Type Works, by Erik Spiekermann
Designing For The Web, by Mark Boulton
Giving a Damn About Accessibility, by Sheri Byrne-Haber
Typography Playbook
The Growth Handbook, by Intercom Authoritative, actionable strategies from industry leaders on how to grow your business.
Enterprise Design Sprints, by Richard Banfield
Customer Engagement Handbook, by Intercom
Why Do We Interface, by Ehsan Noursalehi A historical look at the past, the present and future of digital interfaces.
The Onboarding Guide, by Phil Byrne
Content Strategy: A Guide for UX Designers, by Liam King
How To Make Sense Of Any Mess, by Abby Covert
The Complete Guide to Product Prioritization
Free Content Design eBooks for UX Designers

Shape of Design, a wonderful book all around design, its main purpose and how to be a better designer.

The Monster List Of UX Books #

If you are looking for a categorized, searchable list of UX books, The Monster List of UX Books is a fantastic up-to-date list of UX books, grouped by categories, ranked, tagged, searchable and with references to authors. You can suggest and rate books as well. Kindly maintained by Chris Oliver.

Monster List of UX Books, a wonderful collection of books, neatly categorized in one single place.

My Favorite Books #

Some of the most remarkable books I’m remembering reading are the ones that questioned what I believe in, and change my view of the comfortable universe which I have built around me over the years. Here are some of such books that I keep very close to my heart (in no specific order):

The User Experience Team of One, by Leah Buley
The Shape of Design, by Frank Chimero
Just Enough Research, by Erika Hall
How To Make Sense of Any Mess, by Abby Covert
Mismatch: How Inclusion Shapes Design, by Kat Holmes
Design Systems, by Alla Kholmatova
Universal Principles of Design, by Jill Butler, Kritina Holden, William Lidwell
Making of a Manager, by Julie Zhuo
Envisioning Information, by Edward Tufte
Form Design Patterns, by Adam Silver
Change by Design, by Tim Brown
Meeting Design, by Kevin M. Hoffman
The Laws of Simplicity, by John Maeda
Steal Like An Artist, by Austin Kleon
Build, by Tony Fadell

I could never emphasize enough just how grateful I am to authors taking the time to put together their thoughts and experiences in a book. I know just how much I personally learned from each of the books — and there are so many other wonderful books to discover!

If you can, please support authors and your local stores — and perhaps even send a warm hello to them to let them know just how valuable and impactful their writing has been to you.

Color Contrast Cheat Sheet PDF

Vitaly Friedman — Mon, 14 Aug 2023 00:00:00 +0000

Poor color contrast is the most common problem on the web. Here are some useful guidelines for text and buttons, with minimum contrast recommendations for better legibility, a few color contrast tools and useful resources.

How Color Contrast Is Calculated #

In general, color contrast captures the difference in brightness between two or more colors. We often use it to measure how well one foreground color works against a background color. Under the hood, the contrast is calculated using relative luminance of colors.

Color Contrast Cheat Sheet PDF (scroll to the bottom), kindly shared by Oliver Schöndorfer. Large view.

The greater the difference in luminance, the higher the contrast ratio. And the higher the contrast ratio, the better the readability. For example, white-on-white has the 1:1 contrast ratio (minimum), black-on-white is 21:1 (maximum).

However, we don’t need extreme color contrast though. In practice, moderate contrast between these extremes usually works best. We use color contrast to ensure legibility and color differentiation in our UIs. Keep in mind that a high color contrast alone isn’t sufficient for colorblind people.

WCAG 2.1 Level AA, Minimum Contrast Cheat Sheet #

✅ Level AA is considered the industry standard today
✅ 4.5:1 for regular text vs. background (7.1 for AAA)
✅ 3:1 for text larger than 24px (4.5:1 for AAA)
✅ 3:1 for bold text larger than 19px (4.5:1 for AAA)
✅ 3:1 icons and graphs of any size
✅ 3:1 UI elements, buttons, borders, underlines

Please keep in mind that these guidelines are minimum recommendations, and color contrast is one of the many factors that contribute to better accessibility. We might want to add a border to create boundaries for our UI components. And it is a good idea to add an icon or an underline to clearly mark interactive components.

You can find more details and a cheatsheet PDF in the end of Oliver’s article (email is required).

Useful Color Contrast Tools #

Useful Articles on Color Contrast #

Fix Color Contrast – Web Accessibility for Text & UI Design, by Oliver Schöndorfer
Color Accessibility: Tools and Resources, by Stéphanie Walter
An Interactive Guide To Colors and Contrast, by Nate Baldwin
The “Dark Yellow Problem” in Color Palettes
Designing Accessible Color Systems (Stripe case study), by Daryl Koopersmith, Wilson Miner
Accessible Palette: Stop Using HSL for Color Systems, by Eugene Fedorenko
Color Contrast Guidelines With APCA, by Lisa Charlotte Muth

A Guide For Designing For Older Adults

Vitaly Friedman — Tue, 25 Jul 2023 00:00:00 +0000

Avoid Wrong Assumptions #

Don’t assume that older adults struggle to use digital.
You don’t need to strip the design to bare minimum.
Avoid general stereotypes and assumptions about elderly people.
Most users are healthy, active and have a solid income.

How To Write Better Microcopy For Older Adults highlights practical examples of designing interfaces with older adults in mind.

Things To Keep In Mind #

Older adults often read and analyze every word (Stroop effect).
Shades of blue/purple and yellow/green are difficult to distinguish.
Visuals with a similar contrast are harder to tell apart.
Often struggle with precise movements and text input.
Users are more likely to perform actions they didn’t mean to.
They take more time and need more control over the process.
They often view error messages as a personal failure.

Things To Avoid #

Avoid disappearing messages: let users close them.
Avoid accessibility overlays; they are often inaccessible.
Avoid long, fine drag gestures and precision.
Avoid floating labels and use static field labels.
Don’t rely on icons alone: add descriptive labels.
Ask for explicit confirmation for destructive actions.
Add a "Back" link in addition to browser’s “Back” button.
In forms, present one question or one topic per screen.

Useful Resources #

So, You’re Managing a Design Team, by Alex Mandel
How To Write Better Microcopy For Older Adults, by Michal Halperin Ben Zvi (PhD.) and Kinneret Yifrah.
What You Can Learn From Older Adults About Accessible Design, by Becca Selah
A Guide to Interface Design For Older Adults, by Sergei Polyuk
Designing User Interfaces for an Aging Population, by Jeff Johnson and Kate Finn
Age-Friendly Digital Design Toolkit (PDF guide, email required)
Age-Positive Image Library
Voice Design Strategies for the Elderly Population, by Shyamala Prayaga
Creating Online Environments That Work Well For Older Users, by Barry Rueger
Usability Testing With Older Adults, by Megan Chan

Wrapping Up #

We should be careful not to make our design decisions based on assumptions that are often not true at all. We don’t need a “barebones” version for older users. We need a reliable, inclusive product that helps people of all groups feel independent and competent.

Bring older adults in your design process to find out what their specific needs are. It’s not just better for that specific target audience — good accessibility is better for everyone. And huge kudos to wonderful people contributing to a topic that is often forgotten and overlooked.

Practical Guide For UX and Design Managers

Vitaly Friedman — Tue, 25 Jul 2023 00:00:00 +0000

Things To Avoid as a Design Manager #

Most managers don’t give enough feedback.
Don’t “sandwich” feedback — critique with humility.
Never do your team’s work; help them do their best work.
Don’t mandate decisions from the top; explain them.
Don’t be a silent voice in the back: be present at all times.
Don’t be scared to hire people who outperform you.

A comprehensive roadmap to design management, kindly put together by Alex Mandel. Full version.

Things To Do as a Design Manager #

Good managers are vulnerable and sincere.
Your best work gets done in well-prepared 1:1’s.
Track progress and achievements for each team member.
Fight hard for your team’s promotions and bonuses.
Start your week by asking your team how you can help.
Give feedback often, timely and firmly.
Set expectations and explain what success means.
Always set a structure around what needs to happen next.
Protect your team when something goes wrong.
Give your team the credit when things go right.
Keep your doors open at all times.

Management Isn’t For Everyone #

Personally, I’d like to emphasize that becoming a manager isn’t really a promotion. It’s not necessarily a “common” career path either. It's a different path, and an entirely new role — with new responsibilities and tasks.

The most remarkable part about management is that you can plant a seed and see people growing to incredible heights. But sometimes you will face confrontation, conflicts, strong opinions and lack of team spirit. This will make you feel exhausted, discouraged and lonely.

So don’t forget to build relationships with people who go through the same things like you do. Build a guild. Meet regularly. Share what has worked for you. Carve out time to think. To reflect. To build bridges and discover connections. If it’s for you, it will feel right. And if it isn’t, there is always a way back.

Useful Resources #

So, You’re Managing a Design Team, by Alex Mandel
Design Manager Playbook
How to Become a Better Design Manager, by Romina Kavcic
Motivations and Realities: From Design Lead to Manager, by Jared Zimmerman
Bitter Lessons as a Design Manager (+ part 2), by Slava Shestopalov
20 Lessons For New Design Managers, by 🪴Tarryn Lambert
Main Leadership Mistakes as a New Manager, by Claire Lew
Leadership Lessons as Product Design Manager, by Rayana V.
Good UX Manager / Bad UX Manager, by Peter Cho
Critical Skills of Effective Design Leaders, by Amy Cuevas Schroeder

Personal Stories and Journeys #

How I Grew From A Designer to a Design Manager, by Lindie Botes
First Year as a Product Design Manager, by Jonathan Meharry
Things I Learned in My First Year as a Design Manager, by Kyle Turman
The Brutal Truth About Becoming a Design Manager, by Martyn Reding

Useful Books #

The Manager's Handbook, by Alex MacCaw
The Making of a Manager, by Julie Zhuo
The First 90 Days, by Michael Watkins
Build, by Tony Fadell
Books for UX Managers, by Joshua Seiden

How To Design For Users With Colorblindness

Vitaly Friedman — Mon, 24 Jul 2023 00:00:00 +0000

Too often accessibility is seen as a checklist, but it’s much more complex than that. We might be using a good contrast for our colors, but then if these colors are perceived very differently by people, it can make interfaces extremely difficult to use.

Depending on our color combinations, people with colorweakness or who are colorblind won’t be able to tell them apart. Here are key points for designing with colorbliness — for better, and more reliable color choices.

Different people perceive colors differently. Around 300 million of people are affected by colorweakness or coloblindness.

Things To Avoid #

Don’t mix red, green and brown together.
Don’t mix pink, turquoise and grey together.
Don’t mix purple and blue together.
Don’t use green and pink if you use red and blue.
Don’t mix green with orange, red, blue of the same lightness.

Things To Keep In Mind #

Red-/green deficiencies are more common in men.
Use blue if you want users to perceive color as you do.
Use any 2 colors as long as they vary by lightness.
Colorbrlind users can tell red and green apart.
Colorbrlind users can’t tell dark green and brown apart.
Colorbrlind users can’t tell red and brown apart.
The safest color palette is to mix blue with orange or red.

Never Rely On Colors Alone #

The insights above come from “How Your Colorblind And Colorweak Readers See Your Colors”, a wonderful three-part series by Lisa Charlotte Muth on how colorblind and colorweak readers perceive colors, things to consider when visualizing data and what it’s like to be colorblind.

It’s worth noting that the safest bet is to never rely on colors alone to communicate data. Use labels, icons, shapes, rectangles, triangles, stars to indicate differences and show relationships. Be careful when combining hues and patterns: patterns change how bright or dark colors will be perceived.

Use lightness to build gradients, not just hue. Using different lightnesses in your gradients and color palettes so readers with a color vision deficiency will still be able to distinguish your colors. And most importantly, always include colorweak and colorblind people in usability testing.

Useful Resources #

How I Live With Color Blindness, by Andy Baio
Who Can Use This Color Combination?, by Corey Ginnivan
Designing for Colorblind Access, by Alex Chen
Colorblind-Friendly Design Guidelines, by Unma Desai
How To Choose Colors For Data Visualization, by Lisa Charlotte Muth
Coblis, Color Blindness Simulator
Color Blindness Simulator Figma Plugin, by Sam Mason de Caires
Colorblindly Chrome Extension, by Tom van Beveren
Improving The UX For Color-Blind Users, by Adam Silver
How To Test With Blind Users: A Cheatsheet by Slava Shestopalov, Eugene Shykiriavyi

Where to Take Your UX Career?

Vitaly Friedman — Thu, 20 Jul 2023 00:00:00 +0000

An example of anin-house ladder, ranging from junior designer to design director. From 10 Directions To Take Your Next Career.

There is no universal career path that works for everyone. In fact, the best path is the one that feels right to you. But there are some things to consider when choosing any of these paths. In “10 Directions to Take Your UX Career”, Shannon Groom highlights some of them, with pros and cons of each.

Here’s a quick summary with my notes and remarks:

1. Moving To a Big-Name Company #

If you’re thinking about moving to a larger company or organization, typically it’s a quite safe bet. Large companies are stable and predictable. Decent salaries. Good work-life balance. Established career ladders and processes.

Most importantly, you learn a lot from smart people around you. The environment might be very competitive and it will keep you on your toes. That’s how you grow and make valuable connections. With it, however, often comes the lack of ownership. You might be working on something that will never see the light of day — and over time it can get very frustrating.

Going from junior to senior doesn’t take very long, and once you get there within a few years, you might feel like you are hitting the ceiling. It often feels like your only way up from there is through the management track.

2. Moving Into Management #

As a design manager, you won’t be doing much design work. Better salary. Busy schedule. Meetings, planning, reporting. The most rewarding part is planting new seeds and seeing them grow to incredible heights.

Management is not for everyone, but if you want to make an impact, that’s the strategy to choose. You will have to find allies to grow UX maturity and fight for resources for your team. Of course you can always move back to design but then your options for growth in the same company are limited.

3. Moving To a Start-Up #

When time is of essence and money in short supply, corners are cut. In a start-up you’ll probably do everything, from user research and design to prototyping and user testing (if at all) — and often as the only designer on the team. You have the freedom to quickly iterate and make decisions, but often no senior designers to learn from.

With it comes quite a bit of chaos, plenty of back-and-forths and last-minute changes. You learn how businesses fail and succeed. It’s a good choice in the beginning of your career, but probably not when you are looking for stability and work-life balance.

4. Moving to an Agency #

The main benefit of working in an agency is that you learn from different industries and knowledge domains. You make incredible connections. You learn how to deliver on time, become more pragmatic and learn how to make tough compromises.

You also work longer hours as you manage demanding and important clients. You get a grip of how to jump into any project of any scale, and how to navigate everything from B2C-products to complex B2B-enterprises. That’s challenging and it will always keep you on your toes. Just make sure to not get flooded by customer requests and a wave of approaching deadlines.

5. Moving Into a Product Team #

In a product team, you learn to work with product owners and business analysts. You better understand the business side of things. You’ll spend time connecting design activities with OKRs and business objectives.

You learn the language of business, and how to translate it to the language of design. You can also grow into product management and own the product. This means that you move away from Figma mock-ups into Keynote or PowerPoint presentations and meetings with stakeholders and business owners.

6. Going Freelance #

Autonomy comes at a cost. As a freelancer, you need to be visible and invest in your own brand. You need a good network and good negotiation skills. You learn how to properly estimate, scope, find clients, run accounting and optimize expenses.

Self-discipline is critical as otherwise you’ll work day and night in a never-ending revisions hell.

7. Role Hopping #

Sometimes all you need is just a new challenge. This doesn’t necessarily mean quitting your job and move to another company. Talk to other teams in your company or organization, send them a message and find out what they work on. Chances are high that there are innovation teams that would desperately need you on their side.

Alternatively, explore entirely different industries and domains. Specialize in your strengths, but also broaden your skillset. Move into UX research or DesignOps. Find where your passion is and give it a try.

8. Become an Industry Expert #

Consultancy can be lucrative, but your work will often get lost somewhere — between other priorities, important milestones and abandoned projects. You’ll rarely know about the impact of your work, unless you spend at least a few months on a project.

Once you’ve gathered enough experience in the industry and established yourself as a reliable partner and a trustworthy expert, you can feel more comfortable in creating your own company, agency, product or leading an already existing company.

Further Resources #

How Design Generally Works at Tech Companies by Yamilah Atallah,
Career Ladders: A Guide to Becoming a Senior Product Designer, by Aaron James,
UX Spectrum of UX Career Ladders, by Jason Mesut,
The Four Phases of a Design Career, by Garron Engstrom,
What It’s Like Designing at Start-Ups, by Melody Koh

Six Ways To Speed Up Navigation

Vitaly Friedman — Tue, 18 Jul 2023 00:00:00 +0000

In some interfaces, navigation feels extremely slow and frustrating. Users seem to be running in circles, heading through multiple pages, sections and sub-sites, being re-routed and redirected multiple times — often without a clear path forward.

How can we boost the speed of navigation, so users can move from one page to another more predictably, more reliably and more confidently? With smart breadcrumbs, navigation queries, and navigation billboards. Let’s find out how to do just that!

Every usability study reveals the same story: hiding important navigation is harmful, especially on pages where people tend to navigate a lot. On such pages, go an extra mile trying to always display important actions as cards or large buttons.

More important sections would be displayed at the top of the screen and take significantly more space — similar to a billboard.

The billboard pattern in use: Koreapost.go.kr and Sparkasse.de.

Alternatively, scatter the navigation across the logo in the header, or dedicate an entire bar to display important navigation items. If you don’t have a lot of navigation, this might work well.

No need for hamburger icons. Display important navigation all the time: Moma.org and Typography.com.

Further reading: Never Hide Critical Navigation on Mobile

2. Breadcrumbs Dropdowns #

Breadcrumbs seem to be quite obvious at first. As users move from one page to the next, they leave traces of navigation, and can use them to return to where they are coming from. In practice, however, breadcrumbs indicate where the page lives, not where the user has been — in fact, they rarely match user’s journey.

Typically big jumps on a site require a mega-menu or search, but we could support more granular jumps by turning every crumb into a dropdown of its own. Users can then navigate between siblings of the current page or all children of its parent page without leaving the actual page. That’s how SBB does it.

Extended breadcrumbs with drop-downs, allowing users to navigate sideways — all the way to the homepage. Example: SBB.

If you don’t have space to display a large sidebar navigation on your site, this approach can help as well. And it translate well to mobile as well — in pretty much the same way. Note: you need to display full path from the homepage as otherwise top level navigation wouldn’t be accessible.

Further reading: Designing Better Breadcrumbs UX

3. Skip Search Results Pages #

We’ve got accustomed to the idea of driving users to search results pages — pages with a huge list of links to choose from. But sometimes it’s absolutely unnecessary, and users could benefit from more refined jumps instead.

City of Amsterdam allows users to skip keyword search.

The website of the City of Amsterdam allow users to skip search results pages with smart autocomplete suggestions. Instead, users can jump straight to relevant pages or categories or even sub-categories. A good old-fashioned keyword search is supported as well

Further reading: Five Simple Steps For Better Autocomplete UX

We can help users construct just the right navigation path for their intent. We could show options to choose from and based on one answer, provide further options, all the way to the point where we bring a user to the page of interest.

Users could jump straight from the homepage to a relevant selection of items, with filters applied. Navigation shortcuts on AO.de (now offline).

The pattern on AO.de has been providing a shortcut for users to jump from the homepage to a specific selection of relevant products with filters applied. Once an option is selected, another drop-down appears, allowing them to specify their intent even further.

This experience mimics the drill-down navigation with multiple levels. Yet the difference is that users are making small decisions, one after another, without being confronted with the entire navigation at every step of the way.

5. A-Z Index Overlay #

One way to address complex navigation issues is by using an A-Z Index pattern. We identify the top tasks that users perform on the site. For each task, we define a set of keywords that they associate the task with. We run tree testing to ensure that they can find the pages that they are looking for. And then we show the A-Z catalog of keywords in a menu.

Visitors can quickly jump from any page to any other page on the Aarhus University website.

Aarhus University highlights the A-Z index as part of the global navigation. Visitors choose their role first, then choose a letter, and then explore the overview of all options, jumping to a specific department or faculty. The pattern requires rigorous curation and testing, but it can be remarkably fast!

Most importantly, visitors can quickly jump from any page to any other page. In this case, A-Z index is permanently accessible in the header of each page. That’s not something other navigation patterns provide out of the box.

Wrapping Up #

The patterns above might help you speed up user journeys, but they don’t guarantee successful outcomes. Before exploring design patterns, we always need to spend time refining and testing navigation labels. We also need to indicate where users have been and where they can go next.

And of course, speed isn’t everything. But if we can avoid slowdowns and bring users to success moments faster, we should do so. And hopefully the design patterns above can help us do just that.

You can find more details on navigation UX in the video library on Smart Interface Design Patterns 🍣 — with a live UX training that’s coming up later this year.

How To Design For Users With Dyslexia

Vitaly Friedman — Mon, 17 Jul 2023 00:00:00 +0000

Dyslexia can take different shapes. Different people are in a different place on a continuum, but for some dyslexic users reading might take longer, especially if text has many large uninterrupted blocks, italics, words written in uppercase and flashing images.

It’s difficult to give general advice when it comes to dyslexia, but here are some key points that are quite helpful — along with further resources, articles and toolkits.

Things To Keep In Mind #

For some users, reading can take up to 3× as long.
Some users might confuse b, p, d and n, u and m, w.
Remembering words between screens might be difficult.
Users are heavily distracted by flashing images/sounds.
Difficulty to read analog clocks, directions, numbers.

Designing for users with dyslexia (PDF), an accessibility poster by Gov.uk.

Things To Avoid #

Avoid dynamic, moving or flashing images.
Avoid heavy underlines, uppercase and italics.
Don’t force users to remember; give reminders instead.
Avoid text justification and align text to the left.
Avoid long columns for reading (use 45–65 chars per line).

Things To Do #

Support accurate spelling with autocomplete.
Let users change the contrast between background/text.
Simple sans-serif fonts with generous spacing work well.
Use dark grey instead of black, and soft colors instead of white.
Consider text-to-speech, Bionic reading and dark mode.

Better For Everyone #

It goes without saying that the design guidelines above are general pillars of good design. They are better for everyone — and they help us design digital experiences that are more reliable and usable, and make it much more difficult to make mistakes.

Ultimately, our job is to help people get where they want to be, without segways or retours along the way. Most of the time it means two simple things: maximize clarity, minimize distractions. It works for everyone — and creates helpful and respectful designs that people appreciate and use.

Useful Resources #

Neurodiversity Design System
Dyslexia Style Guide 2023 (PDF)
Dyslexia-Friendly Style Guide
Design Guide For Dyslexia
Designing With Dyslexia, by Alex Morris
Dyslexia Accessibility Guidelines, by Eva Katharina Wolf
Design For Dyslexic Users, by Pradipto Chakrabarty
Design for Customers With Dyslexia, by Kate Hughes
What Makes a Typeface Accessible, by Gareth Ford Williams
How to Involve Dyslexic Users Into Your Design
How to Write With a Dyslexic Audience in Mind, by Trisha Dunbar
GOV.UK Accessibility Posters

How To Write a Great Design Case Study

Vitaly Friedman — Sat, 15 Jul 2023 00:00:00 +0000

How do we write a great design case study? I’ve put together some practical guides, examples and do’s and don’ts on how to stand out.

Key Takeaways #

Think of a case study like a magazine feature.
Keep a case study digestible, thorough and a story.
Choose a customer that represents your scope of work.
Promote the skills that you want to be hired for.
Focus on insights rather than process.
Show your intention and your values.
Use the language that your future clients will understand.
Teach readers something they don’t already know.

A fantastic example: Creating Slack's illustrations, neatly put together by Alice Lee.

I absolutely love diving into case studies that highlight wrong assumptions and failures, explaining how designers managed to turn the ship towards a better outcome. It’s a wonderful way to understand how a designer thinks, and that how they learn and adapt along the way.

Don’t be afraid to show your mistakes, and tell honest stories that your prospect clients can connect to. Probably the worst thing you could do is to create a polished, soulless, marketing version of your work that is too perfect to be true.

Authenticity and enthusiasm always shine through. Don’t hide them, and people will notice how incredible you are.

Design Case Study Examples and Guides #

A Complete Guide To Case Study Design, by Fabricio Teixeira, Caio Braga
Creating Slack's illustration voice, by Alice Lee
Reimagine the future of TV, by Abdus Salam
Designing Urban Walks, by Anton Repponen
Case Study Club, a curated hub by Jan Haaland
A Guide To Case Studies for Designers, by Jenny Kowalski
How to Write Project Case Studies For Your Portfolio, by Tobias van Schneider
Tips to Structuring Case Studies, by Lillian Xiao
How to Write Great UX Case Studies, by Yu Siang Teo
How To Write A Case Study For Your Design Portfolio
How To Write Trust-Building Case Studies (+ Templates), by Elise Dopson
The Ultimate Guide to Writing a Good Case Study
How to Create Case Studies Without Any Past Projects

Five Tips To Boost UX Maturity In Your Company

Vitaly Friedman — Tue, 11 Jul 2023 00:00:00 +0000

Do your design initiatives clash against the company culture? Do you struggle to boost the role of UX in your organization? If you also struggle to convince your colleagues or stakeholders about the impact of UX, the action points below might help.

We’ll also dive into the ins and outs of design KPIs, design impact, design metrics and getting a buy-in in our upcoming live UX training (2× a year), with a well-deserved UX certification!

1. Study Org Charts and Understand Your PMs #

Org charts are very underrated, and extremely useful. They indicate relationships that we, as designers, need to be aware of when making design decisions. Design efforts have tremendous impact, but often they aren’t obvious to the entire organization. A part of our job is to make that impact visible.

An org chart is always a good starting point to understand relationships in the company and explore business goals of each department. (Image source)

When I look at an org chart, I see people who have plenty of priorities, commitments, goals and KPIs — and design is usually not one of them. Meticulously study what your stakeholders care about. Understand your PM. Explain design decisions through the lens of what they care about, and what will help them succeed.

2. Connect Business KPIs and Design KPIs #

Often design has a very good ROI. Developing new features is remarkably expensive, but addressing user’s pain points can be relatively quick and inexpensive — once we’ve learned through UX research what users’ pain points are, of course. Not many companies fully understand it.

An example of a design KPI tree that connects business goals and design activities while addressing user needs. (Large preview)

To argue about the impact of design work, we need to measure the impact of design on business KPIs. A good way of doing that is to establish and get a sign-off on a design KPI tree. The tree documents connections between business goals and design work. For design efforts to be successful, they must be seen as enablers for these business objectives.

3. Create Weekly Overlaps Between Designers and Developers #

Too often designers and developers work in silos; they communicate ad-hoc and mostly during hand-offs. We run weekly “show-and-tell” meetings (20 mins) for dev/design teams to screen share what they are working on, ask for feedback, gather and document insights.

Objectives often change, processes are ad-hoc and design lives somewhere in-between. By John Cutler.

4. Establish Exposure Hours With Users #

Many organization struggle with a product gap: the people who evolve the product often miss the connection with the customers, their pain points and their needs. To reduce that gap, we need to create overlaps between creators of the product and customers.

We try to announce usability tests ahead of time to all teams. Everyone can jump into a Zoom call to observe a test live. The insights are circulated in an internal newsletter, with video snippets and key takeaways. Ideally, 2h exposure every 6h weeks for everyone is a good aim to target for.

5. Reserve 20% For Quality Improvements #

Many teams endlessly run behind schedules. Their sprints are packed with tickets at 100% of their time and there isn't any time left to review their workflows. As a result, the product accumulates technical debt and design debt — and this doesn’t come for free.

Slowdowns are expensive. The industry approach is to reserve 80% for ongoing tasks, 20% for quality improvement and design/tech debt. Find an opportunity to run a workflow revision or a retrospective as a way to reduce "slacking" costs and improve efficiency. It also brings the notion of quality into conversations, which PMs typically aim for.

Wrapping Up #

Changes are slow in large companies, and introducing them is often an exercise of patience and stubborness. But once the wheel is moving, you might activate other wheels — and most importantly find people who care about your work across the organization.

With them on your side, next changes will be much easier to prompt and get a buy-in for. It’s difficult and time-consuming, but if you work in a good company with good people, it will be very much worth it.

Useful Resources #

Feature Prioritization Guide (free eBook), by Roadmunk,
Measuring UX Research Impact, by Karin den Bouwmeester,
Navigating The UX Team of One, by Jamie Ryan,
The UX Team of One: A Research and Design Survival Guide, by Leah Buley,
Articulating Design Decisions, by Tom Greever,
Building KPI Trees, by Shaun Russell.

30 UX Interview Questions To Ask In a Job Interview

Vitaly Friedman — Sat, 08 Jul 2023 00:00:00 +0000

When talking about job interviews for a UX position, we often discuss how to leave a good impression and how to negotiate the right salary. But it’s only one part of the story. The other part is to ask questions and to listen carefully — to discover red flags early, and figure out if a company is a good fit for you.

Best interviews include questions from both sides. A wonderful illustration by José Torre.

Most importantly, it’s a good idea to ask yourself what exactly you need to know about the company to make an informed decision if you actually want to work there.

Useful UX Interview Questions To Ask #

In her recent article, Nati Asher has suggested many useful questions to ask in a job interview — when you are applying as a UX candidate. I’ve taken the liberty to revise some of them, and added a few more questions that might be worth considering for your next job interview.

What are the biggest challenges the team faces at the moment?
What are the team’s main strengths and weaknesses?
What are the traits and skills that will make me successful in this position?
Where is the company going in the next 5 years?
What are the achievements I should aim for over the first 90 days?
What would make you think “I’m so happy we hired X!”?
Do you have any doubts or concerns regarding my fit to this position?
Does the team have any budget for education, research etc.?
What is the process of onboarding in the team?
Who is in the team and how long are they in that team?
Who are the main stakeholders I will work with on a day-to-day basis?
Which options do you have for user research and accessing users or data?
Are there analytics, recordings or other data sources to review?
How do you measure the impact of design work in your company?
To what extent does management understand the ROI of good UX?
How does UX contribute strategically to the company’s success?
Who has the final say on design, and who decides what gets shipped?
What part of the design process does the team spend most time on?
How many projects do designers work on simultaneously?
How has the organization overcome challenges with remote work?
Do we have a design system, and in what state is it currently?
Why does a company want to hire a UX designer?
How would you describe the ideal candidate for this position?
What does a career path look like for this role?
How will my performance be evaluated in this role?
How long do projects take to launch? Can you give me some examples?
What are the most immediate projects that need to be addressed?
How do you see the design team growing in the future?
What traits makes someone successful in this team?
What’s the most challenging part of leading the design team?
How does the company ensure it’s upholding its values?
What is the one thing in your company that you would change if you could?
What is the one thing one should never do in the team?

Before a job interview, choose a few relevant questions and have them ready. Not only will they convey a message that you care about the process and the culture, but also that you understand what is required to be successful. And this fine detail might go a long way.

Useful Resources #

What’s The Perfect Design Process?

Vitaly Friedman — Sat, 17 Jun 2023 00:00:00 +0000

Design process is messy. You might be following a structured approach, but with all the last-minute changes and overlooked details, too often it takes a life of its own. And before you know it, you are designing in a chaotic environment, full of refinements, final-final-deliverables and missed deadlines.

What’s The “Right” Design Process? #

Of course there is no “right-and-only” way to frame a design process. It’s defined by whatever works well for you and for your team. Personally, I tend to rely on 4 design models that seem to fit well with my design work:

Double Diamond Process for its comprehensive and reliable methodology for solving problems. In this guide, Dan Nessler breaks down the entire Double-Diamond process into single parts, explaining how exactly it works, step-by-step, in all fine details.

The classic. The Double-Diamond process revamped for messy reality. A helpful guide by Dan Nessler.

Triple Diamond Process for its more realistic approach to designer’s input across the product’s life cycle. That's a piece by Adam Gray on why bringing flexibility for the messy reality of the design process is critical to improve planning and involve design work as prototypes are being built.

Extending Double Diamond with an extra Diamond to bring more focus into experimentation and refinement. From Triple Diamond Process, a guide by Adam Gray.

Enterprise Design Thinking Model by IBM for its focus on design maturity and scale, which really helps with large organizations. A useful model that helps argue for user research, user-centricity and rapid low-fidelity prototyping — and how to transfer ownership to design teams at scale.

A helpful model for complex projects and enterprise world: Enterprise Design Thinking Model by IBM.

Hot Potato process, for its simplicity in bridging design and development across the entire product lifecycle. Designers and developers throw ideas and mock-ups and prototypes to each other permanently. Sometimes there are more involved design phases than dev phases, but there is no hand-off, and the entire process is driven by continuous collaboration.

A collaborative approach for designers and developers, focused on throwing ideas back and forth: the Hot Potato process by Dan Mall.

These ways of thinking about design process translated into a process that works well for me, but has to be adjusted for every project that I'm working on. In a nutshell, here's how it would work.

A Process That Works For Me #

There is no such thing as enough user research. In every project, I start with involving users as early as possible. I explore all the data we have, interview customer support and service desk, check for technical debt and design issues, backlog items and dismissed ideas. I explore organizational chart to understand layers of management. I set the right expectations and seek allies.

From there, I would typically spend weeks or even months in diagrams and spreadsheets and endless docs before drawing a single pixel on the screen. I try to get developers on board, so they can start setting up the dev environment already.

I bring in stakeholders and people who have vested interest to contribute to the success of the project. Voices that need to be heard, but are often forgotten. I see my role as a person who needs to bridge the gap between business requirements and user needs through the lens of design.

Then I take a blank piece of paper and start sketching. I sketch ideas. I sketch customer journey maps. I sketch content boxes. I write down components that we will surely need in the product — the usual suspects. I set up a workshop with designers and developers to decide on names. Then developers can go ahead and prototype while designers focus on UI and interaction design.

To make sure I get both sides of the equation right, I draft customer journey maps, brainstorm ideas and prioritize them with the Kano model and Impact ÷ Effort matrix (with developers, PMs and stakeholders).

An example of a Design KPI tree, connecting business goals with design objectives.

I don't want to waste time designing and building the wrong thing, so I establish design KPIs and connect them with business goals using KPI trees. I get a sign-off on those, and then interface design starts.

I develop hypotheses. Low-fidelity mock-ups. Speak to developers. Get their feedback. Refine. Throw the mock-ups to developers. Bring them into HTML and CSS. Test hypotheses in usability sessions until we get to 80% success rate for top tasks. Designers keep refining, developers keep building out.

Establish a process to continuously measure the quality of design. Track task completions rates. Track task completion times. Track error rates. Track error recovery rates. Track accessibility. Track sustainability. Track performance. In a B2B setting, we track the time customers need to complete their tasks, and try to minimize it.

Make them visible to the entire organization to show the value of design, and its impact on business KPIs. Explain that the process isn't based on hunches. It's an evidence-driven design.

Establish ownership and governance. Search team must be measured by the quality of search results for top 100 search queries over the last 2 months. People who publish content are owners of that content. It's their responsibility to keep it up-to-date, rewrite, archive or delete.

Refine, refine, refine. Keep throwing new components and user journeys to developers. Stop. Test with users to check how we are doing. Keep going and refine in the browser. Continuously and rigorously test. Launch and keep refining. Measure the KPIs and report into the next iteration of the design.

Admittedly, it is a bit messy. But it helps me stay on track when navigating a complex problem space in a way that delivers measurable results, removes bias and subjectivity from design decisions and helps deliver user-centric designs that also address business needs.

Wrapping Up #

Of course there is no “right-and-only” way to frame a design process. It’s defined by whatever works well for you and for your team. Explore options and keep them in mind when designing your design process. Whatever you choose, don’t follow it rigidly just for the sake of it, and combine bits from all models to make it right for you.

As long as it works well for you, it’s right. And that’s the only thing that matters.

Designing Sticky Menus: UX Guidelines

Vitaly Friedman — Sun, 07 May 2023 00:00:00 +0000

We often rely on sticky headers to point user's attention to critical features or calls to action. Think of sidebar navigation, CTAs, sticky headers and footers, “fixed” rows or columns in tables and floating buttons. We've already looked into mobile navigation patterns in Smart Interface Design Patterns, but sticky menus deserve a closer look.

As users scroll, a sticky menu always stays in sight — and typically it's considered to be a good feature, especially if the menus are frequently used and especially if we want to speed up navigation.

Multiple sticky menus in use: Sverigesradio with a bottom sticky navigation, and TV Gids, with multiple chained sticky menus on the top.

However, sticky menus also come with a few disadvantages. In his recent article on Sticky Menus Are Problematic, And What To Do Instead, Adam Silver argues about some common usability issues of sticky menus — and how to solve them. Let’s take a closer look.

When Sticky Menus Are Useful #

How do we decide if a menu should be sticky or not? This depends on the primary job of a page. If it's designed to primarily convey information and we don't expect a lot of navigation, then sticky menus aren't very helpful.

A helpful sticky bar for navigation through channels on France TV.

However, if we expect users to navigate between different views on a page a lot, and stay on the page while doing so — as it often is on long landing pages, product pages and filters — then having access to navigation, A-Z or tabs can be very helpful.

Also, when users compare features in a data table, sticky headers help them verify that they always look at the right piece of data. That's where sticky headers or columns can help and aid understanding. That's why sticky bars are so frequently used in eCommerce, and in my experience, they improve discoverability of content and speed of interaction.

Keep Sticky Headers Small, But Large Enough To Avoid Rage Taps #

The downside of sticky menus is that they typically make it more difficult for users to explore the page as they obscure content. Full width bars on mobile and desktop are common, but they need to be compact, especially on narrow screens — and they need to accommodate for accessible tap sizes to prevent rage taps and rage clicks.

Postal Service from Iceland with 4 items in the sticky bar navigation (now changed).

Typically that means that we can't have more than 5 items in the sticky bar navigation. The choice of the items displayed in the sticky menu should be informed by the most important tasks that users need to perform on the website. If you have more than 5 items, you probably might need to look into some sort of an overflow menu, as displayed by Samsung.

Sometimes sticky menus are used for in-page navigation: a sticky overflow menu at Samsung.

Whenever users have to deal with forms on a page on mobile, consider replacing sticky menus with accordions. Virtual keyboards typically take up to 60% of the screen, and with a sticky bar in a view, filling in a form quickly becomes nothing short of impossible.

Accessibility Issues of Sticky Menus #

By their nature, sticky menus always live on top of the content, and often cause accessibility issues. They break when users zoom in. They often block the content for keyboard users who tab through the content. They obscure links and other focusable elements. And, there is often not enough contrast between the menu and the content area.

Poor contrast between the sticky sub-menu-navigation and the content area can cause accessibility issues. Discovered via NN/Group.

Whenever we implement a sticky menu, we need to make sure that focusable elements are still visible with a sticky menu in action — and this also goes for internal page anchors that need to account for the sticky bar with the scroll-padding property in CSS.

Avoid Multiple Scrollbars Of Long Sticky Menus #

When sticky menus become lengthy, last items on the list become difficult to access. We could make them visible with some sort of an overflow menu, but often they appear as scrollable panes, causing multiple scroll bars.

Australian Bureau of Statistics, with a large sticky sidebar navigation that causes a scroll.

Not only does this behaviour cause discoverability issues, it's often a cause for mistakes and repetitive actions on a page. Ideally, we would prevent it by keeping the number of items short, but often it’s not possible, or can’t be managed properly.

No sticky menu in sight: instead, we could show and hide cart details when needed. On Smashing Magazine.

A way out is to show the menu as an accordion instead in situations when the space is limited, especially on mobile devices. That's what we do at Smashing Magazine in the checkout, with a button that reveals and hides the contents of the cart when needed.

Partially Persistent Menus #

Because sticky menus often take too much space, we could reveal them when needed, and hide them when a user is focused on the content. That's the idea behind partially persistent headers: as a user starts scrolling down, the menu disappears, but then any scrolling up prompts the menu to appear again.

A partially persistent sticky menu on CB2 that disappears on scroll down and reappears on scroll up.

The issue with this pattern is that sometimes users just want to jump back to a previous section of the page, or want to double check some details in a previous paragraph, and the menu often gets in the way. Page Laubheimer from NN/Group recommends to use a slide-in animation that is roughly 300–400ms long will preserve the natural feel, without being distracting.

Alternatives To Sticky Menus #

In some situations, we might not need a sticky menu after all. We can avoid their downsides with shorter pages, or lengthy pages which repeat relevant calls-to-actions or navigation within the page.

Alternatives to sticky menus: a table of contents displayed on UK Government and New Zealand Government.

We could display a table of contents on the top of the page, and bring user's attention to table of contents with a back-to-top link at the bottom of the page.

Wrapping Up #

Whenever a job of the page is to help users act, save, compare, or we expect users to rely on navigation a lot, we might consider displaying sticky navigation. They are most harmful when there isn't enough space anyway, as it often is with forms on mobile devices.

Sticky menus do come at a cost as we need to account for usability and accessibility issues, especially for zooming, keyboard navigation and anchor jumps. Add them if you need them, but be careful in plugging them in by default.

We need to prioritize what matters and remove what doesn't: and too often, the focus should lie entirely on content, and not navigation.

Further Resources #

Of course, the techniques listed above barely scratch the surface. Here are wonderful articles around sticky headers, from design considerations to technical implementations:

The Problem With Sticky Menus, and What To Do Instead, by Adam Silver,
Sticky Headers: 5 Ways to Make Them Better, by Page Laubheimer,
A different approach to sticky in-page navigation, by Corey Snyder.

Mobile Accessibility Target Sizes Cheatsheet

Vitaly Friedman — Thu, 20 Apr 2023 00:00:00 +0000

Rage taps are annoying and frustrating. These wonderful occurrences in our interface when we need to tap twice, or sometimes three times to continue our journeys. Of course sometimes they happen because the website is too slow, but sometimes it’s the target size of interactive elements that is the culprit.

Rage Taps, a Metric for User Frustration, by Colin Contreary

So how big should our interactive elements be these days? What would be a reliable size for icons, links and buttons — in navigation and on mobile? How do we make it more difficult for our users to make mistakes? Let’s take a look.

Target Sizes Cheatsheet #

One of the common recommendations for target sizes on mobile is 44×44px. This is a little bit misleading because screen pixels, or at least device-independent pixels (dips) are scaled to a multiple of the display resolution. So pixels are different on different screens, and when we have a conversation about sizes, we probably should be speaking about dips, rather than pixels.

Target Sizes Cheatsheet, researched and designed by Steven Hoober. Large view.

Depending on where an element appears on the screen, it needs more or less padding. In general, we are very precise in our input in the center of the screen, but we are least precise on the edges of the screen (both on the top and at the bottom).

According to Steven Hoober’s research in his book on Touch Design For Mobile Interfaces, to minimize rage taps we need to aim for 11mm (or 31pt / 42px) on the top of the screen, and 12mm (or 34pt / 46px) at the bottom of the screen. In the center though, we could potentially go as low as 7mm (or 20pt / 27px). This includes both the width and padding of an interactive element.

How do point units translate to CSS pixels or Android/iOS units? Fortunately, Steven Hoober provides a helpful conversion table to help you translate from points to px and em units, Android SPs or DPs, iOS points and Windows DIP or px.

Not All Pixels Are The Same #

As we’ve seen above, target sizes change depending on where components appear on the screen. It’s worth noting that according to the WCAG 2.1 AAA level requirements, all targets should measure at least 44 by 44px, except if the target is in a sentence or block of text. For such exceptions, we could be using 27px as a goal, but in general, the larger, the better.

Bottom Sheet Bar navigation might work better if you need to display more than 5 items at the bottom of a mobile screen.

For sticky menus at the top or bottom of the screen, we should probably aim for around 44–46px boxes, or preferably even more. However, for links that appear on the screen as user scroll down the page, we probably will be able to avoid most issues with smaller components.

Frans Hals Museum and Danish Public Transport websites with 5 items appearing in the bottom menu.

This is also why we probably will be able to place at most 5 items in the bottom tabs on a mobile phone. Instead, we might need to use a bottom sheet that would slide up from down as an overlay on top of the screen.

Prefer “Actions” Button To Single Icons For Data Tables #

Complex tables typically have hover actions that appear once a user starts hovering over a particular row. They typically include everything from highlight and export to move and delete.

In testing, showing icons on hover produces too many mistakes: not only do users often accidentally jump to a wrong row as they navigate horizontally towards the icons. They also make mistakes by accidentally clicking on the wrong spot and starting all over again.

Table view hover for the Liferay design system. Source.

To avoid rage clicks, it might be a good idea to test how well an “Actions” buttons or a “Split”-Button would perform instead. Indeed, that button could live on every row, would open on tap/click and wouldn’t close automatically. It might not be ideal for every use case, but it definitely gives users more sense of control as they need to take an action on a row.

No hover icons in sight; instead, the interface uses an 'Actions' button that shows options in an overlay. Large view.

A split-button typically produces fewer rage clicks/taps than small hover action icons.

Provide An Assistant For Complex Manipulations #

With a complex manipulation such as rotation of an image, or selection of a small part of a larger area, we often rely on pinch and zoom, or zoom in/out buttons. These options of course work, but they easily become a bit tedious to use for very precise manipulations — especially if used for a while.

Assistant pattern allows users to navigate an object with a little handle on the right. Example: Tylko.

Instead, we can attach a little handle to allow users to move their selection within the object faster, and with more precision. This is how Tylko allows users to customize their shelves on mobile. Zooming is supported as well, but it’s not necessary to select one of the areas.

When Multiple Taps Are Better Than One #

But what do we do if some tap areas have to be small? Perhaps we can’t reserve 27×27px for each icon — for example, when we suggest a color selection in an eCommerce site? Well, in that case one option to consider would be to prompt a “proper” selection of colors with one additional tap. This might be a bit slower in interaction, but way more accurate.

Fewer rage clicks: Grønland Color Picker Microinteraction, designed by Mykolas Puodžiūnas.

Always Maximize Clickable Area #

Whenever possible, encapsulate the entire element, along with enough padding to ensure that you hit the magical 42–46px size to prevent rage taps for good. This typically means adding enough padding for icons but also preferring full-width or full-height bars for accordions and navigation.

Navigation bars should ideally be full-width, so there is no need to focus specifically on the link area.

Always add enough padding to make it easier to tap an element. Again, we are aiming for interactive area of at least 44px radius for every interactive element.

Ahmad Shadeed presents a few useful examples of using spacing to increase clickable areas and prevent rage clicks. Any Lupe provides even more suggestions in her article on accessible target sizes.

Wrapping Up #

When designing for touch today, we need to use at least 27×27px for small links or icons in the content area, and at least 44×44px for icons at the top and at the bottom of the page.

Padding is always helpful for any kind of input: be it stylus, pointer or a finger. From Accessible Target Sizes, by Amy Lupe

Personally, I would always go up to 30×30px and 48×48px to make sure mistakes are really difficult to make. And of course, always use full width or full height for the clickable areas. Hopefully this will help us remove rage taps from our websites altogether — and many of your users would sincerely appreciate it.

Useful Resources #

There are a few wonderful resources on accessible target sizes that might be helpful if you’d like to dive deeper in the topic:

Accessible Target Sizes, by Amy Lupe
Touch Targets on Touchscreens, by Aurora Hailey
Enhancing the Clickable Area, by Ahmad Shadeed
WCAG 2.55 for Better Target Sizes, by Todd Libby
Fitt’s Law In The Touch Era, by Steven Hoober
Touch Design For Mobile Interfaces, by Steven Hoober
Type Sizes for Every Device, by Steven Hoober

Drag-and-Drop UX: Guidelines and Best Practices

Vitaly Friedman — Wed, 12 Apr 2023 00:00:00 +0000

Drag-and-drop is not a trivial user interaction. It’s messy, inaccurate and comes in plenty of flavors — from design states to interaction modes. Yet when we think of drag-and-drop, we typically think of a simple drag’n’drop file upload — which is only one of the many contexts where drag-and-drop appears.

Drag-and-drop requires cursor changes and a “ghost” image of the component. From Drag and Drop for Design Systems by Grace Noh.

Yet every time we need to re-order a list, or move around cards, or reshuffle columns in a fancy enterprise table, we’ll probably be dealing with drag-and-drop interactions. And too often, they will feel too sluggish, too difficult to use and absolutely inaccessible. Let’s fix it.

You can find more details on navigation and interaction design in usability chapters in the video library, with a new UX training coming in September 2023.

1. Drag-And-Drop Should Resemble Physical Movements #

It’s not surprising that many users expect drag-and-drop to feel very much like the offline experience of moving physical objects from one place to another. With it come expectations around everything from lifting an item and moving it to spotting available “drop zone” and eventually dropping an item there.

In fact, there are plenty of states to consider:

states for components: resting, lifted/grabbed, in transit, dropped, erroneous and successful.
states for the drop zone: empty, hidden, revealed, disabled, ready and contentful.
other states: changes in drag handle and grab cursor, but also adjustments of drop shadows and drop targets.

Each of these states must be designed with affordance in mind, and provide instant feedback for the changes made — whether they are possible or not.

2. Use The Right Cursors and Grab Handles #

If a UI component doesn’t provide any clues about its support of drag-and-drop, we shouldn’t really expect users to discover it on their own. This is similar to right-click interactions which, without any clues, often have a very low discovery rate. With drag-and-drop, the cursor should change on hover to indicate that tapping or clicking will initiate a grab.

Cursors we can use to indicate drag-and-drop on Mac and Win. From Drag-and-Drop in Design Systems.

This isn’t enough though. Hover alone assumes that users will discover it on their own, which will not be the case for keyboard users. The component must also be focusable and include a focused state — along with controls to move the component. To be on the safe side, we can clearly indicate for each item that it can be dragged by adding a “grab” or “move” handle on it.

The mouse cursor could change to indicate that an item is being dragged — from the “move” or “grab” cursor (which indicates something can or is to be moved) to the “grabbing” cursor (which indicates that something is being moved).

Usually there is no need to reinvent the cursor and design an entirely new set of drag-and-drop icons.

3. Elevate Lifted Items With Drop-Shadow and Tilting #

Whenever we are moving an item from one place to another, we almost instinctively follow a pattern that we are used to in physical spaces, too. We lift an item, move it, make space for it, drop it to its new spot. Each of these movements is familiar and obvious — and on the web, we can imitate it, too.

In UI terms, that means “lifting up” an item towards a user once it has been grabbed, in the z-dimension. Not only does the item then stand out from the others; the elevation also indicates that the item’s state has now changed. In fact, it could be achieved in a few different ways:

Tilting cards on drag action when moving items in Trello.

Add a drop-shadow to add depth and elevation,
Add an outline around the component,
Slightly tilt the object (Trello pattern displayed above),
Leave a “ghost” image where the component used to be.

Whatever options you choose to use, consider also using indentation with some horizontal and vertical offset, so the item appears quite different from the items that are currently in place. This will help avoid confusion when you need it the least.

4. Collapse Large Items Into Summaries #

And here comes the never-ending question: as the item is being dragged, when do we actually remove it from its original position? This seems like a question with an obvious answer, but there are 5 important considerations which every drag-and-drop experience might need to consider:

Collapse a grabbed item into a summary as it’s being moved. Example: Gmail.

A dragged item should follow user’s movements immediately.
Always leave a ghost image of the component to indicate where it used to be.
As the item is being moved, make sure it stands out from the rest of the list.
For large items, collapse them into a summary of the contents.
Remove the ghost image on drop, but support undo.

Google Drive shows where the folder used to be, what is in transit and highlight an area which would capture it once it’s dropped. No surprises here.

The summary pattern seems to work best when we are moving large columns, rows, files or large chunks of data as otherwise they would pollute the entire screen. For smaller items, such as relatively small cards or list item, we don’t need to collapse into summaries, and can move the item directly across the screen.

5. Reshuffle Items Center-Out #

As items are travelling across the screen, eventually we also need to either “capture” them in a drop zone, or move other content out of the way to make room for them. Usually we change the drop zone to a "ready” state to indicate that it’s ready to capture the dropped content.

With other components, we usually push items out of the way and use a visual indicator to cue the change (with a horizontal line or a temporary empty card). Both give users a preview about where the item will land once it’s dropped.

When to reshuffle items? One option is when one item cross the vertical center of the other one. Source: Norman-Nielsen Group.

The most complex question, however, is when exactly we should start pushing out components to make space for a new one?

Many implementations start moving items out when their edges meet, but it might be a little premature. An alternative option is to move an item out of the way once the center of the dragged component overlaps the edge of the other component — this might be a slightly stronger intent that the user has made up their mind.

6. Use Magnetism To Snap Objects Into Place #

Drag-and-drop is inherently inaccurate, so whenever an item can be comfortably dropped, we might want to make it obvious to users. We could do so with a slightly different outline of a dropzone that the target area is ready for the drop.

Even better if we can animate the drop with a short transition (100ms) into its new home position, so it feels like it snaps an object into place.

A file upload drop zone with a red dotted line indicating where the actual drop zone interaction border is, despite it being invisible to the user. Source: Norman Nielsen Group.

Typically a dotted or dashed area indicate that an item will be safely captured once it’s dropped. Notice how on Dropbox (pictured below), a file is collapsed into a summary, indicating just how many files there are and they type of the file as well.

Large dashed area in blue on Dropbox indicates a dropzone.

7. Allow Users To Undo #

Mistakes are inevitable, and eventually items will end up in wrong places. To help users recover from these mistakes, we might want to support an option to “Undo” the last action and restore the initial position of the item. It could be as simple as an “Undo” button that remains visible until the user moves on to the next operation. It could also be a stack of last changes that users could revert back to.

Drag-and-drop isn’t a trivial interaction, so we can help users recover from mistakes by adding an option to Undo.

8. On Mobile, Use Action Buttons #

Because drag-and-drop is inaccurate, an alternative way to prevent errors or mistakes is by providing an option to select one or multiple items and move them by using a dedicated “Move to” button, as it’s used in some mobile applications (see below). That’s a simple way to make drag-and-drop more accessible in general, but it is extremely useful especially on narrow mobile screens.

GMail uses a “Move to” button on mobile, creating fewer avenues for mistakes. Source: Norman Nielsen Group.

9. Accessible Drag-And-Drop #

There is a common assumption that drag-and-drop can’t be accessible. But there are some implementations that make the interaction fully accessible without a mouse. On mobile, sometimes interface use a subtle haptic “bump” to indicate that an object has been grabbed.

Salesforce’s accessible drag and drop pattern library supports screenreader messages.

Keyboard users need to be able to focus on handle icons and receive screen reader messages about the changes they are about to make, implemented with ARIA live regions. The actual drag-and-drop experience need to be implemented with keyboard keys.

Keyboard users need to be able to focus on handle icons and receive screen reader messages about the changes they are about to make, implemented with ARIA live regions.

The Salesforce implementation allows users to use Tab/Shift+Tab to navigate to an item, press Space to enter into drag mode, then use Down/Right, Up/Left arrow keys to select a new position and then press Space to drop item in new position. For each of them, we also need to design a separate state.

Wrapping Up #

Indeed, drag-and-drop is not a trivial interaction. Hopefully the pointers listed above will help you design slightly better and more accessible drag-and-drop UX without making users confused about just how painful and slow the experience is.

Here’s a quick summary of the pointers mentioned above:

Users should feel like they are moving physical objects.
Design states for components and drop zone areas.
Dragged items should move towards users in the z-dimension.
Animate the drop of an item (100ms) into its new home position.
Add shadows and elevation to make interaction obvious.
Simulate a “magnetic” effect that snaps objects into place.
Reshuffle when a center of a dragged item overlaps an edge.
Collapse large components into summaries during transit.
Keep handle icons accessible and support screen readers.
Support Spacebar to pick up, Arrow keys to move, Space to drop.
Use grab-handle icons and adjust system cursors.
Use a haptic “bump” to indicate grabbing on mobile.

Further Resources #

Of course, the techniques listed above barely scratch the surface. Here are some fantastic resources all around drag-and-drop, from design considerations to technical implementations and ready-to-use libraries:

Drag and Drop UX Best Practices, by Ceara Crawshaw
Drag and Drop UX for Design Systems, by Grace N.
Building a Drag and Drop UI, by Graeme Fulton
Rethinking Drag and Drop, by Alex Reardon
Drag–and–Drop: How to Design for Ease of Use, by Page Laubheimer
Salesforce Drag and Drop Interaction Patterns
Drag and Drop Order UX Pattern, by Glen Lipka
Major Interaction Patterns for Accessible Drag and Drop, by Jesse Hausler
Beautiful Drag And Drop, A React Library

Happy drag-and-dropping, everyone!

The Best Handoff Is No Handoff

Vitaly Friedman — Sat, 01 Apr 2023 00:00:00 +0000

Many companies organize their workflows around projects and departments. Especially in large companies, work often travels from one place to another, often getting stuck between emails and Slack messages, and often “refined” on its never-ending journey between design and engineering teams.

Too often things don’t go as expected. Illustration by José Torre.

This inevitably brings up the question about the design hand-off: that magical moment when designers are done with their work and developer can take over. Most importantly, that’s where designers must stop working, and move on to other work — unless the scope changes or late adjustments creep their way in.

The “No Handoff” Method #

Last week, I stumbled upon an interesting article about the no-handoff method, in which Shamsi Brinn shows an alternative to typical design hand-offs. Shandi shows a fluid model where product and engineering teams work on the product iteratively all the time, with functional prototyping being the central method of working together.

Before and after: the good ol’ Double Diamond on the top, an alternative “no handoff” method on the bottom.

With the process, the working prototype is the living spec of the project and a shared language for the team. No more translation is needed because everyone works on the same prototype. The problem space and the solution space are explored by designers and engineers collaboratively, and the entire workflow is organized around the product, rather than company’s internal structure.

The “Hot Potato” Process #

This reminded me of the Hot Potato Process by Dan Mall and Brad Frost, where ideas are passed quickly back and forth from designer to developer and back to designer then back to developer for the entirety of a product creation cycle — similar to throwing hot potato back and forth (audio, video).

The “Hot Potato” process, with designers and engineers throwing mock-ups and prototypes to each other repeatedly.

From my personal experience, I can only testify that the best collaboration doesn’t have any handoffs between teams. There, work flows seamlessly from design to engineering and back — with both teams working simultaneously, and discussing issues as they occur, during the entire product lifecycle.

There are phases of independent work for sure, but there are also plenty of overlaps for collaborative work, which are opportunities to discuss the progress, explore what is and what isn’t viable and hence avoid lurking issues down the line.

Create As Many Overlaps As Possible #

Of course, the process works well for small product teams. But what if a part of the product is outsourced to an external agency? Many companies choose the route of extensive documentation — almost to the last pixel, along with a brief explaining the strategy and the thinking behind the design.

This isn’t enough though. Design decisions have to be informed by technical implementations and its limitations. There is no universal language around design patterns and their interaction design either. And not every design detail can be implemented in an accessible and performant way. This is why beautiful mock-ups turn into painfully slow and inaccessible monsters.

Engineers could and often should contribute to the design process. Illustration by José Torre.

We can reduce the risks of hand-offs with dedicated overlaps between designers and engineering teams. With regular check-ins. Weekly reviews. Shared channels for communications. Visibility into the work done. Usability testing of functional prototypes and small but regular design revisions.

Design is a team work. It involves everybody who contributes to the website — from customer service and marketing to developers and designers. Any overlaps you can create will benefit the teams, their productivity, and ultimately your users.

Wrapping Up #

So we want to move away from handoffs. But how to convince teams to change their workflow entirely? With a small experiment on a small project. Pick a project where you could test the waters and suggest a collaborative process. Ask what designers could do while developers are busy. Ask what developers could do while designers iterate. And enable both teams to work together, at the same time.

Ultimately, the success depends on one simple thing: just how well the teams work together. And if they can’t collaborate particularly well, chances are high that a design hand-off won’t make it any better, and a major change in the team culture will need to happen first.

You can find more details on design patterns and UX in the video library on Smart Interface Design Patterns — with a live UX training that’s coming up in March 2024.

Sending a lot of optimism, hope and good energy your way! Happy designing, and thank you for reading!

How To Avoid Bias in UX Research

Vitaly Friedman — Wed, 22 Mar 2023 00:00:00 +0000

Recently I stumbled upon the article How To Avoid Bias in UX Research, with pointers on how to anticipate, identify and overcome biases in your research by being more strategic about how you ask questions and how you run the test. A concise write-up by Genís Frigola.

Here are some useful points (with a few additions from my end):

Check your emotions: be boring and neutral.
Talk less, listen and observe instead.
Think carefully about the sequence of questions.
Ask a question, then get out of the way.
Let users follow their own paths.
Never suggest your opinions or views.
Never respond positively or negatively.
Never use leading words and limit guidance.
Watch out for your tone and body language.
You don’t need to fill silences — let them be.
Avoid close-ended questions or opinions.
Repeat what users say and ask if you got it right.
Get enough time to recruit the right people.
Space out the scheduling of interviews.
Ask colleagues to shadow you for second opinions.

Personally, I tend to avoid focus groups as they usually result in a few people taking a lead in the conversation and ultimately guiding other people in their direction, leaving no opportunity for others to make up their mind on their own.

Also, with a wonderful advice by Gerry McGovern, I’ve stopped asking users to walk me through the test as they complete tasks. Instead, I just give them a task and observe them trying to complete it. Whenever issues occur, I ask questions to better understand what the problem actually is.

Further resources

Overcoming Cognitive Bias in User Research, by Adam Kiryk
What To Do About Bias in UX Research, by Lizzy Burnam
Confirmation Bias in UX, by Jennifer Junge
10 Cognitive Biases to Avoid in User Research, by Sundar Subramanian
10 Cognitive Biases Anyone Doing UX Research Should Know, by Nikki Anderson

A huge thanks to everyone kindly contributing to all these resources!

Navigating The UX Team Of One

Vitaly Friedman — Tue, 21 Mar 2023 00:00:00 +0000

Are you the only designer on the team? Navigating The UX Team Of One is a very honest article about the things to keep in mind in the open waters of technology-driven teams. Written by Jamie Ryan.

Document everything, from your work to org charts.
Ask a lot of questions, listen and build credibility.
Make yourself known to every team.
Reach out to key figures from every department.
Find your allies among non-designers.
Find where you add value, and spend your time there.
Protect your work from people telling you how to design.
Understand the language of each department.
Always speak about their goals, not yours.
Always give your points firmly: no soft cloud landings.
Watch out for red flags, and write them down.
You will need other people to carry your design in action.
Make your work visible to other people, and bring them in.
Good design execution is about relationship management.
Protect your time and keep a file with your achievements.

Plenty of actionable recommendations — and I can only emphasize just how important it is to establish good relationships with key people in other organizations, and understand and speak the language of the business. This is how changes happen — in big and small organizations. Safe sailing, everyone! ⛵

Further reading:

The Only Designer
Advice For Young Designers Joining a Start-up As The Only Designer
The UX Team of One: A Research and Design Survival Guide, by Leah Buley
Articulating Design Decisions, by Tom Greever

Red Flags To Check In Your Design Interviews

Vitaly Friedman — Tue, 21 Mar 2023 00:00:00 +0000

Red flags to check in your design interviews. Photo by Carson Masterson.

I’ve recently stumbled upon Red Flags To Check In Your Design Interviews, a quick guide on how to work out if a team is right for you, and what it's going to be like to work in that company, or with that team. A great reminder, kindly put together by Morgane Peng, with a few useful pointers:

Your interviewers aren't all recent hires.
Design decisions aren’t made by managers.
Designers aren’t expected to do non-design tasks.
People seem to feel positive about their colleagues.
There seems to be a proper onboarding process in place.
Design process isn’t stale but evolves over time.

Wonderful points, and I would expand it a little bit to make sure the company has at least some commitment to design and UX, and an inclusive and supportive culture :

The company is public about its values and beliefs.
There is a well-defined design career ladder.
There are regular 1:1-meetings and feedback sessions.
There is a commitment to user research and UX.
The environment seems to be inclusive, diverse and supportive.

Further reading:

Questions to ask your product design interviewers, by Poyi Chen
Questions You Should Ask to Avoid Working for a Toxic UX Manager by Vivianne Castillo
Questions Designers Should Ask Before Joining a New Company, by Catriona Shedd
UX Interview Questions You Should Ask, by Poyi Chen
Questions to Ask When Being Interviewed For a Design Job, by Michael McWatters
Questions to ask in your Head of Design interview, by Martyn Reding
Interviewing Your UX Interviewer, by Jeremy Bird 🇺🇸🇧🇷
Smart Questions to Ask in a Job Interview, by Amy Gallo
Questions to Ask in a Job Interview, by Alison Green

Good luck with your interviews, everyone! 🌱

Five Simple Steps For Better Autocomplete UX

Vitaly Friedman — Wed, 15 Mar 2023 00:00:00 +0000

Autocomplete! Their design seems to be almost obvious at first, yet there are some common usability issues that appear over and over again, preventing users from using them effectively. Let’s fix that — by exploring 5 autocomplete UX details where the design pattern can be improved.

1. Always Show Suggestions On Focus #

When do we start showing suggestions? Typically, this happens after a few first keystrokes — and usually that’s a recipe for trouble. There will always be some portion of users who always look at the keyboard while typing — usually we just don't know how many people do so.

Almost perfect autocomplete UX from a lengthy series on forms by DKO.

Often it’s only after a user finishes at least some part of their input that they will verify it on screen. So if we display autocomplete suggestions too late, some people will never learn that your site provides an excellent autocomplete support.

We can indicate autocomplete with a search icon, or a chevron icon, as well as a sensible placeholder, such as “Select an option...”. It also works best to always display autocomplete suggestions immediately: with frequently used or most relevant options, for example. It’s just more obvious this way.

2. Use Tap-Ahead Autocomplete Suggestions #

If you take a close look at the example below, can you spot the arrow on the right-hand side of keyword suggestions? Now, do you know exactly what they are, and how they are different from regular keywords? Chances are high that you don't.

One of the many: autocomplete suggestions by Mediamarkt, a German eCommerce retailer.

While the tap or click on the keyword will bring you to a search result page, the click on the arrow appends the search query to the search box, without executing search. So you can gradually construct a more sophisticated search query, relying on relevant suggestions. It’s useful as users can move forward confidently, and never end up on a zero-results page.

A much better way to display tap-ahead suggestions: with pills underneath the search box.

The problem is that this pattern has very low discoverability. Most people just don’t know how it works. A much better way to design this feature is by providing chips or badges underneath the search box, like the newer iteration of Google does. This pattern is often called tap-ahead suggestions — and it’s always a great add-on for every autocomplete.

3. Show A Diversity Of Suggestions #

We often assume that users are just looking for the right search query, but it’s not always true. The search box is often used as a shortcut strategy to get to a particular category or products, and we can help users get there.

Autocomplete can do more than just showing keywords: Prisma.fi, Hema.nl and IKEA

Additionally to keyword suggestions, we can show relevant categories, or even products with thumbnails, availability and pricing. Of course, they also need to include distinct icons and typographic treatment to be recognized as such.

Showing a diversity of suggestions helps users get where they need to go, faster — and it might work very well as an additional way to expose featured products. In fact, users might appreciate this feature very much.

4. Provide Autocomplete Filters #

If a large number of your users are expert users, consider turning the search autocomplete into a sophisticated query builder — with filters, sorting and attributes that can be defined straight from the search box.

On Stackoverflow, users can define filters for search results directly: by specifying the status of a question asked to tags and the number of answers, with a special pre-defined search query syntax.

Stripe follows a similar pattern, with suggested filters and search tips that allow expert users to not only search, but also reduce the scope of search straight away. It might be a bit too complex for new users, but just what is needed for experts.

It’s worth stating that a good autocomplete UX always supports keyboard navigation. Usually users would use Up/Down keys to navigate the list, and Enter to submit a search query. This of course requires a selected search query to be highlighted during navigation in the list, and the search suggestion should be announced by screen readers as well.

Autocomplete from start to finish, a thorough guide by Adam Silver.

You can find an example of an accessible autocomplete component in Adam Silver's article on Building an accessible autocomplete control, along with the markup, CSS, JavaScript and a working demo.

Wrapping Up #

Autocomplete can do much more than just highlighting keyword suggestions. By showing suggestions on focus, using tap-ahead suggestions, exposing users to relevant details from the search box and allowing experts to make the best out of the results before even executing search, we can make autocomplete more efficient and relevant.

The main benefit of autocomplete is the increased speed of accurate and relevant input. Once users know that there is autocomplete, and understand how it works, we can help them increase task completion rates and task completion speed. And that’s something not many component can do as well as autocomplete does.

Things I Wish I’d Known Earlier In My Design Career

Vitaly Friedman — Tue, 07 Mar 2023 00:00:00 +0000

Too often, our individual goals and plans are left far behind the company’s goals and product development roadmaps. That’s not right. Below are some of the tips around design career that I wish somebody had told me earlier in my career, and that I hope will be useful for your career as well.

You need to plan your negotiation strategy ahead of time. Estée Janssens.

1. Never Tell Your Salary Expectations First #

Usually it doesn’t take long until a recruiter or HR manager asks you about your salary expectations. Of course, you’d like to make a good first impression, and my first instinct has always been to provide a slightly discounted ballpark figure.

Salary isn’t everything, but it’s important. Be very careful and strategic when negotiating your salary. It should be fair and comparable to your colleagues. If asked about your expectations, politely reject and ask for an average salary for your level in the company instead.

Also, do your research upfront (via TeamBlind, Levels.fyi, Glassdoor and know what to expect as a minimum.

2. Pay Close Attention To Your Job Title #

We often think that titles don’t matter as much as the work that we are actually doing. Yet throughout the years, I’ve been proved wrong over and over again. Titles do matter. They define salary levels and your growth opportunities.

Be very careful and strategic about the role you apply for, and make sure it matches the role stated in your contract. There are vast differences between UX Designer and Senior UX Designer roles, for example, and growing from one level to another can be quite difficult.

3. Always Have a Comfortable Salary Range in Mind #

Don’t focus too much on your current salary as it might not account for inflation, gender gap, and other costs. Instead, explore what a reasonable salary for your role is and for your level of experience in your region. You might even increase it a bit to leave enough room for negotiations.

Ask yourself what salary would make you enthusiastic enough to be heavily invested in the product and deliver your best work. But never provide a number on the call, and defer it to an email if you must.

4. You Can’t Have It All #

Who doesn’t want to have a lovely combination of ownership in the team, a decent salary with stock options, stability, great managers, fantastic people, and a good work-life balance? It was quite a surprise to me that getting everything neatly packaged in one job opening was quite an unrealistic expectation.

In a start-up, you might have a lot of ownership, but with it often comes slightly chaotic management with last-minute changes and mid-night fixes.
In large corporations, you would have a reasonable salary and stability, but you probably won’t feel like you make significant contributions to the product. But you learn a lot from your team and grow significantly as a professional.
As a contractor or freelancer, you always need to chase your projects, and with it comes a healthy dose of accounting, estimates, scopes of work, and eventually, last-minute changes and deadlines. This adds to the pressure and stress levels that you might want to avoid.
In an agency, you’ll learn a lot about different knowledge domains, but you’ll be jumping from one project to another, sometimes working on multiple projects at once. The salary might be lower than in a product team, and you’re likely to work on deadlines.

Be clear what is more important to you, and what combination are you after: team, culture, ownership, flexibility, stability, salary, work-life-balance. You rarely will find a perfect match, and you will have to compromise. Just have your priorities clearly defined.

5. Keep Record of Your Achievements #

Why is it so difficult to grow from one role into another? Well, we often think that if we just work hard enough, we will get noticed, and we will be promoted to senior positions. But your growth heavily depends on how attentive and caring your managers and your company are.

However, in many companies managers change, companies evolve, teams get restructured. You might not ever get a chance to have a proper conversation about a promotion.

Maintain an up-to-date record of your achievements, milestones, projects and learnings, workshops and trainings you’ve attended, articles you’ve written and talks you’ve given, your help with onboarding new employees, your contribution to weekly UX meetings, etc. (a Google Doc would do). This will help you argue better in your 1:1’s with your manager(s).

6. Test The Company During Your Probation Period #

Watch out for red flags. Do people leave for strange reasons? Do managers change frequently? Do people get promoted at all? Are designers being listened to in the company? Track the impact of your work, and anything that stands in the way.

7. Switching Companies Is How You Make More Money #

Jumps from one company to another help climb the career ladder and improve salary, yet as a result, you might end up without any ownership at all. Just because you don’t get enough time to contribute and see the impact of your contributions in real projects. And to me, that’s always been very important, and more important than the salary.

In the industry, it’s common to be jumping between companies every 12–18 months, and in fact that’s how you usually would make more money. But if you feel valued and appreciated, the team is great and salary is fine, stay. But: make sure you don’t leave too early or too late. Leaving after 8 months will raise red flags in your future job interviews.

8. Think About Passive Income Early #

When you are in your 20s, it’s easy to dismiss the notion of passive income. After all, you have all the time in the world to make your financial decisions later. But I can’t stress it enough: do think early about your passive income.

The earlier you start investing into ETFs or creating digital products, the more you can accumulate over the years. You don’t need much money to start building up your passive income. Even putting aside $100 a month will pay off long term. Be visible by writing, sharing, open-sourcing. That’s a great investment of your time for decades to come.

Wrapping Up #

Don’t put your hard work and efforts into something that might not even be worth your energy. You are talented, skilled, and hard-working, and there are plenty of good uses for your skills out there. So settle for a while if you must, but never stop looking for options that would suit you better if you can.

Designing A Time Zone Selection UX

Vitaly Friedman — Sat, 04 Mar 2023 00:00:00 +0000

Designing a time-zone selection is hard. Not only are time zones difficult to scan and understand; they also change over time, with or without daylight saving at different times, and there is no universal way of organizing and displaying them.

Time zones are hard, a wonderful article by Łukasz Tyrała with details about time zones and tips for better time-zone selection UX.

And then there are dozens of time zones and hundreds of mysterious abbreviations — UTC, GMT, DST, CET — which sometimes change, and sometimes not. Ironically, users often need most time when choosing the right time zone. How do we make it easier for them? Let’s figure it out. (You can find more details on that in the usability chapters in the video library.)

1. Use a Complete List of Time Zones #

In total, there are 352 time zones around the world, with 245 different abbreviations (as defined by the Time Zone Database). Of course time zones evolve over time; they get changed or deprecated, so it shouldn’t be surprising to discover that our legacy applications might be showing some time zones which are no longer relevant.

A section of time zones around the world: download the complete list.

Of all the different time zones, Coordinated Universal Time (or UTC) is the one reliable, true compass for time definition. It never changes and serves as a constant time of reference, in which other time zones are relative. It’s also seen as a successor to the Greenwich Mean Time (GMT). Unsurprisingly, it will have to make its appearance in our time-zone selection UI.

2. Users Think in Their Local Time #

Because UTC is standardized, we should be able to rely on it and display just that. However, as it turns out, users often don’t think about UTC at all. Nor do they understand time zones, or the difference between UTC and GMT, or when and where daylight saving times are. However, GMT in general is better understood than UTC.

Time Zone Selectors UX study. All groups had more correct selections in GMT than UTC. But it was statistically significant only in UK.

Instead, users typically think about the local time in their city, or in their region. And when arranging a call or meeting, they need to look-up the time for a specific date in a specific location where their partner will be connecting from. In fact, the selection of a city is way more important than time zones.

3. Always Add Autocomplete For Location #

It’s not surprising that scrolling through the endless list of countries and time zones isn’t particularly exciting. So whenever possible, include autocomplete to allow users to type their city or country and locate the needed time zone faster.

Always encourage users to start typing. When placeholders matter: “Start typing” might work better than “Select” as users might scroll instead.

Most people will be searching for a specific city, but they can type larger areas — counties, states and localities — as well. This typically means that we need to support cities and countries as a minimum. And if a country has more than one time zone, we need to highlight distinct time zones for each country match.

4. Show Current Times in Locations #

Sometimes selecting a time zone is only one part of the story though. What if a user needs to make a decision about the right timing as well? We can display the current time on location to help there.

No UTC/GMT times are displayed on Calendly. Instead, they show the current time on location instead. Source: NN Group.

5. Detect and Suggest User’s Time Zone #

Based on current user’s location and their past selections, we can suggest a time zone that is most likely to work for the user. These suggestions would be displayed above the list for quick access. Of course, IP detection is never bulletproof, so we need to always include a way to override the suggestions as well.

We can suggest a time zone based on user’s current location and their preferences. Source: NN Group.

6. Sort Countries Alphabetically, Not By UTC/GMT Offsets #

Since many users orient themselves in time zones through cities and countries, we could sort time zones options alphabetically, by country and at least large cities. We still need to provide UTC/GMT offsets or current time as well.

A sophisticated time zone selection UX in Grafana.

In Grafana, users can search by region, country, city, UTC offsets time zone abbreviations or use default settings. All cities and countries are sorted alphabetically and grouped into continents.

Time Zone Selection UX Checklist #

Our goal is to drive users towards an accurate selection, faster. To do that, we can embed a few little details into our interfaces:

Detect and suggest user’s time zones.
Support typing for city, country, locality, UTC offset.
Always show current times in locations.
Use a placeholder "Start typing..." or "Search..."
Display local time zone names (CEST, PST etc.).
Sort counties and cities alphabetically.
Don’t sort time zone options by UTC/GMT offsets.
Surface critical details (calendar availability, weather conditions, custom preferences etc.)
Keep your timezone database up-to-date.

Useful Resources #

A Complete Timezone List, a list with grouping by timezone, in TypeScript.
Standard Time Zones Of The World (as of April 2014).
It’s Time We Addressed Time-Zone Selectors, a wonderful usability study by Norman-Nielsen Group.
On Time, Time Zones, and Software, a fantastic write-up all around time zones, UX and implementation details by Łukasz Tyrała.

Wrapping Up #

Sometimes allowing users to type instead of scrolling is much faster. Time-zone selection is just an example of that. This also goes for country selectors, sliders and sometimes even navigation. The challenge is to hide complexity by showing users things that matter and hiding things that do not.

Seven Fantastic Design Systems

Vitaly Friedman — Fri, 03 Mar 2023 00:00:00 +0000

Nobody is surprised by design systems these days. A novelty just half a decade ago, they have become an established part of the design process, helping teams bridge the gap between design and code.

I'd love to share with you some of the useful features of design systems that I keep referring to often in my work — and hopefully they can boost your design system, too.

1. Accessibility and Naming Conventions #

Nordhealth is created for healthcare applications for clinics and practices, and as such, it’s heavily focused on accessibility. There are also dedicated guides to naming conventions and localization guidelines. Plus, there is a plenty of customization options, themes and a fully-fledged CSS framework. Unfortunately, the Figma toolkit isn’t open-sourced yet.

2. Branding and Multi-Lingual Design #

Olympics Design System is focused on branding and identity design, but also provides examples of ilustrations and graphic elements. It shows how to manage multi-lingual challenges and how to use typography, with plenty of good and not-so-good examples and many guidance notes along the way.

3. Comprehensive, Live Examples #

Workbench Design System is a wonderful design system by Gusto, with usage guidelines, do's and don'ts, visual explanations and implementation details. What really stands out to me are very, very comprehensive live examples that explain how exactly components should be used in different contexts.

The developers have also built a Gusto Workbench VS Code Extension with common snippets for their UI components.

4. Content Guidelines and UX Writing #

Deutsche Bahn Design System is a lovely design system with content guidelines, accessibility considerations, components and contextual examples of components in use. It also provides a number of guidelines around UX writing (in German) and helpful visual guides to accessibility and logo.

5. Decision Trees and Flow Charts #

Workday Design System seems like a regular design system with content guidelines, UI components, patterns and accessibility guidelines. However, what really stands out to me are decision trees and flow charts that are used to help designers and developers make a decision around a particular component or how it could be used.

6. Visual Examples of Do’s and Don’ts #

Audi Design System has been around for a while. Along with brand appearance guidelines and UI components, one useful feature it provides is a comprehensive set of visual examples of how a component should and shouldn’t be used in Audi’s interfaces. There is also a freely available Audi UI Kit for Figma and Sketch UI library.

7. Free Design Systems Figma Kits #

Design Systems Figma Kits is a growing repository of freely available Figma kits of design systems — grouped, organized and searchable. Additionally, I can only recommend Gov.uk design system Figma kit, focused specifically on complex user journeys and web forms.

And That’s A Wrap! #

Obviously there is no reason to copy-paste an existing design system, but we can get inspired for features and the ways to present do’s and don’ts, for various contexts. I hope that some of these examples will be helpful for your work.

Designing Better Meetings

Vitaly Friedman — Mon, 27 Feb 2023 00:00:00 +0000

Meetings can be utterly exhausting and frustrating, but also valuable and productive. Here are some of the formats and guidelines that seem to be working slightly better, especially in large organizations.

Best Practices For Meetings #

There should be no surprises in a meeting.
Meeting invites come with an agenda, pre-read and objectives.
The agenda must be sent ahead of time (at latest 24h).
Meetings without an agenda get cancelled automatically.
Meetings are time-boxed to 14, 27 or 42 mins.
3×27 mins sessions often more productive than 1×1.5h meeting.
Meetings are most productive with 5-8 people max.
Not everyone has to speak, but everyone has to feel heard.
Always start on time, and never finish late.
Record meetings by default for async consumption.
Alignment sessions work better in the morning.
Retrospectives work better in the evening.
Create focus day(s) when no meetings take place.

Meetings Types #

It's a good idea to always define a specific meeting type, with a custom emoji and a color coding for your calendar. I love the meeting format suggested by Rich Watkins:

Broadcast Meetings 📣 for announcements and townhalls,
Rhythm Meetings 🥁 for regular status updates,
Planning Meetings 🏗️ to define timelines and provide estimates,
Problem-Solving Meetings 🛠 for workshops and solution finding,
Exploration Meetings 🏕️ for big questions and complex problems,
Team Building Meetings 💚 for team spirit and collaboration,
Review Meetings 🏆 for retrospectives, 1:1, performance meetings.

10-Points Meetings Checklist #

Larger meetings need to be structured and formalized. For example, with a 10-point meeting document that's distributed ahead of time:

Format of the meeting, title, date, time
Zoom/Teams URL for remote meetings,
Purpose and desired outcome,
High-level agenda,
List of attendees,
Questions to be discussed or decisions to be made,
How much time each question would get,
Off-topic items that were parked during the meeting,
Action points and ownership/roles for each,
Link to the video recording + transcript.

Poorly designed meetings are wasteful; but good meetings are a critical part of productive work — from setting priorities and information sharing to brainstorming and collaboration.

Useful Miro Templates For UX Designers

Vitaly Friedman — Thu, 02 Feb 2023 00:00:00 +0000

Full Remote Design Sprint Template, by TED
Reflection Island: End of Year Team Retro, by Aryanna Martin
Product Design Principles Workshop Template, by Stu Collett
Structured Problem Solving Workshop
UX Persona for Healthcare Projects
System Mapping Toolkit
User Research Kick-off Canvas, by Michael Bierens de Haan
Kick-Off Workshop Template, by Aneta Kmiecik
User Journey Map Board, by Stéphanie Walter
User Task Canvas, by Geoffrey Crofte
UX Problem Statement Map for Logistics Projects
UX Research Plan One-Pager, by Alba Losada
The Sustainable UX Design Toolkit
User Testing Observations Template
Remote Usability Study Workshop Template
Design Critique Template
Features Prioritization Board Template, by Yuval Eitan

Frequently Asked Questions UX

Vitaly Friedman — Tue, 31 Jan 2023 00:00:00 +0000

Barely any website can escape the curse of the FAQ section. Even seemingly simple products eventually grow roots as the user base expands. Sadly, the web is not a particularly friendly place, and so users have all kinds of doubts, objections, questions and concerns — and they need to be addressed.

Walmart FAQ hub highlights multiple FAQ guides, depending on the topic of interest, sometimes with one-line answers.

But are FAQs a good solution to do just that? Not necessarily. Let’s explore some of the issues that FAQs have, and how to actually help customers find what they need. You can find more details on that in the usability chapters in the video library.

Usability Pitfalls With FAQs #

We’ve learned to rely upon dedicated FAQ sections over the years, and users seem to understand the concept very well. However, on an FAQ page they typically scan questions for a specific keyword, or use in-browser search to find what might be relevant for them.

The questions format, however, doesn’t aid in quick navigation to the answer. And with accordions, the answers usually aren’t accessible without opening each accordion.

On Airtable Help Center, there are no FAQs. Instead all topics are presented as cards, front-loaded with keywords.

This reveals some significant usability issues:

FAQ is unlikely to help if customers don't know if a particular piece of content or feature exist on the site. People don't call support about tools they don't know exist.
FAQs are too slow to use: they are convenient for writers, but take significantly more time for users to scan and understand.
FAQs lead to duplication: as multiple pages repeat the same information, they pollute search,
FAQs are difficult to navigate: they force content designers to group content by general type or format, rather than task (e.g. toolkits, resources, videos),
FAQs need to be actively maintained: customer’s questions change frequently, and multiple sections of the site must be updated.
FAQs also have governance issues: every piece of content needs an owner, but it’s difficult to assign an owner to an FAQ page spanning multiple topics.

In general, just like PDFs, FAQs are examples of organization-centric form of navigation and content. Since many customers don’t know how the organization is structured and how it works, they often experience issues finding an answer in a myriad of poorly organized questions.

The Best FAQ Isn’t Even There #

Typically FAQs emerge because users can't easily find a particular piece of information on the site, and keep sending similar questions to the service desk — after all, these questions are “frequently asked”.

However, this isn't really an indicator that an FAQ section is needed, but rather that IA, navigation and search aren't working very well. Before setting up an FAQ page, we can try to find a way to show answers where users actually expect to find them.

In the eCommerce example above, we leave customers with plenty of unanswered questions. We need to highlight all the details about taxes and fees, delivery times, shipping costs, returns policy and payment options — as prominently as possible. But we don’t really need an FAQ for that — we could show them right away (pictured below ↓).

We might need to do a bit more work. We could break down the pieces of content and publish relevant content where people naturally look for it. We also might need to iterate on IA, navigation design, labels and layout with top tasks and tree testing.

There are no FAQs on AirBnB. Instead, topics with short headlines and front-loaded keywords.

And once it all set in motion, we might set up help hubs, or if absolutely necessary, an FAQ page as a temporary solution.

A Well-Designed FAQ #

But what if we do need an FAQ after all? Of course we need to group questions by topics, and probably design them as accordions. Displaying all answers as is would work with in-browser search, but it might make the page too lengthy to be usable.

Here are some of the useful features of FAQ pages that you might want to consider:

Include the FAQ link in the footer of each page,
Include a table of contents (perhaps sticky),
Alternatively, group accordions in a split-menu (as displayed above),
Use autocomplete search to find specific details in the FAQ might be helpful,
Add jump-links with an option to go back to the overview,
Allow customers to open multiple questions at once,
Instead of long passages of text, use bulleted points and shorter, concise sentences,
Front-load questions with keywords as far as possible,
Validate the quality of FAQ with a “Did this answer your question?” prompt?
For longer FAQs, or those with complex answers, screenshots, or videos, you might want to set up separate answer pages (or topic pages).

Wrapping Up #

FAQs are difficult to navigate and maintain, but they do gather critical information in one single place, and hence can be helpful. But we need to measure just how helpful they are.

Measure how much traffic your FAQ page has and how often people mark answers as helpful. Establish a regular maintenance review for the content of the page as it might be something that users heavily rely on.

You might not need an FAQ page after all. Perhaps you could break down the answers to each question within the interface. Or perhaps you could create a help hub, or a full support guide with how-to articles, screenshots and videos, dedicated Q&A blog posts and a decent autocomplete. This might be much more efficient than a never-ending list of nested FAQ sections.

Design KPIs

Vitaly Friedman — Fri, 27 Jan 2023 00:00:00 +0000

Imagine that you’ve just received an invite to a new meeting. The description is a bit vague, but the title is sitting right there, with its heavy weight, making you a bit worried: design KPIs. Now, what do you think the meeting is going to be about?

It wouldn’t be surprising to hear about conversion rates, new A/B testing results and bounce rates; perhaps exit pages and SERPs and funnel drops. We might expect data from Google Analytics, and perhaps a report about generated leads.

What we expect to see are data points scattered across charts. Each of the data points represents a unique experience, and when put together, they represent an average behavior in our products. The average user doesn’t exist, of course, but the data helps us identify trends and changes over time.

These trends are indeed valuable insights. But they also are only one part of the full story.

Hidden Costs #

Over the decades, we’ve become remarkably good in digital design. We’ve learned how to craft truly beautiful interfaces and well-orchestrated interactions. And we’ve also learned how to encourage action to meet project’s requirements and drive business metrics. We can make pretty anything work really.

Can you spot what’s not quite right in this mock-up? Designed by Paul Boag. Large view.

In the mock-up above, the option "Add to basket" is beautifully highlighted in green, indicating a way forward, with insurance added in automatically. That’s a clear dark pattern, of course. The design, however, will drive business KPIs, i.e. increase a spend per customer. But it will also generate a wrong purchase. The implications of it for businesses might be severe and irreversible — with plenty of complaints, customer support inquiries and high costs of processing returns.

Many organizations focus on a few selected business metrics; yet they need a holistic overview of metrics that have an impact on the entire business. As Paul Boag explains in his recent book, there are plenty of hidden costs that often stay in the shadows of business KPIs. This usually leads to short-term improvements with expensive long-term implications.

Healthy business metrics mix. Large view.

A healthy business metrics mix usually includes KPIs that go a bit beyond data from Google Analytics. We also need to consider life-time value, time to first purchase, time to upgrade, loss in processing returns, cost of support, sales, marketing, acquisition and ratio of negative reviews, to name a few.

And that’s exactly where another significant set of metrics comes into play — design KPIs.

Design KPIs #

How can we speak objectively about a particular design? It appears to be such a subjective thing, with plenty of personal opinions and individual experiences that flow into every individual design process. Yet ultimately design solves problems, and we surely should be able to measure how well a particular problem is being solved.

In fact, just like we define business KPIs, we can also establish design KPIs and track their performance over time. Design KPIs are key attributes that capture customer’s experience for top tasks that users frequently perform in a product.

A leaderboard for design KPIs for a project with a few separate products. Each value is normalized on the scale from 1 to 10. Heavily inspired by incredible work by Dan Mall on Design Systems Scorecards. Large view.

Recently I’ve started setting up dashboards of design KPIs in organizations that I work with. Together, we decide on key attributes that are important to provide a better UX, and then we track them repeatedly over time.

There are, as it turns out, plenty of helpful design KPIs, but these are the ones that usually deserve special attention:

top tasks completion rates,
top tasks completion times,
accuracy of data submitted by users,
ratio of content vs. navigation (mobile/desktop),
error frequency,
error recovery rate (= quality of error messages),
speed of publishing,
quality of leads,
time to release,
time to upgrade,
conversion rate,
carbon footprint impact,
System Usability Scale Score (ideally over 75),
accessibility score,
web performance score.

These metrics are much more focused around the actual user experience and user behavior, rather than ambiguous data points in analytics that represent an average behavior. Of course, we also need to keep track on these KPIs as time evolves. And this requires measurements.

Measuring Design KPIs #

Once we have defined the KPIs, how do we measure them? We can rely on Gerry McGovern’s Top Tasks approach and identify the most frequent tasks that users complete in a product. We conduct research to discover the most important tasks. We study search queries and server logs, run user interviews and workshops with stakeholders.

What really matters: focusing on Top Tasks, an article by Gerry McGovern that introduces the Top Tasks methodology. Illustration by wonderful Brad Colbow.

Once we have that list, we bring users in to vote on the tasks that they consider to be important for them. Then we write down task instructions for each top task. These instructions will be handed to users in usability tests to validate that they can actually complete these tasks successfully.

Finally, we run tests with the same task instructions to the same segments of users, repeatedly, every 8–12 weeks. Based on these tests, we measure and plot success rates and completion times over time. As long as we improve our design KPIs, we should be on the right path. And we have data to prove it!

Design KPIs help us stay on track in driving metrics that actually matter. With them, we can gradually improve UX over time and gain evidence that our design decisions are actually effective in practice.

Wrapping Up #

It’s worth noting that the definition of design KPIs should have a significant impact on how the quality of work is measured. Rather than focusing on the amount of produced pages or websites, bounce rates or click rates alone, we should be aligned towards producing quality content that is useful for people consuming that content.

Next time you are working on a project, consider establishing design KPIs alongside business KPIs and create a more holistic and healthy mix of metrics that capture user experience and business goals. In the end, both sides will only benefit from it, with a sustainable and effective strategy that keeps users and business stakeholders happy.

Designing Better Breadcrumbs UX

Vitaly Friedman — Sat, 14 Jan 2023 00:00:00 +0000

Nobody gets particularly excited about breadcrumbs. Those tiny little crumbles that illustrate where a user currently is in the intricate hierarchy of the website. They might be unnecessary on smaller websites, but they can make a difference on complex websites.

When users come from search engines, messaging apps or social media, they need to understand where they are on the site. They might need to navigate forwards, backwards or sideways, exploring similar or related pages. In all these cases, breadcrumbs are invaluable.

So how can we make them more useful to our users? Well, here are a few ideas.

Breadcrumbs Work Best Under Global Navigation #

To help users understand where they are, breadcrumbs need to be visible to users. Ideally, we would place them right under the main navigation, or at least above the headings, easy to spot, find and use. This also indicates a clear connection between breadcrumbs and what they refer to, the current page.

On Australia Post Service, for example, various kinds of navigation need to work together. The primary navigation, the breadcrumbs, the sidebar and tabs. Users can jump between various levels, go backwards with breadcrumbs, move forward with horizontal navigation, move sideways with the sidebar navigation and switch contexts within sections with tabs.

Avoid “Disabled” Breadcrumbs #

For legacy reasons, every now and again some breadcrumbs appear as links, while others are disabled, merely representing the location of a given page in the overall hierarchy.

In Sparkasse’s breadcrumbs, “Startseite” (Homepage) and “Karten” are actually links, but the sections in between are not. There might be very good reasons for this decision, but the general expectation is very clear: all breadcrumbs should be links, except the last one.

Breadcrumbs Should (Probably) Point To The Right #

In left-to-right-interfaces, relationships are usually indicated with icons pointing to the right. Because we usually consider browsing through pages as a horizontal experience on a timeline, we usually move from left to right.

However, sometimes breadcrumbs point to the left, rather than to the right. On TVM, for example, arrows reluctantly point to the left. Since breadcrumbs are usually explored right to left, the icons indicate where a particular section or page belongs to.

We all would probably point to the right, since it’s more conventional. But in usability tests, we couldn’t find any preferences or differences at all. While it might not matter that much, pointing to the right is more familiar to most people.

Distinguish Between Links and Text Labels #

If a component in the UI behaves differently or serves a different purpose, we make it stand out by highlighting it in some way. In the case of breadcrumbs, there are two different types of crumbs: the current page (if we choose to display it), and the breadcrumbs on the path to that page.

On Deutsche Bahn, the styles for text labels and links are identical — unless you start hovering or tabbing through the sections. Plain underlines would make it slightly more obvious.

Showing Current Page Might Be Unnecessary #

In breadcrumbs, current page shows where a user currently is, and there is no need to navigate there because the user is there already. If breadcrumbs live close to the main heading of the page, repeating them in breadcrumbs might be unnecessary.

Breadcrumbs on Gov.uk don’t include the current page. However, the futher away the breadcrumbs are placed from the main heading of the page, the more likely it is that the current page will need to be present in the breadcrumbs.

On Mobile, Use Breadcrumbs Accordions #

Websites with many levels of navigation often don’t have space to display the entire path with breadcrumbs. One common way to deal with this problem is to truncate intermediate steps in the breadcrumbs navigation, or show just one item at a time. However, this makes previous levels inaccessible.

On the European Commission’s website, the parent category of the current page is always displayed in full, but the parents of that section are truncated. When a user taps or activates the truncated area (which is a link), entire breadcrumbs appear. Notice the visual difference between the current page (text label) and breadcrumbs (links).

Curtain Reveal Breadcrumbs #

Another approach on mobile is to try to show as much as possible with an option to show/hide breadcrumbs. This could be with breadcrumbs appearing on the same line, encouraging users to swipe left and right, or by encouraging users to tap around to the point of interest.

Use Sideways Breadcrumbs #

Often, breadcrumbs are mostly a static representation of the information architecture on the site. They support backward navigation, but moving forward or sideways always requires another click. There is an alternative way of helping users move forward faster.

At ADAC, breadcrumbs are sort of extended — with a drop-down that allows users to jump to other sections within the category quickly. The last chevron in breadcrumbs might be missing to make the expected interaction perfectly clear, but the design pattern per se is useful since it significantly speeds up jumps between siblings.

We could even take it to the next level. Federal Administration of Statistics in Switzerland displays global sideways breadcrumbs that help users jump between different departments of the administration. The breadcrumbs are the first thing that users encounter on the site.

Wrapping Up #

Breadcrumbs alone aren’t enough. The aren’t sufficient to navigate the site easily and always complement existing navigation patterns, but can’t really replace them.

Every time we design breadcrumbs, we need to keep them visible without scrolling, create a clear relationship with the main heading and maximize the speed of interaction from intent to result. Not many components can do it as well as breadcrumbs do, so keep them close in your toolbox.

We Don’t Need Hamburger Icons

Vitaly Friedman — Sun, 08 Jan 2023 00:00:00 +0000

There are many flavors of hamburger icons out there. From chocolate cakes and hot dogs to fries and veggie burgers. They all hide navigation, oftentimes critical navigation that users need to comfortably use the site.

Hamburger icons come in many flavors. Designed by Alex Münch.

But not in a single usability session did they help users navigate faster than a boring, dull yet remarkably efficient “Menu” button. No icon, just a button with a text label. Perhaps with a chevron pointing down to indicate a drop-down behavior (as pictured below).

A simple “Menu” button never fails. It’s large, so it’s always easy to tap and click. As a button, it’s perceived as interactive. It works for frequent and inexperienced users. It works for teenagers and senior citizens. It has an information scent. It’s universally understood.

Simpler is always better. Obvious always wins. And it makes it damn hard for anybody to make a mistake, accidentally or not.

So no hamburgers or fries for me, I’m afraid. Consider me old-fashioned, but I’m going to stick with the “Menu” button for the time being.

Designing A Better Birthday Input

Vitaly Friedman — Sat, 07 Jan 2023 00:00:00 +0000

Every time you apply for a job application, open a bank account or book a flight, you probably will be typing in your date of birth. As designers, we don’t just care about the completion rates, but also completion times and the accuracy of input.

We also want to support browser’s auto-fill and minimize mistakes. To achieve the last goal, we often rely on a date-picker-widget (native or custom) or a group of drop-downs.

It turns out that both solutions are suboptimal, and unnecessary — and they often cause more accessibility issues that can be avoided with a much simpler technique.

The Pitfalls Of Native Date Pickers #

Unfortunately, native date pickers, prompted by <input type="date">, come along with plenty of accessibility nightmares. At the moment of writing, when used out-of-the-box, they aren’t a very accessible choice for pretty much any kind of date input. Not only are there plenty of screen reader issues, but also focus and layout issues as well as confusing and generic error messages.

A calendar view with very strict input requirements. Accessible only for mouse users. The keyboard input is disabled. It took me 52 seconds (!) to provide my birthday. (Video preview)

On top of that, many implementations disable keyboard input altogether, requiring customers to use a native date picker’s calendar widget exclusively to reduce mistakes. Without a keyboard input fallback, users have to embark on a long-winded journey between days, months and years, taking up dozens and dozens of taps or clicks.

As humans, we usually know our birthday, and we don’t really need to look it up in a calendar. Yet the interface requires us to navigate between dates, and then find our date in the calendar overview once we get there. This is useful when booking a flight, but not very useful when typing a birthday.

The Pitfalls of Drop-Downs #

Compared to native date pickers, drop-downs seem to be much faster and easier to navigate. They are accessible by default, plus rather than navigating between months and years, it’s enough to locate the right numbers in 3 lists — days, months and years.

The iOS calendar reels are shown after tapping onto the date control. (Image source)

But drop-downs are still slow. They have zooming issues. Pinching scrollable options is tiring. They take up a lot of space. The list of years is long. And when specifying the input, we need to tap the control, then scroll (usually more than once), find and select the target, and continue to the next dropdown. It’s not exhilarating either.

That’s why dropdowns are considered the UI of last resort, and usually replaced with buttons (e.g. for filters), toggles, segmented controls, or autocomplete boxes. Dropdowns can be useful for a long list of selections; but “operating” them takes a lot of time, and it’s not comfortable either.

The Default Values Dilemma #

And then there is a question about default values. While with dropdowns we default to no input whatsoever (mm/dd/yyyy), with a date picker we need to provide some starting point. In the latter case, ironically, the “starting” date usually happens to be just around the date of when the form is filled. This doesn’t appear optimal of course, but what should be the right date? We need to start somewhere, right?

When a date-picker with default values makes sense: when booking flights or vacation. Open sourced by AirBnB. (Video preview)

Well, there really isn’t a right date. We could start early or late, 3 months ago or tomorrow, but in the case of a birthday picker, all of these options are pure guesswork. And as such, they are somewhat frustrating: without any input, customers might need to scroll all the way from 1901 to the late 1980s, and with some input set, they’ll need to correct it, often jumping decades back and forth.

No matter what choice we make, we will be wrong almost all the time. This is likely to be different for a hotel booking website, or a food delivery service, and plenty of other use cases — just not birthday input.

Designing A Better Birthday Input #

If somebody asks you for your birthday, you probably will have a particular string of digits in mind. It might be ordered in dd/mm/yyyy or mm/dd/yyyy, but it will be a string of 8 digits that you’ve been repeating in all kinds of documents since a very young age.

We can tap into this simple model of what a birthday input is with a simple, single-input field which would combine all three inputs — day, month, and year. That would mean that the user would just type a string of 8 numbers, staying on the keyboard all the time.

Using one input for a date is ambiguous and difficult to validate. Using multiple inputs for date is not ambiguous, and much easier to validate. Designed by Adam Silver. (Large preview)

However, this approach brings up a few issues:

we need to support auto-formatting and masking,
we need to explain the position of the day/month input,
we need to support the behavior of the Backspace button across the input,
we need to support jumps into a specific value (e.g. month),
we need to minimize rage clicks and navigation within the input to change a specific value on mobile devices,
If auto-making isn’t used, we need to come up with a set of clean-up and validation rules to support any kind of delimiters.

In his book on Form Design Patterns, Adam Silver argues that using multiple inputs instead of one input is rarely a good idea, but it is a good option for dates. We can clearly communicate what each input represents, and we can highlight the specific input with focus styles. Also, validation is much easier, and we can communicate easily what specific part of the input seems to be invalid, and how to fix it.

To explain the input, we’d need to provide labels for the day, month and year, and perhaps also show an example of the correct input. The labels shouldn’t be floating labels but could live comfortably above the input field, along with any hints or examples that we might want to display. Plus, every input could be highlighted on focus as well.

Design pattern, as suggested by Gov.UK team. (Jump to the demo)

Over the years, I couldn’t spot a single problem with this solution throughout years of testing, and it’s not surprising the pattern being used on Gov.uk as well.

When You Need A Date Picker After All #

While the solution above is probably more than enough for a birthday input, it might not be good enough for more general situations. We might need a date input that’s less literal than a birth day, where customers will have to pick a day rather than provide it (e.g. “first Saturday in July”).

For this case, we could enhance the three input fields with a calendar widget that users could use as well. A default input would depend on either the current date, or a future date that most customers tend to choose.

Adam provides a simple code example for the Memorable date pattern in his NoStyle Design System.

Adam provides a simple code example for the Memorable date pattern in his NoStyle Design System. It solves plenty of development work and avoids plenty of accessibility issues, and all of that by avoiding tapping around calendar widgets or unnecessary scrolling around dropdown wheels.

Wrapping Up #

Of course, a good form control depends on the kind of date input that we are expecting. When we ask our customers about their date of birth, we are asking for a very specific date — a very specific string, referring to an exact day, month, and year.

In that case, a drop-down is unnecessary. Neither is a calendar look-up, defaulting to a more-or-less random value. If you do need one, avoid native date pickers and native drop-downs if possible and use an accessible custom solution instead. And rely on three simple input fields, with labels and explanations placed above the input field.

AI Tools For Designers

Vitaly Friedman — Mon, 02 Jan 2023 00:00:00 +0000

I have to admit that I used to be very skeptical about the entire topic of AI and algorithmic design, and how it is going to change and shape design on the web. To the point that I was reluctant to even try out Midjourney and DALL-E — there were enough of artifacts produced by those tools all around the web.

My attitude changed entirely when I encountered Erik Kennedy's take on AI in his recent newsletter. Erik suggested a few AI tools for research and inspiration in the design process, and it has started an entire rabbit hole trip for me.

An incredible result generated by Lexica Aperture for a 'portrait of a master chocolate maker in an artisan chocolate shop'.

Useful AI Design Tools #

Below are some of the tools that I've discovered, and I hope that you will find them useful as well:

For AI portraits and photos, use Lexica Aperture,
For AI-generated model photos, use Generated.photos,
For AI-generated rare photos, use Raretifacts,
For AI image editing, use Lensa,
For AI headlines and CTAs, use ChatGPT,
For AI textures, icons, visual assets, use DALL-E,
For AI logos, use LogoAI,

This set of headphones has never existed — except in the AI's imagination. Designed with Raretifacts.

For AI font picking, use ChatGPT,
For AI image retouching, use Background Remover or Remove Background,
For AI color palette generator, use Khroma,
For AI image upscaling, use Let's Enhance,
For AI video generation, use Synthesia,
For AI doodles generator, use Autodraw,
For AI eye-tracking/heatmap testing, use Visualeyes,
For AI avatar generator, use StarryAI,
For AI mock-ups generator, use uizard.

Surely there are plenty of other AI tools available out there, and Futurepedia features 100s of of small and large AI tools that might come in handy for a project.

And if you are looking for a showcase of specific AI outputs, there is a growing repository of AI Prompts as well.

A Little Bit Odd, A Little Bit Cold #

The results produced by AI are quite remarkable, but they are far from perfect. Sometimes you'll end up with weird artefacts for human hands and typography, and sometimes results feel extremely polished and unnatural. AI’s output can work as-is, but often it won’t — and will require human intervention.

A problematic part is that AI systems are trained on existing work by creatives, building on top of individual human contributions, which is highly questionable on its own. This goes for illustrations, UI design and headlines. Still, the output always feels... a little bit odd and a little bit cold. And if you want to adjust it, there aren't enough tools to make those refinements and tiny adjustments as needed.

That doesn't mean that we shouldn't be using AI as a research tool though. It actually works really well for research, be it quick brainstorming or exploration. It also is great at collecting data, but also structuring and making sense of it. In fact, there is a lot of value in the output that might provide actionable insights within seconds.

Wrapping Up #

AI is interesting. It probably deserves the attention it gets, and the best results will come with advanced tooling allowing us to granularly adjust AI's output. But hopefully the tools listed above will help you get there. That’s a pretty good start, especially if you are as skeptical about AI as I was just a few weeks ago.

Billboard Navigation Design Pattern

Vitaly Friedman — Fri, 30 Dec 2022 00:00:00 +0000

Not every navigation item is equally important. Some items are more important or more frequently used, so they might deserve a little bit more spotlight in your navigation. In fact, if some items are more important than others, we can use the billboard pattern and display them more prominently.

Korean Post Mosaic #

Korea Post uses a colorful mosaic-alike grid on desktop and on mobile to guide visitors straight to the main features of the site. There is also a big mega-drop-down-hover menu, yet the front and center of the experience is all about the most important tasks that people perform on the site — on the homepage and on the category pages.

Sparkasse Mosaic #

Sparkasse, a German bank, uses a similar approach with important features presented as a mosaic-grid of larger buttons both on desktop and on mobile, along with some features getting slightly less attention. The order of features should be defined by how critical or important the tasks are (for users and for business).

Deutsche Post Billboard #

In their mobile navigation, Deusche Post features most important tasks prominently as 5 large buttons above the regular navigation. The highlighted features stand out; they appear differently than the rest of the navigation and are always displayed when a user opens the navigation drawer.

eCommerce Billboards #

Otto, one of the major retailers in Germany, focuses on lage buttons both on category pages and in the main navigation. As the first choice of category is the most critical one, the first level navigation items include illustrations — presented in a two-column grid.

This pattern is actually quite common in eCommerce as it seems to better drive engagement in a seemingly endless list of options, and Coolblue, Zalando and Target use it, too.

Insurance Billboards #

Typically, a billboard includes plenty of cards, and often with illustrations. They don’t have to appear only on the homepage though; on DNB and Folksam, many category pages display large signposts with available options, like in the examples below.

Summary #

If something requires more attention, we don’t necessarily need flashy animations or large carousels. We can just show the navigation more prominently. If it’s important, it shouldn’t be hidden behind a menu-button. That’s where the billboard pattern helps: as a grid, list of cards or just plain links.

We just need to be very careful of what goes on a billboard and what doesn’t. Sometimes it can change over time, but when top tasks don’t change, the billboard shouldn’t change either. Either way, the billpoard pattern can help in focusing on what matters, and avoiding distractions when they are unnecessary.

Right Timing Matters

Vitaly Friedman — Mon, 26 Dec 2022 00:00:00 +0000

Imagine a shiny newsletter pop-up. A pop-up making its splendid appearance on an eCommerce site just as you are about to make your way to a product page. You didn’t even have a chance to explore a single product yet; nor did you have a chance to learn about prices and materials and delivery options. But here you are, distracted and annoyed, almost instinctively dismissing that pop-up before even fully realizing what it says.

That pop-up is right there, and it’s there for a reason. It’s there because there are established KPIs and expectations that somebody in the company needs to reach. These KPIs expect leads, and the more charming (or intrusive) that pop-up is, the more leads it will generate, boosting revenue projections and bonus pay-outs.

A Short Story About A Large Pop-Up #

A while back I was working with a large eCommerce retailer operating just like that. There was a strong desire to generate new leads, so the team has spent weeks tweaking headings and copy and labels and visuals and calls to action and their positions and backgrounds.

By the end, the pop-up was so large and so loud that you could barely see anything else on the page. And it worked! Indeed, just a few weeks in, the list has started to grow considerably, and there was even a dashboard set up to celebrate new leads coming steadily minute after minute.

It was weeks until the management has discovered that the growth of the list wasn’t resulting in the growth of the revenue.

The company was indeed getting plenty of leads, but those leads were poor and noisy. They were a mixed bag of disposable, temporary emails, creative but non-existent aliases and just random text strings, and as such, they weren’t generating any noticeable revenue at all. The same leads actually cost money because the pop-up — showing up on every other page — drove people away from the site.

It didn’t work because what the company wanted wasn’t just leads; they wanted good leads. They wanted emails with low bounce rates and high opening rates; emails that would have high conversion and high engagement; emails that wouldn't get filtered out or marked as spam. They wanted new, engaged and excited customers who would trust and love the brand. A loud newsletter pop-up wasn’t helping them get there.

What did help the company was removing the pop-up altogether, and subtly integrate a bit of newsletter messaging all across the site, from product pages to confirmation emails.

Strategy To Generate Good Leads #

Over the years studies showed over and over how reluctant people are to respond positively to any promotional message if their workflow is massively disrupted. This goes for a modal, a pop-up, a notification and anything in-between. In fact, any interruption of a task at hand is seen as a major distraction that needs to be dealt with urgently. And urgently rarely works in favor of user experience.

In the end, it’s all about the right timing. If we want a good response, we need to find the time in a user’s journey when we can almost guarantee that users will appreciate the disruption, and will response positively. And that means being very thoughtful about the right time and the right places to surface our messages in a humble, respectful way.

Just a mock-up of what a better newsletter integration could be like. Based on Argos.

There are a couple of options that we can explore:

Integrated messaging. The more integrated our messages appear with the rest of the page, and the more connected they are with a task at hand, the better they will be performing. Think of empty states, 404 errors, product pages and blog posts.
Success moments. Identify moments when a user completes a task or reaches a particular milestone, and integrate your messaging there. E.g. when an invoice is paid, when a request is approved, when a transaction is completed.
Nonmodal dialogs. To ease distraction, consider using collapsible nonmodal dialogs that don’t block the rest of the UI. Users can dismiss them for a while, and return back if needed.
Confirmation pages. That’s where users linger for a while until they get a confirmation email. That’s also a great place to ask users for more details, ask to review email or set up a password, and get a 15% discount in return.
Confirmation email link. As users are eagerly expecting that email, we can allow people to subscribe to a newsletter with one single click on a link in the confirmation email.
Next to the price. We could integrate the newsletter box on most important pages, right next to the pricing of a product, prompting them to subscribe to get 10–15% off the first purchase.

What About That eCommerce Retailer? #

Of course, what has worked for one company might not work for you, so it’s probably a good idea to try out all these options and see what actually works best.

In the case of the eCommerce retailer, integrating the newsletter box next to the price and making the newsletter pop-up a collapsible non-modal dialog worked best. This change didn’t produce as many leads as the initial pop-up, but the leads were much better in quality and longevity.

We need to give users a chance to develop trust towards the brand. This requires a more humble approach and a more patient team, but the results might be significantly better, with customers coming back and giving a company exactly what it has always wanted.

Reviews And Ratings UX

Vitaly Friedman — Mon, 26 Dec 2022 00:00:00 +0000

When we make purchasing decisions, we often rely on expertise from people like us who have already purchased that item. And so we seek user ratings, often looking for a high enough review score and a good number of reviews.

In fact, 95% of users rely on reviews to make their decisions and learn more about how well a product fits their needs. Unfortunately, too often the way we design reviews and ratings UX confuses and frustrates users, rather than helping them.

Let’s fix that.

1. Always Show Decimal Ratings and Total Number of Reviews #

Many services use bright orange stars as indicators of how great or poor the experience has been. However, there are vast differences and nuances between “4 stars”- and “5 stars”-experiences, which are somehow getting lost between two aggressively rounded scores.

Walmart highlights both decimal ratings and the total number of reviews, as well as the distribution of ratings

To provide a slightly better assessment, our rating scores could be a bit more precise. As a general rule, it’s always a good idea to display a decimal average score (e.g. 4.1 out of 5) and the total number of reviews (1528 reviews) together.

The decimal average score provides a more granular estimate, while the total number of reviews guarantees a high enough number of reviewers contributing to that score.

Is there a perfect score? Well, as long as your product’s score is somewhere between 4.5 and 4.9 (with a high enough number of reviews), you probably shouldn’t worry too much. But: don’t feel too tempted to hit that score as it’s not the only detail that customers pay attention to.

2. Display a Full Rating Distribution Summary #

In addition to bright yellow stars, we’ve learned to rely on distribution summaries for ratings. They explain the relation of high-score reviews vs. low-score reviews, and give customers a more granular overview of how good the product is for most people.

The pattern that seems to perform best: a lot of positive reviews and a good number of negative reviews. Source: Flipkart

As customers, we do so by looking for specific patterns in the rating distribution summary. In it, we need to find a lot of positive reviews, and enough negative reviews. Most importantly, there must be enough negative reviews to give customers pointers about the most negative experience that they might have. Products that match that perfect pattern usually appear most trustworthy and perform best.

In user research, this “perfect” pattern is called the J-shaped distribution pattern. The distribution resembles a capital letter “J”, with a small spike of the most negative reviews (★), a flat middle ground (★★, ★★★) and a high spike of the most positive ones (★★★★★). However, as it turns out, it’s not really that perfect and conceals some troubles for businesses.

3. Break Rating Distribution Summary by Product Attributes #

Showing a distribution summary isn’t enough. For example, a customer might be in interested in how long battery life is, or how sophisticated a particular feature is. To learn both, they’ll need to sip through dozens or even hundreds of reviews, often without any success.

Ikea provides individual ratings for each part of the experience. This goes for every individual review as well.

For each standalone product attribute — appearance, value for money, product quality, battery life etc. — we could gather and highlight average scores, based on user reviews. When a customer chooses to provide their feedback, we could ask them to evaluate specific qualities of the product, and then calculate a separate average score for each attribute.

On Adidas, customers can explore ratings and reviews for comfort, quality, fit and support, and filter reviews by commonly used tags.

4. Allow Users To Mark Helpful Reviews #

Not every review is helpful. Some reviews appear very generic, others lack important details, and others again focus too much on irrelevant details. To make sure that relevant reviews get surfaced to the top of the reviews list, we could kindly prompt users to mark if they find a review helpful — both for positive and negative reviews.

On Glossier, most helpful reviews are highlighted at the very top of the “Reviews” section.

Marked reviews — a few of each kind — could then be highlighted on the top of the reviews section, along with the number of users who found them helpful. This dramatically boosts trustworthiness and reduces time to relevance as highlighted reviews have been validated by other customers. This appears authentic and builds trust.

5. Reward Users For Negative Reviews #

The more specific negative reviews are, the easier customers can discard irrelevant details and reach that threshold of trust. Especially if negative reviews simply don’t apply to them.

iHerb.com highlights the most helpful positive and the most helpful critical review at the very top of the “Reviews” section.

You probably will need some negative reviews to appear trustworthy; they will, in fact, increase conversion and boost customer’s confidence. That’s why encourage customers to write detailed, honest negative reviews — and ask them to be very specific about the “bad” parts of the experience and update the review if they’ve been resolved.

The more detailed and the more useful the review, the higher should be reward points and coupon codes. Counter-intuitive, but you might be surprised how well it might impact your sales.

Wrapping Up #

Getting user ratings right requires quite a bit of work. We need to gather and highlight relevant reviews, present distribution charts properly and allow users to use filters, tags or search to faster find useful reviews.

In general, every review should have:

average score presented with decimal numbers,
overall number of ratings,
distribution chart of ratings,
customer’s unedited product photos,
ratings for individual features (size, fit, support etc.),
(#) of reviews for intermediate values (1.0, 2.0, 3.0, 4.0, 5.0),
tags and filters to find relevant reviews,
personal details that will help customers find people like them in the reviews,
date of publishing,
how many people find it helpful,
how many customers (%) recommend the product.

Sounds like a lot of effort — and it actually is. The impact of a proper user rating design can be remarkable and drive your sales efforts much stronger than any other campaign could have.

And once it’s done, it will work for you long-term, building up a community of people who trust your brand and recommend it online and offline. And without any doubt — that’s very much worth the effort.

Useful Resources #

UX tips: featuring customer reviews to increase conversion rates by Sepre Boyer,
User Ratings Design UX Research by Baymard Institute,
How To Design User Rating and Reviews by Nick Babich,
The Problem of J-Curves (in Online Ratings Systems), by Sav Sidorov.

What Do PMs Do?

Vitaly Friedman — Mon, 26 Dec 2022 00:00:00 +0000

Let me ask you a simple question: what’s the role of a PM? Or more specifically, what’s the difference between product managers, product owners and program managers? And how are they different from project managers or technical leads?

If you know the answer, you can probably just skip this email alteogether. And if you don’t, let’s figure it out. You can also find more details around cross-team workflow in the design KPI chapter in the video library.

What exactly do PMs do? In different companies, PMs do different things. Illustration by José Torre.

For Different Companies, PM Means Different Things #

For a very long time, I was utterly confused about the term "PM". I would ask myself what PMs actually do, or look it up and find all kinds of contradictory definitions. Honestly, I never knew for sure what responsibilities would go along with a role of a PM in a given company.

In fact, I would jump from one company to another with wrong assumptions and wrong expectations, often asking the wrong questions, and speaking to the wrong people. I would try to understand the context reading between the lines, mostly failing and wasting time.

It took me years to realize that different companies define the role of PMs differently. Sometimes it would include finances and marketing and sometimes stretch mostly over design and engineering. So no wonder I could never tell right away what PMs actually do in a given team.

PM is The Voice of The Customer #

The clarity came unexpectedly. I’ve accidentally stumbled upon what is probably the clearest definition I’ve seen so far in Build, a wonderful book written by Tony Fadell, with actionable, practical insights for anyone who is building a team:

Product Managers are the voice of the customer. Their focus and responsibility is to figure out where customers are unhappy, what product should do, create the description of how it will work, and the facts they want customers to understand. To achieve it, they work with every part of the business — from engineering to finance.
Project Managers are the voice of the project. They coordinate tasks, meetings and assets to enable individual projects to get done in time.
Program Managers supervise groups of projects and project managers, facilitate processes and make sure all projects get done in time.
Product Owners work mostly with the development team to prioritize the product backlog and create user stories. In some way, they dictate what will and what will not make it into the product. (Which is something that actually should be done together with the team, rather than for them.)

Typically the work of a product owner could be done by a product manager, and a good product manager would do that — and a dozen of other things. They need to discover user problems and the roots of these problems, and work with the team to solve them.

They also need to be close to marketing to communicate the right messaging, and close to sales to make sure the product has a market. Of course they would also work with engineers to get the product built according to spec, and with designers to meet user needs. Getting it all done is usually very challenging and a key to success of a product.

Avoid The Term "PM" #

Most teams assume that “PM” stands for “product manager”, but I’ve seen people being as confused as I am, trying to figure out the right choice between product managers, project managers and program managers.

So perhaps in our Slack messages and emails, we could just avoid “PM” altogether and always be very explicit about what we mean — a “product manager” or “project manager” or “program managers”, or anything in-between. I know for sure that it would have helped me get on the right track much faster back in the day.

You will also find some practical advice on design process, design patterns and design KPIs in my video library on UX.

Happy designing, and thank you for reading!

Onboarding UX

Vitaly Friedman — Mon, 26 Dec 2022 00:00:00 +0000

You've just signed up for a service, yet here it comes — the disruptive, annoying, attention-demanding onboarding tutorial. It’s right there, asking for attention; yet chances are high that you will never find out what it was all about because you’ll be swiftly dismissing it with the "skip" link.

How do we deal with onboarding UX? What's the right way to explain our beautifully crafted new features or hidden treasures that our interface provides? Let's figure it out.

1. Slowly Guide Users To Small Success Moments #

While many onboarding tutorials focus on explaining how to locate some features, it might be a good idea to change the perspective and focus on bringing users to first success moments instead. The learning of the features and their location in the interface, then, happens gradually, slowly, step-by-step, but on the side.

Monday.com and Notion bring users to success moments: users are asked to specify their context first; then they get one of the pre-made templates that's customized for their needs.

The goal is simple: we shorten the time to relevance as much as possible. For our various use-cases, we create and suggest presets and templates that will bring them to a good starting point faster. That's how Monday.com's onboarding works. No interactive tutorials or feature highlights — just a streamlined way to get to the first success moments. This works well.

2. Avoid Interactive Tutorials and Walkthroughs #

Anything that keeps users away from using the product is an unnecessary distraction. That’s why tutorials and walkthroughs are often dismissed almost instinctively. Instead, we'd be better off showing hints only if we are absolutely confident that they are going to be well-received and highly appreciated.

To do that, we need to time our onboarding hints well. We carefully choose and writte our hints and choose the right times and places for just-in-time-hints (Luke Wroblewski). In fact, features usually don't come out of nowhere: they address particular pain points and help users solve particular tasks.

SBB Touch-Fahrplan allows users to connect two locations with a line: that’s the input. First time, users are educated how to connect the lines — and only about that feature. Video and detals.

We can tap into situations when users lose time by doing repetitive tasks, or make the same mistakes, and frame a feature as something that can help them solve tasks better and faster. We meticulously choose the right timings for each feature, and show hints when needed.

3. Collapsible Onboarding Checklist #

Probably one of the best ways of teaching users how to use the interface well is via a collapsible checklist. We use a non-modal dialog with up to 7 accordions that guide users through the necessary steps to complete the set-up or use the service. The onboarding checklist never blocks the UI, can be hidden, deferred — and restored later.

Loom makes onboarding optional; it can be collapsed and restored, if needed.

Loom's onboarding UX is a great example of getting onboarding right. Six simple steps, clearly labeled, eacy to check, easy to hide and restore — with a progress indicator on the top. That's how it could be done.

4. Prepare Users With a Custom Prompt #

If we need user’s permissions for location or notifications, need their consent, or would love to show them a few new features, why don't we politely ask users first if it would be OK for them?

Instead of showing anything disruptive immediately, we explain why we need their input before prompting any OS prompt. Users then have to activate a UI button first before interacting with the OS modal. At least a modal wouldn’t come as a big surprise, and is likely to have more positive responses.

Lime never shows OS prompts for permissions or notifications right away: it always prepares users with a well-integrated and clear messaging. It’s only on click that an OS prompt is displayed. That’s polite and respectful.

Wrapping Up #

If a feature is obvious, you might not need to explain it at all. As it turns out, the more integrated and "regular" a button appears, the more likely it is to be perceived as an integral part of the interface, and hence be used. Instead of highlighting the new feature, make it more subtle.

A "new" badge along with a very subtle background change might be perfectly enough. A single popover at the bottom of the screen might also work well. Anything beyond that might not create the desired result. And: as Adam Fard suggests, educate users incrementally, by structuring your suggestions in bite-sized chunks, so that users find them easy to learn.

Useful Resources #

Mobile App Onboarding, by Nielsen Norman Group
UX Onboarding Patterns, by Eve Weinberg,
UX Onboarding Checklist by Adam Fard,
UserOnboard.com

Never Hide Critical Navigation On Mobile

Vitaly Friedman — Mon, 26 Dec 2022 00:00:00 +0000

Every usability study reveals the same story: hiding important navigation is harmful, especially on pages where people tend to navigate a lot. In fact, digital experiences typically have two kinds of pages: navigation pages and content/task pages.

Navigation pages are the journey. There users spend most of their time looking for the next step, exploring and relying on menus, links and buttons. Hiding navigation there is harmful and counter-productive. In fact, we need to show as much forward-facing navigation as possible.

Content/task pages are the destinations. There users spend most of their time consuming content, reading, examining, comparing, completing tasks, but not navigating. Hiding navigation here is sensible, but there still might be some critical navigation to display — table of contents, progress steps etc.

If navigation is important, we need to show it — especially on mobile. Let’s explore a few simple techniques to make it work.

1. Use a Billboard Pattern #

Display important actions as cards or large buttons in a grid. More important sections would be displayed at the top of the screen and take more size — similar to a billboard.

Examples: Koreapost.go.kr and Sparkasse.de.

Scatter the navigation across the logo in the header, or dedicate an entire bar to display important navigation items. If you don’t have a lot of navigation, this might work well.

Examples: Moma.org and Typography.com.

Sometimes we don’t need to show content on navigational pages. Instead, we can prioritize navigation, and display options as a list of large clickable cards.

Examples: Auswaertiges-amt.de and NHS.uk.

4. Use Progressive Disclosure To Show More and Less #

Display as much as you can, but then allow users to quickly see more navigation options if needed. Important items should be visible at all times.

Examples: Arbetet.se and TheGuardian.com.

Important items can also be visible at the bottom permanently, especially for items such as tracking delivery on a postal service website, or buying tickets on a museum website. Beware: they can quickly get annoying on content/task pages, so they could be smaller there.

Examples: Posturinn.is and FransHalsMuseum.nl.

Cards take quite a bit of space, but links are easier to arrange. Ideally use just one simple column and two if you absolutely must. Each link must look like a link, and have active and focus states.

Examples: Unegui.mn, UAntwerpen.be.

Sometimes users need to navigate sideways, exploring a similar section. For important navigation, show it at the very top of the page. Surely it takes space away from the content, but if it’s frequently used, it needs to be visible.

Examples: Gov.uk and Govt.nz.

8. Keep the Table of Contents Accessible For Long Documents #

If a page is a part of a guide, or it contains many sections, include a table of contents on the top of the page (as an accordion), or at the bottom, revealing it as users start scrolling up.

Example: Nejm.org.

Wrapping Up #

Never hide critical navigation. Hamburger menus are often cluttered closets of our interfaces. And if something is important, we usually keep it close, nearby and visible, right in front of us instead of hiding it away.

So show navigation when it matters and hide it when it doesn't. And avoid hamburger menus if you can.

Designing Multi-Lingual UX

Vitaly Friedman — Mon, 26 Dec 2022 00:00:00 +0000

If you ever had to design a multi-lingual website, you probably know the drill. Usually it’s not just a matter of translation. Eventually, labels get too lengthy to work everywhere, and we need to dedicate a lot of attention to currencies, dates, different word order, pluralization, colors, and gender pronouns.

We need to think about how to stress test our designs in various contexts, and a proper localization strategy is needed as various versions of sites will be ready at various times.

Designing a language selector isn’t as straightforward as one might think. We’ve just published a comprehensive UX guide on just that.

1. Defensive Design Mindset #

Internationalization is hard. As we rarely know how much content will go into every given components we need to design with a defensive mindest in mind. That means considering special use cases and edge cases early.

Defensive design helps us stay on track when we don’t know in which context our design will be used. Image by Ahmad Shadeed.

These are the questions I ask myself when working on any multi-lingual website:

What if we double the number of navigation items?
Can we use a show/hide pattern to show less if we need to?
What if the headline is much longer, or much shorter?
What if all images/videos have a wrong aspect ratio?
Do our fonts support accent characters?
Can we serve different illustrations to different audiences?
Is our code base prepared for right-to-left interfaces

Surely we need to first know what countries we are designing for. In her wonderful talk on International Is The New Mobile First (video, 50 mins), Robyn Larsen highlights how much attention we need to spend to everything from wording to photography when preparing a product for a new market.

A reliable way to stress test just how defensive an interface actually is, is pseudolocalization — and that’s probably one of the first techniques that is likely to come up in conversations about multi-lingual UX.

2. Testing With Pseudolocalization #

With pseudolocalization, we test an interface before a translation is ready. We accent each character yielding a visibly different but still legible string. For example, French texts are on average 20 percent longer than English ones, while Japanese texts are 30 to 60 percent shorter. So we can simulate translation-induced expansion and add extra characters and make each word 40-50% longer to see if the layout still works well.

Localizing Slack, a lovely case study on internationalization at scale.

Personally, I always try looking into very long and very short titles, extremely wide and extremely tall images and the content in German, Cyrillic and Arabic or Hebrew. This requires also to observe if dates and currencies are displayed properly, and ideally hand over the design to a native speaker to see if the leading and whitespace work well as well.

Pseudoloc, a Figma plugin, inspired by Netflix case-study.

There are a few tools for pseudolocalization. For example, Pseudoloc and Psuedo Localizator are Figma plug-ins, and Pseudolocalize! is a free online tool that does the same thing for any paragraph of text.

3. Designing For Global Audiences #

To be prepared for the unexpected, it’s a good idea to leave enough room for longer translations and avoid putting text in narrow columns. We have to be careful with our icons and metaphors. But sometimes we need to go a little bit beyond that. We also need to address cultural characteristics in UX.

Different audiences are different. Jenny highlights just how different the cultures are around the world.

In her incredible two-part article series “UX Design Across Different Cultures”, Jenny summarized what she has learned from designing for various cultures. Once you know the culture of the audience that you are designing for, your design decisions will have to consult and address cultural characteristics of that audience. Jenny also goes into detail of conducting usability tests, measuring data, and localizing copy.

Part 2 looks into researching mobile device usage in emerging markets, researching local UI patterns and creating personas of local users. Jenny also highlights many of these findings in her talk on Design for users across cultures (video, 35 mins).

Wrapping Up #

Personally, the most important thing to design for global audiences is to question every single assumption made in the interface. The wording, the buttons, the visuals, the layout. Our design has to be defensive and flexible enough to accommodate for major changes across languages and cultures.

That’s not an easy fit, but it has a lovely side effect of helping us migrate our design to any other environment with a bit more confidence. And even if the interface will not be translated to other languages, it will be resilient enough for any kind of edge cases that happen in every single project. And that’s something worth striving for.

Designing Better Links UX

Vitaly Friedman — Mon, 26 Dec 2022 00:00:00 +0000

Too often, links on the web don’t get the attention they deserve. Their appearance often follows the brandbook, and interaction seems to be so obvious that it doesn’t even come up in design discussions. Let’s fix it — and explore how we can make links better.

1. Link Underlines Remove Ambiguity #

Link underlines are often dismissed, yet they are the clearest and simplest way to help users discover links. By default they can be too thick and appear too heavy, especially when in mega-drop-down menus, but we can make them a bit thinner with the text-decoration-thickness property in CSS.

For Vodafone, we can simplify the design quite significantly by adding link underlines where they belong.

What is a link and what isn’t? Instead of relying on arrows, we can use link underlines: it’s less clutter and more obvious this way.

In the example above, rather than using arrows to indicate a link and mixing them with chevrons indicating accordions, we can underline links and remove arrows altogether.

This helps especially in navigation menus when we want to make it very clear which action opens an accordion and which action drives users to a category. Underlining links often solves this problem for good.

2. Focus and Active Styles Boost Confidence #

It’s not uncommon for users to get lost on a page. Not because the page is confusing, but because the UI doesn’t provide any noticeable feedback upon user’s action. That’s when people accidentally click twice or refresh the page, and when they experience rage clicks and rage taps.

NHS.uk prominently highlights focused and active states with a bright yellow background and a slightly thicker underline.

Keyboard users often have issues following links as they tab through them; mobile users can’t see past their non-translucent fingers, and often it’s not clear if you actually missed the target, or it’s just the slow connection. Focus and active styles help in these situations. Bright yellow background is usually a good choice as it helps the link stand out.

There are ways of designing better focus styles. In Tips For Focus Styles and custom :focus styles, Nic Chan and Lari Maza highlight a few helpful tips on how to improve focus styles with better affordance and a bit of padding, offset, and outlines.

3. There Is No Harm in Visited State #

Is it a good idea to communicate to users that they’ve visited a link already? It might be, especially when we expect users to click through many links in a list. If anything, a visited state will help a user to re-find a section that they’ve visited before.

Gov.uk changes the color of a link to violet with a heavier underline for visited links, while the other links are blue — except the focused one.

4. Meaningful Link Labels and Link Accessibility #

Link labels matter. The more contextual they are, the more obvious it is for users to make a choice between navigation options. Thoughtfully composed links express respect to readers, whereas jumbled-up ones cause confusion and suspicion. For example, “click here” and “this link” are ambiguous and confusing choices that miss context.

A well-composed link should make sense alone. In this case it doesn’t.

As Slava Shestopalov writes in his article, concise self-explanatory phrases inform people about the destination; they are actionable and clear. A well-composed link makes sense out of context and typically combines a topic (e.g. security, brand, marketing) and the format (questionnaire, request form, guideline, policy etc.).

Well-composed links typically avoid generic words like 'this' or 'here'.

It’s also a good idea to indicate if the link will guide users towards a PDF or any other downloadable file, so indicating the file size, or the types of content available (HD, SD) is reasonable as well.

5. Should Links Open In New Tabs By Default? #

Probably not. Ideally we would leave it to users to choose how to open a link, as they might want to open an external link in the same tab, rather than seeing it appearing in a new tab and then returning back to close the old tab.

If we have an external link, we can indicate it with an icon, but open it in the same page by default. From Smart Interface Design Patterns.

In general, it’s a good idea to always open links in the same tab, unless you are absolutely certain that the user will appreciate a new tab. This makes sense when a click on a link would disrupt a process (e.g. help-links), or a user might lose data, or it’s a link to an external downloadable file. But in general: leave links be, and let users choose how to open them.

Wrapping Up #

An underline is the clearest indicator of a link. Surely they aren’t always necessary but they are always helpful. For navigation menus, we can use links to distinguish between accordions and category links. With :focus, :active and :visited states we make it clear where a user currently is, where a user has been, and where they can navigate to.

Meaningful wording aids accessibility. The more obvious it is where a user can go without reading the entire sentence, the faster the navigation will be. However, links opening in external pages by default would slow them down and confuse them, so opening links in the same window by default is a safer bet.

Language Selector UX

Vitaly Friedman — Mon, 26 Dec 2022 00:00:00 +0000

Imagine that you’ve just arrived to Tokyo. Full of impatience and excitement, you are just about to hit the road, yet there it comes: an urgent warning from your mobile provider, nudging you to top up your dwindling balance.

There isn’t anything cryptic on Stripe, with a popover, allowing users to jump to a different country in the footer.

With some justified concern you head to the website, just to be redirected to the Japanese version of the site. You can’t read Japanese just yet, yet there is no option to change the location, and there is no option to change the language either. As the data keeps dwindling, you juggle between auto-translation and your VPN options — just to run out of data in the middle of the session.

So, how do we fix it? By decouping presets, allowing for overrides and providing users with choice.

Decouple Location and Language Selection #

Many websites rely on an assumption that location, language and currency are tightly coupled. After all, if a user chooses a location in Germany, they are very likely to prefer German language and see prices in Euro. However, this is based on assumptions that would work for many people, but break the experience entirely for some others.

The language and country selection are decoupled on AirBnB. Large view.

AirBnB suggests languages and regions in groups, but also allows users to adjust their preferences and choose a language and region of their choice. Additionally, users can opt-in to automatically translate descriptions and reviews to English.

SSGA goes an extra mile with settings for roles and types of sites. Large view.

Some slightly different preferences can be defined on the State Street of Global Advisors. On the first visit, a modal window appears explaining to users some of the assumptions that the interface is making about the location and their interests. Within the modal window, users can change a location, specify their role and choose a preferred type of the site for their visit.

Use Flags For Countries, Text Labels For Languages #

When designing a country selector, it feels almost natural to think about the flags they are represented by. After all, compared to just plain text, it should be much easier for users to locate the icon that they can immediately recognize. This is indeed true, however, as James Offer has suggested in his wonderful blog on Flags are not languages, flags are specific to countries, but languages often cross borders.

To avoid misunderstandings, make sure that you use flags if your users need to select a specific country. However, if you’re providing users with a choice of a specific language, then flags are probably not going to work well. There, an autocomplete with all available countries and labels for languages written next to them might work better.

BOL shows a modal window asking for a language and a destination separately. Large view.

Flags for countries, and plain text for languages. Everything seem to be about right on Bol.com. The country selector (with a flag) is located in the right upper corner, where most users expect it.

Admittedly, modal windows are rarely a good idea. They are disruptive and annoying as they require immediate attention. They might be appropriate when we need to draw user’s attention to important details, but nonmodal dialogs are less intruding and more friendly.

Patagonia uses a nonmodal window, and never blocks scrolling or copy-paste. That’s friendly. Large view.

Upon website entry on Patagonia, a non-modal window appears in the left bottom corner. Users can choose location and language and save their preferences as a cookie. They can also always bring the selection back by accessing the preferences bar in the footer.

Navigating dozens of options in a small overlay, or even a large modal will be a bit cumbersome and require a healthy dose of scrolling. So it’s not very surprising that often websites present all available options on separate pages, broken down by regions and sometimes illustrated with country flags.

Oracle with a click-through menu located in the footer of each page. Large view.

However, a slightly different kind of country selector on Oracle: a click-through menu that covers the page, with all countries grouped, rather than displaying a standalone page. That’s a very compact and straightforward solution.

Use Autocomplete Suggestions #

Getting autocomplete right isn’t an easy task. For it to work well for a country selector, we need to support frequent abbreviations, endonyms and shorthands for all available options. And then, of course, our autocomplete suggestions should display both countries and languages, with an option to choose one option or another.

IKEA goes big with its country pre-selector on its homepage. Large view.

IKEA doesn’t use an automatic redirect, but a generous country selector that understands domains, endonyms and languages of the largest countries in the world. The “Go shopping” button might be the biggest button in the world and might deserve a spot in the World Guinness Records Book. Unfortunately, on the site, you can change the country, but not always the language.

The Globe Icon Instead of Flags #

Since flags can be somewhat problematic, what would be a reasonable alternative to them? We can use icons such as “Globe” or “Translate” to indicate the choice of locales. Flags do work slightly better, but both icons are fairly well understood and avoid all the issues outlined above.

Atlassian nudges users to switch to another language, based on their IP. Large view.

On Atlassian, the language selector is tucked at the very end of the page in the footer, with a globe icon indicating the selection. However, if the user with a different browser language preference enters the site, it suggests to change the language at the very top of the page, with a globe icon appearing there, too.

Wrapping Up #

The country and language selector might appear like a quite trivial task, but there are plenty of fine details that make or break the UX. When designing one, always decouple presets and reduce assumptions. Users expect the language selector to be located in the header or in the footer of each page, and they often watch out for flags, “Globe” or “Translate” icons to find it.

If you have just a few languages, a drop-down overlay might be perfectly enough. If you need 10–15 languages, perhaps it’s worth exploring the option of a non-modal overlay with autocomplete. If there are even more options to display, consider using a standalone page, with countries grouped into tabs or accordions.

Filtering UX

Vitaly Friedman — Mon, 26 Dec 2022 00:00:00 +0000

Filters are everywhere. They are used in pretty much every interface that features more than a handful of data points. It’s not necessarily just the sheer amount of data that is difficult to make sense of though; it’s the complexity and lack of consistency that the data usually entails.

That requires some solid filtering — such a common scenario in data grids, enterprise dashboards, vaccine tracking and public records registries. Too often, however, filters require too much work — too much scrolling, too long to wait for the results to come back, too many pages to browse through.

So if we wanted to improve our filters, how would we do that?

Never Auto-Scroll Users On A Single Input #

You probably have been in a similar situation before. On Dell.com, as you choose your laptop features, only a single input is registered at a time. If you happen to be selecting multiple options quickly, only the last input will be applied.

Dell’s filters aren’t very responsive. If you tap fast, you’ll need to have a bit of luck for all your filter inputs to be registered successfully.

And as an input is registered, the page refreshes, jumping the customer all the way to the top of the filtering sidebar. That means that the more filters you want to use — and usually navigate from top to bottom — the more you’ll have to keep scrolling down to find the right filter. That’s annoying.

In fact, even if you’d like to specify just 6–10 features this way, you’ll need to embark on a quite stubborn scrolling fight against the auto-scroll, with only a single filter registered at a time. It is possible to tap or click on multiple filters at a time, but in this case unfortunately the UI won’t respond as expected.

Never Freeze The UI On A Single Input #

Every time we freeze the UI on a single input, we actively slow down our customers in expressing their intent. We actually make it a bit more cumbersome for them to specify what they are interested in, prioritizing the display of results over the input. This seems to be a wrong prioritization though. Let’s take a look at the example below.

It’s common for customers to want to set multiple filters right after another. Freezing the UI on every single input slows them down and makes it just a bit more difficult. Example: Sears.com.

At Sears.com, every time a selection is made, not only is the UI fully blocked; the users are also pushed to the top of the page. That’s especially frustrating for filters that include accordions (“see more” link in “Brand”, for example). With every new filter, the user has to scroll down and open the accordion to find that particular attribute that they want to select.

It’s remarkably common for customers to add multiple filters quickly, sometimes in the same category. The behavior of the UI doesn’t support this intent well. What’s the alternative? Manual "Apply" button? That’s one option. But we could also do something else.

Decouple Filters and Search Results #

We could decouple the parts of the UI and render both of them separately. In that case, on every filter input, matching results could be updated in parallel, while the filters always remain accessible and at the same place. With every new filter input, the user would see a flash of new content streaming in.

Filters and search results decoupled on University of Stockholm.

The University of Stockholm above shows that pattern in action. As we select filters in the left sidebar, they get applied in the background while we can keep selecting more and more filters should we choose to do so. The product list gets updated at the same time. There is never a disabled state as new content appears in the list of matching results every time the data gets back from the server.

It’s worth emphasizing at this point that every input in the filters area needs to be registered by the UI, and then applied to the product list. We’ve noticed that for many customers that’s an expected behavior, unless you keep a floating “Apply” button close to the filters area.

Display Filters Above The Results #

To avoid layout shifts altogether, we can display applied filters *above the product results. That would keep the filtering area stable and predictable during the entire user interaction. In fact, it doesn’t have to be visible at all times. Crate & Barrel, in the example below, allows customers to hide and show filters on demand, while applied filters are added to the dedicated area above products. Note that an option to clear all filters is available as well. (The product page has changed since the video was recorded though.)

Another option is to turn all filter sections into overlays and display them on tap/click above the results. In fact, you could even use floating filters, so as a customer scrolls down the page, the filters are still accessible all the time.

An example of this pattern is Adidas (see the image below). The filters bar is persistent; even as users are scrolling down the page, the filter overlay won’t close automatically — it requires user’s input, again handing over the control to the user.

However, it does close automatically once one of the filters is selected. If the user wants to select multiple filters, they have to re-open the same filter group over and over again. Keeping the filters visible until the user chooses to apply them might be a better idea. Still, the result: no layout shifts, no frustrating scrolling in narrow corridors, and filters are always accessible.

A Case For The "Apply" button #

It almost feels a little bit archaic to have an “Apply” button for filters in times when we are getting used to seamless and smooth interactions. However, if we want to drive customers towards a manageable range of relevant results, there is hardly a better way of doing so than displaying the number of results as soon as possible.

Everything in one: on Galaxus.ch, filters are displayed above product results, a filter overlay appears on tap/click, and the overlay doesn’t disappear unless the user chooses to dismiss it.Everything in one: on Galaxus.ch, filters are displayed above product results, a filter overlay appears on tap/click, and the overlay doesn’t disappear unless the user chooses to dismiss it.

We could allow customers to refine filters until they get to that range. Galaxus.ch provides a first-class experience when it comes to filtering. The filters are displayed above product results; a filter overlay appears on tap/click. No slowdowns, fast response times and a lovely integration of active filters with the filters area. A great reference example that is worth considering when designing any kind of filter.

In general, having an “Apply” button along with real-time updates of the content area seems to be working best. It really combines the best of both solutions: showing results immediately when they arrive, while keeping filters accessible at all times.

Avoid Split-Screens On Mobile #

The issues that we’ve explored in the article apply equally to large and small screens. However, on small screens, and especially on slow connections, these issues become even more critical. Most of the time, interfaces tend to block the entire UI on a single filter input, causing massive delays for customers on the go.

The usual suspects: blocking the UI and splitting the screen: Walgreens, Nordstrom, Crutchfield. (Large preview)

In general, though, it might be a better idea to experiment if a full-page overlay for filters would perform better. It gives more space to experiment with a multi-column view, or perhaps even display a swipeable area to choose filters without having to move between separate pages.

In fact, using accordions that could collapse and expand instead of bringing the user to a separate page might be a good idea — similar to what we’ve discussed with mega-dropdowns.

Better options for displaying filters: Myntra and Tylko. (Large preview)

Good reference examples: Galaxus.ch, Wayfair and Lacoste. (Large preview)

Having an “Apply” button in all these examples is a good idea, and you can make it slightly more useful by adding the amount of products as a label on the button and keeping the button sticky at the bottom as the user is scrolling down.

Wrapping Up #

Too often the filtering experience on the web is broken and frustrating, making it just unnecessarily difficult for customers to get to that shiny comfortable range of relevant results.

When designing the next filter, take a look at some of the common issues that you might want to avoid, and hopefully avoid all the frustration that comes from broken and inaccessible implementations.

Customers often want to set a number of filters of the same type. Never auto-scroll users on a single input and never collapse a group of filters automatically.
Never freeze the UI on a single input, and never make your customer wait for an interface to respond back when setting filters.
Always update filters and show results asynchronously, so that on every filter input, matching results could be updated asynchronously, while the filters always remain accessible and at the same place.
Always avoid layout shifts on filter input and consider displaying filters above the results.
On mobile, “Apply”-button could be sticky at the bottom of the screen. Update the count of products and show them on the button.

How To Improve Time Estimates For Designers

Vitaly Friedman — Mon, 26 Dec 2022 00:00:00 +0000

To get better at estimates, we need to know just how much productive time we have, and how much work we need to complete. Both need a lot of planning to avoid surprises down the line.

There are many unknowns that shape your timing: we need to discover them first. Illustration by José Torre.

Estimate with 6–6.5 productive hours per day #

Just because we have around 8 working hours a day, we aren’t actually working productively during that entire time. 8 hours don’t account for so many things, from routine messaging on Slack and urgent errands to sick days and interruptions.

Break down the scope of work into smaller units of work #

It pays off to invest enough time into writing and signing-off a detailed scope of work, explaining:

how you understood the problem,
what the solution requires (with a breakdown of tasks),
what your assumptions are,
how you are planning to solve it,
when customer’s (timely) input will be needed,
what the milestones and timeline are,
what delivery date you commit to (for the fixed scope),
how the pricing and payment are going to work.

Estimate in ranges, not precise numbers #

Many companies estimate work using story points, and it helps assess complexity of a task at hand. Whenever estimating, stay away from precise numbers such as 6h or 1 week — always estimate in time ranges to consider both optimistic and pessimistic outcomes. In reality, most of us aren’t pessimistic enough.

Always add at least 15% of buffer time #

The work is rarely done perfectly on time. You might need to cut corners or reduce the scope of delivery for the first prototype. Account for that time and add buffer time to your estimates. If you are an optimist, add 15%, if you are a pessimist, add 25%.

Explain that late changes are expensive and cause delays #

Make sure that everybody understands that you are estimating delivery for a fixed scope of work, and late changes will be expensive and might delay the delivery. You might want to repeat that last sentence multiple times. Make sure that you get a clear sign-off from your client (preferably with a signature).

Have a script ready for conversations with clients #

Clients don’t know how you work, so we shouldn’t expect them to know the implications of late scope changes and delays on their end. For every step of the process, make sure to mention — in email, calls, meetings etc. — that late scope changes are very expensive, and when you will need a timely input from them.

Every new team member speeds up the process by 1.5–1.8× #

The more people are involved, the higher is the cost of communication. Smaller teams often work more efficiently, but they also need to have meetings, discuss, argue and plan. You can’t double the speed of work by adding another person to the team.

Life is full of surprises: budget accordingly #

Estimates often assume linear, focused, uninterrupted work. They assume regular scenarios and a predictable process. But life isn’t like that at all. Plus, we are very bad at predicting future. Feel free to underpromise and overdeliver, but always include the cost of over-delivery in your estimates.

Happy estimating, everyone!

Error Messages UX

Vitaly Friedman — Mon, 26 Dec 2022 00:00:00 +0000

When we design interfaces, we rarely think about error messages first. But a strategic and thorough design of these messages can be critical for businesses — especially if they struggle with high abandonment. Error messages can make or break the experience in situations when things go south.

Errors are everywhere, and so are error messages. They are of course common in web forms, but also in complex tables, contradictory filters and failed interactions. They can be small error notes and large error summaries; short tooltips and lengthy toast messages. So how do we choose the right ones? Let’s start from the basics.

1. Never Rely On Color Alone #

With error messages, we almost subconsciously think of bold red text. That’s indeed common, but often not enough to indicate to users that something is wrong.

The Error message component on Gov.uk can’t be improved much: the message is clear, fair and with an icon pointing attention to the message.

Due to color vision deficiencies, it’s a good idea to always complement error messages with an icon, e.g. white exclamation mark on a red background — next to the error messages, or within the input field.

Error messages in the Carbon Design System by IBM. Error messages appear above the buttons on tap/click.

As you can see in the first example, we can highlight the entire section, along with the field, label, the hint, the error message and the input field — e.g. with a thick vertical line next to it. We might also display an error summary on the top of the page, with the links to the problematic areas in the form.

2. Never Cover User’s Input #

When we display error messages, we convey to users that there is a problem, but also try to guide users to a solution. This, however, requires the ability to consult the error as the error is being fixed. In other words, users would be able to edit the input field while also reviewing the error message(s) provided to them.

When inline validation meets error recovery. A common example when the message covers the content. Via UX Design World.

So far so good. However, things become quite complicated once we also have a tooltip in play. When a tooltip is open, users might lose sight of both the error message and the input. Should they desire to be able to see all 3 pieces of information at once, they’d be out of luck.

When a tooltip blocks the content, an example from the Carbon Design System.

We can fix it relatively easily. First of all, we avoid tooltips that open on hover, and display the tooltip text only once tapped or clicked. That means that a tooltip text will never disappear automatically, and will have to be closed manually.

Then, we use the details component and inline accordions as an alternative to tooltips. Hence, we make space for the content of the tooltip to expand between the label and the other content, so nothing will be covered. The error message would appear at all times as well, next to the input field.

The details component, with the details appearing on tap/click.

This way, we show all 3 pieces of information at the same time — and users always have a choice to select what exactly they’d like to see. Is it too much? Maybe. But that’s a great option to keep in mind: at least to always display the input field and the error at the same time without them being overlapped by the tooltip.

3. In Forms, Display Error Messages Above Input #

Now this might sound a little bit confusing at first. Usually error messages are sitting conveniently under the input field, or perhaps — less frequently — on the right side of it. As it turns out, there are a few accessibility issues that come as a cost of these conventions.

Users of a magnifying software might miss the error message when it’s located on the right,
On mobile, users might not be able to see the error message under the input because it will be covered by the virtual keyboard,
When editing input, error messages might be covered by browser’s autofill or input’s autocomplete suggestions.

Displaying error messages above input fields typically helps us avoid accessibility issues listed above. The cost of it, though, are layout shifts: with every new error appearing dynamically, the entire form has to shift vertically as we need to make space for the error message to appear. But sometimes it might be very much worth it.

4. In Tables, Display Error Messages Inline #

When displaying error messages in tables, it might be a good idea to consider alternative approaches as otherwise we would end up with a lot of layout shifts for each row.

One of the simpler patterns is to display the error message in the same row where the content lives. In that case, the error message is more likely to live under the input field, not above it. Lengthy error messages could be collapsed and expanded with an accordion.

Error messages could live in the same row where the erroneous content lives. Image source: UX Design World.

If the same error affects multiple rows, we might want to highlight the rows that contain errors and display an error message at the very top of the page that would explain the error and what needs to be done to fix it.

If an error appears multiple times, and its simple to explain, it might be a good idea to show it on the very top of the page. Image source: UX Design World.

5. Don’t Rely on Toast Error Messages #

But what about good ol’ toast error messages? Those animated notifications, informing users about change of status of the system with floating messages. They might be uncommon for forms, but they frequently appear in tables and enterprise dashboards.

There are a few common usability issues with toast error messages:

Users often don’t get a chance to fully read or understand the error message before it has disappeared, and there is no way to restore it or keep it floating.
Toast messages typically appear on the edges of the screen, and usually it’s quite far away from the erroneous input. There is a disconnect between the error message and the input, and it’s rarely possible to read the error message and correct the mistake at the same time.
Lengthy toast messages usually block large areas of content that a user might be relying on — and potentially even the input that has caused the error.
Toast messages need to be announced to screen reader users while also allowing them to bring the focus back and forth between the error message and the erroneous input.
With toasts, we usually don’t have enough space to provide a detailed help using images or videos, and have to rely on plain text and links to external help pages.

This might not be ideal: error messages appearing as toasts in a complex UI.

If anything, toasts should be persistent if displaying information that can be acted upon, and users should be able to manually dismiss the notification.

Personally, I’d definitely stay away from error messages as toasts, even if they are persistent. The more we can connect an error with its cause, the less likely it is to be overlooked. And the better we can explain how to solve the error next to its cause, the faster users will understand what they need to do.

6. Allow Users to Override Error Messages #

No single validation library will be extremely reliable and bulletproof for all the edge cases, so eventually some percentage of your customers will be left out there in the woods, trying to figure out what to do next to proceed. That’s quite suboptimal.

Aggressive validators cost money. Especially when they come in tandem with disabled buttons that literally block users without telling them what exactly needs to be done to fix the issue.

Overriding address validator might be a very good idea.

For cases when a validator might be too restrictive, we can allow customers to override validator’s warning. We will get some wrong addresses as a result of that. But as a business, we need to measure just how much money we are losing due to increase in service desk inquiries vs. how much money we gain by allowing people to find a way to proceed even although the interface doesn’t want to play along. More often than not, it’s worth it.

While this pattern works flawlessly for address input and telephone input, it probably won’t work for any input that needs to follow a particular convention — such as the length and checksum of an IBAN number or a credit card number. There, instead of giving customers a carte blanche, we need to meticulously review the input and guide them towards what exactly the problem seems to be. And help them resolve it.

Wrapping Up #

At the first glance, dealing with error messages might not sound like a big deal. However, as we dive into fine details, there are plenty of considerations that might either cause high abandonment or help people resolve issues quickly.

With these guidelines, we should be better off when boosting our error messages UX. And if you can’t really do much around the way errors appear in your product, explore what you can do to replace generic error messages with helpful ones. This might be a small change with a huge impact that will eventually show up in large business KPIs dashboards.

Disabled Buttons UX

Vitaly Friedman — Mon, 26 Dec 2022 00:00:00 +0000

Admittedly, there might be very good reasons for making buttons disabled by default, but there are also scenarios when disabled buttons turn out to be a disastrous design pattern. Let’s look into common usability issues with disabled buttons, how to fix them, and when disabling buttons makes sense.

One of the many. Usually buttons are disabled because the interface requires user’s input. Example: Swedish public transportation website.

The Downsides Of Disabled Buttons #

As designers, we want to make it more difficult for our users to make mistakes and ensure that the input is perfectly correct before the data is even sent to the server. But these good intentions also bring along pitfalls.

Disabled buttons don’t explain what’s wrong. They communicate that something is off, but very often that’s just not good enough. As a result, too often users are left wondering what’s actually missing, and consequently locked out entirely.

And then there is the question of timing. At which point should we enable a disabled button? Most implementations enable the button only if all required input seems to be well-formed, or/and has been verified by an inline validator. But sometimes inline validation is too aggressive, and it’s never bulletproof.

You just want to fix an error in the first input, but then you are penalized in the second. An aggressive inline validation in play here.

Did you have situations when your address didn’t validate although you’ve been living at that address for years? What about phone numbers locked into one specific country, although you have a number from another one? Technically, we should still be able to proceed, but we can’t.

When Disabled Buttons Work Well #

Imagine you want to purchase a pair of jeans online and as you add the item to your cart, you realize that it is no longer available. Making the “add to cart” button disabled when an option isn’t available is reasonable to avoid confusion.

Or if you’re making a transfer from your bank account and accidentally press the “confirm” button twice. A disabled button could prevent this from happening and indicate that the state has changed and that nothing else needs to be done for the operation to proceed. Communicating that something isn’t possible could also come in handy to avoid wrong purchases or double-bookings or to validate magic sign-in and SMS code.

Upon click, Wise disables the “Convert” button without changing the text, but adds a loading indicator and changes a mouse pointer to indicate the change of state.

When an option or a feature isn’t available or something is happening in the background, we need to communicate it early and clearly. A visible change of the button helps there, but we can also explain why the button is disabled and what exactly is happening. For example, we could change the label on the button and add a looping loading indicator to make it more obvious what exactly is happening.

Making Disabled Buttons More Inclusive #

So what if our implementation relies on disabled buttons? How can we make sure to not leave anyone out? In her article “Making Disabled Buttons More Inclusive”, Sandrina Pereira highlights a couple of excellent techniques to make disabled buttons better — by changing the cursor, showing tooltips, or using ARIA live regions to announce dynamic content.

We can use aria-disabled attribute instead of disabled to keep disabled buttons focusable, and show a tooltip on tap/click. By Sandrina Pereira.

An alternative to the classic tooltip could be to guide the user to the errors in the form, either with a link to the error summary at the top of the page or with jump-links to specific input fields that seem to contain errors. And we could just include a hint next to the disabled button to explain why it’s disabled.

Always Provide A Way Out #

It’s incredibly difficult for an interface to predict all the options that customers might want to choose ahead of time. So in the case of an ill-formed input or an error, we should provide a way out to complete the form. A useful technique is to also add a “way out”-link under the hint that explains what’s wrong. The link prompts the customers to get in touch with the customer support in case they can’t proceed.

A 'way out'-link in action. It sends all customer’s details to the customer support, so you can get back to them. A mock-up based on Sj.se.

An Alternative To Disabled Buttons #

To avoid all the hassle customers have to endure with disabled buttons, we could make the experience much more straightforward by keeping the “Continue” button accessible at all times, and using the click to communicate to the user what’s actually wrong.

Keeping the buttons enabled, and showing errors on click. A mock-up by Jordan Moore.

A good overall strategy that always proves to be working without any usability issues is to validate the input on submit, explain that there are errors and show how many errors there are (as a hint or as an error message). If there’s only one error, point users directly to the input field that contains the error (with a text link), or, if there are more errors, show an error summary on top of the page and link to it on submit.

Validate on submit, and show error summary on the top. Gov.uk.

Simple, straightforward, accessible, easy to implement, and without any reliance on code to be working flawlessly to bring a disabled button back to life.

Wrapping Up #

If you need to use disabled buttons, consider ways to make them focusable and useful by also making them more inclusive and providing a way out for customers to send all the details to the customer support.

If you don’t need to make the buttons disabled, consider validating on submit and guide users directly to errors with sensible error messages. Either way, inline validation can be helpful in giving users a sense of progress as they are making their way through the form, but make sure that users can proceed even if inline validation fails.

Design Metrics and KPIs

Vitaly Friedman — Mon, 26 Dec 2022 00:00:00 +0000

Many organizations focus primarily on data coming from their analytics. This usually includes beautiful dashboards with data points and graphs on bounce rates, exit rates, time spent on site, navigation funnels and most used features or pages. Design KPIs are driven by numbers that don’t have any context and relate to an "average user" that doesn’t really exist.

That’s a very traditional approach that has its roots in an assumption that the more users stay on the site, the more satisfied they are with the experience on the site. As it turns out, often the opposite is true.

Don’t get me wrong: analytics is useful to identify trends and changes in user behavior, but it alone doesn’t provide us with insights on what exactly users are actually doing on the site. For example, some tasks might require a lot of reading and a lot of user’s input to be completed, but for others just a brief scan of a page might be perfectly sufficient to get a big picture.

Some users might find an answer to their question already in a rich snippet provided by a search engine. And on some pages, the content might be organized so well that there is absolutely no need to linger on the site longer than a few seconds.

With a better design, fewer people get lost, and more people find what they need. So it shouldn’t be surprising that as website owners, we might end up with reduced traffic and increased bounce rates. Usually this would be quite a warning sign, but it shouldn’t be — as long as we increase user satisfaction and reduce task completion times.

In my work, we tend to define design KPIs by focusing on two fundamental metrics:

how many people find what they are looking for,
how much time they need to find what they are looking for.

In detail, these attributes could be measured and tracked across a variety of user’s touch points:

top tasks completion rates for internal and external users,
top tasks completion times on or off the website,
overall satisfaction with the content and the experience on the site,
rate of errors and mistakes in navigation, search and data input (e.g. filters, forms, search queries),
accuracy of data successfully submitted by users (how difficult do we make it to make mistakes),
frequency of dead ends (404s, empty search/filtering results, lock-out rates in forms due to poor validation),
time to production, or how quickly users can publish quality content that matches all content and design requirements stipulated by our guidelines,
time to bugfixing, or how quickly teams can fix an issue surfaced in a production environment,
engagement rate, e.g. how effectively do we communicate messages to users or inform them about our campaigns (CTR rates, time to share).
web performance, in terms of response times, Core Web Vitals, response to search/filtering queries, autocomplete etc.,
search-engine friendliness, e.g. average position in search results, the amount of rich snippets etc.

Healthy business metrics mix. Large view.

To define design KPIs, we can rely on Top Tasks, the most frequent tasks that users do on a website or in an application. For usability testing, we come up with tasks and test them with the same audience segments over time (preferably at least once every 3 months). Based on that, we measure success rates and completion times.

The metrics listed above are much more focused around the actual user experience and user behavior, rather than on ambiguous data points that change heavily based on the specifics of what users are looking for and how and when they use the environment.

It’s worth noting that the definition of design KPIs should have a significant impact on how the quality of work done by content and engineering teams is measured. Rather than focusing on the amount of produced pages or websites, bounce rates or click rates alone, we should be aligned towards producing quality content that is useful for people consuming that content.

Designing Better Design Critiques

Vitaly Friedman — Mon, 26 Dec 2022 00:00:00 +0000

Design critiques often undermine trust and crush team spirit. But they don’t have to. Here are a few helpful strategies, templates and articles that I found helpful to run better design critiques.

Key Takeaways #

Explain the problem before showing any work.
Review previous findings and research.
Explain how far you are: 30%, 60% or 90% done.
Explain what kind of feedback you seek.
Start where a user starts: show entire user’s journey.
Avoid surprises and big revelations in the meeting.
Circulate a well-prepared brief ahead of time.
Discourage opinions and invite open-ended questions.
Don’t focus on the solution; focus on the problem.
Don’t reserve critiques to designers only.
Invite developers and stakeholders early.
Make critiques a weekly habit.
We are not our users.

Best critiques raise questions and reveal new directions. They avoid opinions and guidance. They end with action points that continue the process, rather than bringing it to a deadlock. And, most importantly, they strengthen the team, rather than drifting team members apart.

Useful Resources #

Six Design Critique Methods, by Noah Levin

Practical Design Critique Guide: How to Give and Receive Feedback, by Darrin Henein

How to Run an Effective Design Critique, by Katrina Dargel

A Complete Guide To Design Critique, by Jonny Czar

The Pool Rules of Design Critique PDF

Design Critique Meetings Guide (Figma template)

Remote design critiques by Aletheia D.

Anti-Behavior in Design Critiques, and How To Handle Them, by Ben Crothers

Design Critique Presentation Template (Figma)

Design Critique Meeting Figma Template, by Rodrigo Javier Peña

Design Critique Template (Miro)

Design Critique Playground Template (Miro), by Miroslava Jovicic

Design Critique Meeting Agenda, by Anthony Murphy

Book recommendation: “Content Design” by Sarah Winters

Book recommendation: ”Discussing Design” by Adam Connor, Aaron Irizarry

So, what strategy do you use when running your design critiques? Thanks for reading!

Useful Copywriting Tools and Resources

Vitaly Friedman — Mon, 26 Dec 2022 00:00:00 +0000

Copywriting is difficult. Staring at the blank screen can feel daunting, but so does finding just the right words for that landing page. Let’s take a look at some copywriting tools that you might find useful in such situations.

1. SpeakHuman.Today #

SpeakHuman.Today is a great little gem. You can generate human-centric microcopy for various purposes, from errors to confirmations messages. Not ideal for copy-paste, of course, but useful to inspire us all to write better copy.

2. UIcopy #

UIcopy.io is a useful plugin for Figma and Adobe XD that contains pre-built copy templates for your UI. It’s not generated randomly, but is curated by real humans, and often contains a personal touch. Available only with a subscription.

3. Microcopy Patterns #

Tiny Words Matter is a friendly Twitter account that provides a curated dose of well-crafted microcopy. Wonderful real-life examples and microcopy patterns.

4. UX Writing Library #

UX Writing Library is everything on copywriting gathered in one single place: books, communities, tools, online courses, podcasts, newsletters and everything in-between. A great hub to find plenty of resources around UX writing.

5. Good Email Copy #

Good Email Copy highlights examples of email copywriting, tagged and grouped, with search. There aren’t that many examples for each topic, but it might be just enough to help out once help is needed. And if you need more, check ReallyGoodEmails.com and EmailLove.

6. Ditto #

Ditto is a lovely tool that acts as a single place to manage the copy in all of its stages. It allows you to build a text component library, track all copy changes, and review and discuss edits, too.

And That’s A Wrap! #

As always, sending you a lot of good vibes and positive energy for the coming week, everyone! And of course if you could share the newsletter with a friend, or point them to this lovely website, I’d very much appreciate it. Thank you! :)

Complex Filters UX

Vitaly Friedman — Mon, 26 Dec 2022 00:00:00 +0000

Dealing with complex filters in enterprise environments can be quite a challenge. Usually we know where to place them, but not necessarily how to show them. What if you have literally hundreds of these filters? Showing them all at once might be quite intimidating, to say the least.

FinViz, a financial stocks screener, appears to be quite complex.

FinViz, a popular financial stock screener, is an example of just that. Our first hunch would be to regroup filters, break them down, reorganize, reshuffle. That’s an important step, but it’s probably not going to be enough.

Drop-downs are rarely a good idea, they are slow and perform poorly in usability tests. The sheer amount of filters is overwhelming. And choosing the right option is tiring at best.

What’s the alternative? Well, we can’t remove complexity, but we can orchestrate it better, with better design. To do so, we query user’s intent and allow them to choose filters of interest, without overwhelming them with all available options.

Query Constructor Pattern #

Financial Times Screener uses an alternative approach for their equity screener. Rather than showing all filters at once, Financial Times groups all filters into click-through menus along with autocomplete suggestions. The UI queries user’s intent first, and hides complexity by default.

FT Screener: the screener that doesn’t show it all (by default).

Users have to specify relevant criteria first, and add them to the list of selected filters before changing them in all the fine detail. Additionally, FT suggests predefined equity screens in the sidebar that people can use and adjust if needed. No drop-downs in use here.

FT Screener, with a large click-through menu of filters that can be added to the list.

Horizontal Layers #

A common way to deal with complex filters is to allow users to construct filtering queries, rather than showing all available filters at once. While FT uses click-through-menus, we can also use a similar pattern to allow users to build their queries step-by-step in a sort of workflow constructor pattern, with one row indicating every applied filter.

Yahoo! Screener, with a workflow constructor-alike UI.

Yahoo! Finance Screener isn’t very different from FT. It also allows users to select the filters that they find relevant for them first, and the define the specifics for each of the filter. Rather than using click-through-menus, here overlays are used, along with search for every type of filter as well.

Filtering Overlay #

Airtable uses a very similar pattern, with the filtering overlay appearing on top of the data table. As filters are added, the overlay grows vertically, making best use of available horizontal space — each filter takes up the width of the entire content area.

Airtable uses an overlay to allow users to construct their filtering queries.

Trigger Condition Action #

Sometimes we end up with a slightly different kind of filtering though. You might have a trigger, that, based on a particular condition, might prompt a particular action. Rather than just filtering data, we define automated actions. The patterns listed above could be applied here, too.

Smartsheet with a visual constructor for triggering actions.

Smartsheet displays the constructor overlay in a separate view, with each trigger, condition and action receiving a dedicated collapsible card. Items of the same kind are grouped as they are added to the list. So everything finds its place in the UI. It’s complex, but not necessarily complicated.

IFFFT is simple: there are no drop-downs as users explore filters by clicking through cards. Large view.

Wrapping Up #

Filtering can be complicated if we expose all complexity to our users at once. However, more often than not it’s just unnecessary. We can allow users to choose what filters are relevant for them first, and show these filters when requested. We could use the same approach for forms, too.

Of course the techniques listed above might not be an ideal solution at all times, but if we have a lot of options, we can use it to reduce complexity of the interface, while leaving its functionality in tact. And that’s a good start.

Infinite Scroll UX

Vitaly Friedman — Mon, 26 Dec 2022 00:00:00 +0000

We all have our opinions about infinite scroll, and usually not very good ones. This has a number of good reasons.

With infinite scroll, the sheer number of options is often overwhelming. There is no easy way to navigate between the “old” and “new” segments in the list. We don’t have any control about when and how many items appear. We can’t really bookmark a location and return to it later. The scrollbar keeps jumping. The footer is hard to reach. And there are plenty of accessibility and performance issues that go along with it.

All of these issues are just poor usability. So it’s not surprising that we often disregard infinite scroll as a fashionable technique which produces more problems than solutions.

However, usability tests show that every now and again infinite scroll can work well, especially when users browse on a site a lot. The speed of displaying results is significantly higher, and so is engagement. Can we make infinite scroll better?

Yes, we can.

Bookmarking a Position #

The easiest way to improve infinite scroll is by marking the breaks between “new” and “old” items in the list. When a new batch comes in, we separate the items visually and allow users to jump to the position of the list on next visit.

We could allow users to mark the current position in the list and continue browsing later. A mock-up, based on Crutchfield.com.

We could also allow them to copy a link to the current position. And perhaps even send it via email-so we could send them a reminder later, too.

We could integrate a footer reveal: a little helper that would stay persistent at the bottom right bar, and display the footer if needed while the rest of the page uses infinite scroll. You can find a good example on Popmeals (no infinite scroll in use at the moment).

Combine Pagination and Infinite Scroll #

As users scroll down a page and items are loaded in, we can present it as dynamic pagination to users (see Pepper.pl). On scroll, the URL of the page changes and the page number is updated in the sticky bottom bar. Users can also navigate to a specific page in a pagination drop-down. And of course an accordion opens up a footer on tap or click as well.

Combining pagination and infinite scroll on Pepper.pl

Scrollbar Range Intervals #

We can make scrollbars more helpful by adding dynamic labels that are spaced out vertically. These would indicate to users where they current are and where they can jump to. As users keep scrolling down, the labels would be shifting as the scrollbar is growing. Could be used by any criteria a user has chosen to sort the items by. Mock-up by Baymard Institute.

Pinning Sections on a Mini-Map #

We could make it even more useful by allowing users to pin, or bookmark, areas of interest in the list, so they can return to favorites faster. An interesting prototype of such an experience is Minimap experiment (currently works only in Firefox), created by Rauno Freiberg, along with many other wonderful experiments.

Wrapping Up #

With these techniques, we’ve solved most problems that infinite scroll is known for. However, it might seem like a lot of work just to make infinite scroll better. Well, infinite scroll is not for every website, and if it is used, it always needs to be complemented with proper filtering, sorting and search.

The ideas highlighted here are just that-ideas. Some of them might fail miserably in your tests, while others might perform fairly well. But: if you absolutely need to make infinite scroll work, there are ways and workarounds to do so-it’s just not as straightforward as it might appear at first.

Navigation Queries UX

Vitaly Friedman — Tue, 06 Dec 2022 00:00:00 +0000

Gerry McGovern once rightfully suggested that more people have been on the top of Mount Everest than have been to the 10th page of Google’s search results. This is probably true, yet usually our interfaces provide long lists of options, rather than a guidance to where the answers are.

Search usually returns a list of pages, but instead, we could display answers or guide people to these answers. Via Marcin Ignac.

As we try to solve a task at hand, we wander from one page to another, surveying the landscape with keywords, clicks, taps and selections. We rarely get the answers we need immediately though; instead, we discover the answers in a long-winded journey between pages and sub-navigation items.

It works, but it’s slow. To minimize the distance between intent and action, we can just ask users what they want and then assist users in their journey. That's when navigation queries come into play.

The idea behind navigation queries is not new. We’ve seen all kinds of variations of madlib pattern and natural language forms, all of which present a human-friendly way to input their intent without having to use input fields or navigation menus.

The idea is to create a “query constructor” for user’s intent. In our interface, we could show options to choose from and based on one answer, provide further options, all the way to the point where we bring a user to the page of interest.

The navigation query pattern on AO.de provides a shortcut for users to jump from the homepage to a specific product of interest. Once an option is selected, another drop-down appears, allowing them to specify their intent even further.

In the past, a navigation query pattern on Commonbond.co was providing a shortcut for users to jump to a relevant page.

Monday.com asks prospect customers to specify their interests, and then drives them to an onboarding flow that fits their needs best.

A-Z Index #

One way to address navigation issues on large websites is by using an A-Z Index pattern. We identify the top tasks that users perform on the site. For each task, we define a set of keywords that they associate the task with.

We run tree testing to ensure that they can find the pages that they are looking for. And then we surface the A-Z catalog of questions on a single page.

Visitors can quickly jump from any page to any other page on the [Aarhus University website](https://international.au.dk/

Aarhus University highlights the A-Z index as part of the global navigation. Visitors can choose their role first, then choose a letter, and then explore the overview of all options available, jumping to a specific department or faculty.

Tap-Ahead Autocomplete #

We tend to use autocomplete to highlight relevant keyword suggestions. Sometimes we also drive users directly to relevant categories, specific products or even collections of items or records. We can do even a little bit more than that.

Have you ever clicked on an arrow on the right hand side? That’s tap-ahead autocomplete in action, on Mediamarkt

With tap-ahead autocomplete, we allow users to construct a query based on autocomplete suggestions. As users hit the autocomplete field or start typing a keyword, suggestions appear. Users can either jump directly to the keyword, or append frequently used keyword combinations to their query, hence “constructing” their query based on the suggestions.

Tap-ahead minimizes the amount of effort needed for typing, but also drives customers to relevant results and gives them confidence that they are on the right track.

Stackoverflow allows its users to specify a query right in the search box, without having to rely on filters, tags or any other modes of navigation.

Wrapping Up #

When designing navigation, we often rely on predictable patterns. That’s a good thing as our outcome is usually predictable, familiar and hence obvious to our customers.

However, sometimes navigation might be just a bit too tiring and time-consuming, and in such cases we can use navigation queries to pick up our users whenever they are and gently guide them toward the page that is of interest to them. They are unlikely to help you resolve all IA issues on the site, but they could help users get where they want go be, faster.

A much more detailed article about all the fine details of carousels will be published in Smashing Magazine next week, so please take a look if you are interested.

Pricing Plans UX

Vitaly Friedman — Wed, 30 Nov 2022 00:00:00 +0000

We often dismiss pricing plans as if they were quite straightforward to design. In fact, how difficult can it be? We just have a few options with a few features marked as available or unavailable, the pricing, and a few CTAs along the way.

Problems occur at latest when we think about mobile, with pricing plans becoming difficult to explore and differences in plans becoming difficult to decipher. Let’s change that.

Focus on Roles and Key Highlights #

Every pricing plan starts with a description of features. But when there are hundreds of features, making sense of them is becoming difficult and overwhelming. Usually it’s not really necessary. Instead, we could try to indicate to customers who the plan is designed for. Plus, we could add a show/hide pattern to show (and hide) more features if needed.

We can also focus on key highlights, key differences and intended roles for each plan. Kissflow, Airtable, Chargebee.

On Kissflow, no details are displayed at all: instead each plan is focused around a defined role. On Airtable, users can show/hide more features if interested. And on Chargebee, a separate overlay with all features shows up when clicked. Neither design shows all features by default.

For each plan, Gusto reveals plan details within an accordion on click/tap. The main focus is on key features and the pricing. Everything is accessible, but only if needed. A good reference example to keep close.

Avoid Horizontal Feature Comparison Tables #

We've looked into feature comparison tables already, but in generalm horizontal scroll for tables is quite difficult to get right. Users tend to get lost in a large table, often not knowing what represents what and what exactly they are looking at.

Showing a full feature comparison table can be difficult to get right.

In Contentful and Hotjar above, it's not easy to understand what features we are comparing. There is no sticky bar referring to a particular plan, so it's quite easy to get lost. In general, it's worth testing alternatives to this kind of layout.

Grouping Plans With Tabs or Accordions #

We could allow users to navigate through the different features of different plans with accordions or sticky tabs. While it's not ideal for comparing, it's useful to allow users to quickly jump between the plans and find a good fit for them.

We can neatly group features with tabs or accordions. It doesn't make features easier to compare, but makes plans easier to understand.

Asana features accordions, with each open card displaying the pricing and some key features of each plan. On Twilio Segment, a visualization is used to highlight features of Free, Team and Business plans. And on Cloudflare, sticky tabs and a feature selector provide jumps between plans and for features within each plan.

Comparing Without Tables #

If you have a complex set of pricing plans, or need a feature comparison side-by-side, we could use a customizable table to allow users to select two plans at a time. That's what Dropbox does on their pricing page. Zendesk attempts to show all 4 pricing plans with accordions for each feature. This could be an option too.

Comparison is possible, but can be quite challenging with more than 2 options at a time. Dropbox and Zendesk.

Customizing Plans #

Not many people prefer the hard work on comparing features in a pricing plan. To reduce the amount of data to display, we could ask users what is it that they are interested in, ask them to specify their intent and suggest a recommended plan based on their preferences.

No need for guess if we can ask for intent. This helps us nudge users towards a best-fit plan for them.

Jira and Monday.com ask for the type of work and the number of users to suggest a plan, and Intercom suggests plans based on the type of business that is interested in purchasing one of the plans.

Wrapping Up #

Not all of these options will work of course, but they are great solutions to keep nearby when you want to test a few options for that magical landing page. It's probably a good idea to replace feature comparison tables on mobile with a combination of tabs and accordions, and nudge users towards an option that would be a best fit based on their preferences.

Back Button UX

Vitaly Friedman — Sat, 19 Nov 2022 00:00:00 +0000

There aren’t many things in usability testing that keep showing up over and over again. One of them is the anxiety people experience when they have to go back. Users generally don’t have much trust in the browser’s “Back” button, and for a good reason. We’ve all been in a situation when a browser’s “Back” button just didn’t work as expected.

For example, if you happen to be in a multi-step process such as checkout, the “Back” button would often bring you to the very start of the process, rather than to the previous page, with all your data evaporated in thin air. And sometimes we have to retype sensitive data such as credit card number multiple times, because it can’t be stored for security reasons.

Fear of the Browser’s "Back" Button #

Surely, users rely extensively on the browser’s “Back” button. Yet for the reasons mentioned above, frequently users seem to be thinking twice before actually hitting that button. Mostly, they are just afraid of losing their data or the state of the page in which they currently are — and it’s understandable, since sometimes it’s not clear where the browser will bring a user to.

From a user interview: “How do I get back? Just press ‘Back’. Navigation, this isn’t great to be honest. And now it’s brought me back to the women’s. OK. Don’t like this.” Via Baymard Institute.

That’s why it’s not uncommon to see people taking screenshots of the current page, or opening the same page in another tab to ensure that their data (at least for the current page) is still available in the browser.

Severe problems start showing up when we introduce overlays, anchor links, image galleries and dynamic views into our interfaces, or change URLs as users scroll through the page. For example, if a large overlay, e.g. for editing a table, appears on click, where should the “Back” button bring a user to? And what if a user clicks through an image gallery in an article?

Always Close Large Overlays With The “Back” Button #

Research shows that the more different a new view is visually, the more likely it is to be perceived as a separate page by users. With it, comes the expectation that the “Back” button will bring a user to the previous “page”, even although technically it might not really be a separate page.

This goes for the product list appearing after filtering and sorting, for accordion checkouts, but could also be helpful for anchor links and expanded and truncated content — especially if the sections are lengthy. In these situations it’s reasonable to align the browser’s “Back” button behavior to match user’s expectations — with the History API.

Surely we don’t want to pollute user’s history with unnecessary states or pages though. When a user clicks through an image gallery in an article, we probably shouldn’t add every single image to user’s history as it will make it much harder to get to the “actual” previous page.

In this case, a state of the carousel is rarely seen as a “different page”. As long as the page doesn’t change significantly, we should avoid adding states to user’s history stack. This goes for checkboxes, drop-down menus and dynamically injected sections as well, for example.

The Position of the “Back” Button #

Even although we’ve aligned the expectations for the “Back” button behavior, some users will still be worried if the “Back” button actually works as expected. A good way to resolve this issue is by adding a custom, form-specific “Back” link or a “Back” button within your interface.

Steve Schoger’s mock-up for buttons placement. So where should the “Back” button be here?

Steve Schoger suggests that whether the buttons are aligned to the right, or to the left, it’s always a good idea to put the primary action on the outer side. This means that the “Back” button — which would also be visually less heavy — would be residing next to the “Next” button.

Put The “Back” Button Above The Form #

Indeed, the example above is a quite common pattern that will usually work well. However, in my experience, this would also cause trouble as every now and again users will accidentally click on a wrong button — mostly because these buttons are located too close to each other.

Therefore, I’d always argue that placing the buttons as far away from each other as possible is an idea that’s worth testing.

Left: “Back” button at the bottom of the page; Right: Back button above the form. The big question is: which pattern performs better?

Adam Silver suggests to put the “Back” button above the form, as designed by Joe Lanman, a designer at the Gov.uk. Ultimately, the “Back” button is then in a similar place to where most browsers put the browser's “Back” button.

According to Joe, the “Back” button is probably not needed once the user fills out the form — “if they fill out the form and click back, they will lose their answers”.

“Back” Should Look Like An Interactive Element #

It’s worth emphasizing that the “Back” button, when positioned above the form, should actually look like an interactive element. It can be an underlined link or a standalone button that actually looks like a button, for example.

In my experience, if the "Back” link blends in with the rest of the page, users sometimes can’t find a way to go back and usually start searching at the bottom of the page. So to make it work, the “Back” button should be visible and noticeable.

On Gov.uk, the “Back” link is located at the very top of the page, underlined, appearing as an interactive element — in a place where one would usually expect breadcrumbs. There is only one single prominent button, and that’s the “Continue” button.

On Fully, the “Back” button and the “Next” button are positioned very far from each other. Users can go back by tapping on a back-arrow all the way on the left outer edge of the screen, while they continue with the process in the bottom right corner of the screen. That’s a safe way to eliminate mistaps or misclicks.

However, we need to make sure that users can actually find the way back in the middle of the process if they need to.

Group Back States As Snapshots #

Sometimes you might not need a “Back” button at all. Surely we need to support browser’s “Back” button behavior properly anyway, but instead of a custom way to go back, we can allow users to go back to relevant options only. For example, with a dedicated snapshots area for states.

On Fender Mod Shop, you can create “snapshots” as you are configuring a model. You are always driven forward to explore and customize, with an option to go back to a specific version that you saved as a snapshot.

Wrapping Up #

The way we, as designers and developers, see our website, isn’t necessarily the same way of how our users perceive it. The more different the views are from one interaction to another, the more likely users are to perceive these views as “separate things”. Users rely on a “Back” button to go back, but often we mismatch their expectations, bringing frustration and abandonment.

We surely need to align user’s expectations with the “Back” button behavior as a very minimum. Additionally, it’s a good idea to add a custom “Back” button to our interfaces — and perhaps place them far away from “Next” or “Continue” buttons, perhaps at the top of the page.

While it works very well in some scenarios, it might not work well for you. In that case, try to avoid placing the buttons too close to each other and make sure they look different enough visually. One could be a link and the other could be a button. What seems to be a small detail might pay off big time and result in lower abandonment and higher conversion.

Useful Resources #

Back Button Expectations by Baymard Institute,
Designing With the Web in Mind, a wonderful article on back button, URL design, keyboard shortcuts, and other things we often forget about, by Chloe Sanderson.

Usability Pitfalls Of Carousels UX

Vitaly Friedman — Fri, 11 Nov 2022 00:00:00 +0000

Carousels don’t have a good reputation, and rightfully so. They have plenty of accessibility issues, often exhibit low click-through rates and people frequently scroll past through them. Add to it small progress dots with tiny tap areas, barely visible labels and a bit of parallax, and you have a quite troublesome design pattern in your hands.

Teatr Lalka, a puppet theater from Poland, with a creative, dynamic, and accessible approach to highlighting the position in the carousel.

However, carousels can be quite effective, especially when we want to highlight key features or options, but lack space to display them all at once. They work well when users want to explore plenty of options, browse through reviews, dive into image galleries or closely examine product features.

So how do we design better carousels? We provide better context by replacing progress dots with labels, thumbnails and better prev/next-buttons.

Replace Progress Dots With Better Labels #

We are very much used to progress dots in carousels, but there are some good reasons why we might want to avoid them. Sometimes users desperately try to click on them, and because these dots are incredibly small, navigation is slow and requires a lot of precision. This results in a feverish combination of rage clicks (or taps), mistakes, and unexpected jumps back and forth.

Stripe Press includes short horizontal lines, each representing a section on the site. The labels appear only on hover.

Progress dots aren’t a particularly effective way to entice users to click through the carousel. They don’t communicate much; definitely not what each dot represents, nor what users should be expecting while sliding through the carousel.

A good way to encourage navigation through the carousel is by adding more context to it. We can replace lifeless dots with labels, thumbnails and video previews. Interesting examples of it in action are on Creative Denmark and Weber Grill Original, with key video highlights and photos accordingly.

Additionally, we can use filters, tabs and prev/next buttons that allow users to choose the content in the carousel, just like the designers of Reuters.com did.

Better Position of Prev/Next Buttons #

In design, we want to minimize errors and mishaps as far as possible. At the same time, we want to speed up navigation within the carousel as far as possible, and this means minimizing the distance between opposite actions: in our case, that’s moving forward and backward.

On Ritual.com, prev/next-buttons are always grouped.

One useful pattern is to group arrows in the carousel. This allows users to move in both directions quickly, without heaving to re-calibrate their pointer or their fingers, or tab through items.

On desktop, group buttons above the carousel (still Ritual.com in the example above). If the buttons live on the slices of the carousel, it might cause misclicks and accidental jumps to wrong pages. And if the buttons live under the carousel, they might not be noticed in time, especially if carousel slices are tall.

On mobile, group buttons under the carousel. Otherwise, every time a user interacts with the buttons, especially when they are spaced out across the edges of the carousel, they’ll be covering the content of the carousel with their fingers. And when centered vertically, users might end up with plenty of rage taps.

Wrapping Up #

When designing your next carousel, consider replacing progress indicators with labels or thumbnails. Indicate the current slice of the carousel. Include and group prev/next buttons and display them above or below the carousel. Avoid auto-advancing if you can, and if you can’t, add a delay of 7s and allow users to pause rotation.

913 restaurant provides an information scent for prev/next slides.

A much more detailed article about all the fine details of carousels will be published on Smashing Magazine, so please take a look if you are interested.

Designing Better Mobile Navigation UX

Vitaly Friedman — Thu, 03 Nov 2022 00:00:00 +0000

Many mobile navigation menus show only one level of navigation at a time. You might have seen page takeovers and slide-in menus, overlays and bottom sheets. Often this experience is slow and disorienting. Often users have to go back to move forward. Yet usually we want the opposite: help users navigate between levels faster, not slower.

LCFC split the page into two parts, one for each level of navigation.

What if split the screen vertically (pictured above on LCFC, and display two levels of navigation at the same time? To move between levels then we don’t need to close any menus or return back — instead, we move forward and explore.

And what if you need slightly more space for your lengthy navigation labels? Well, they could wrap onto multiple lines, or we could reduce the width by replacing text labels with icons (as long as they are unambiguous). It might not work for every project, but it seems to work for Playstation (pictured below).

Playstation with the curtain navigation pattern, showing 2 levels of navigation at the same time.

The entire first level of navigation collapses into tabs; yet moving from one level to the other doesn’t require any jumps back. You might be wondering what the three vertical lines represent — ideally, one could drag away the pane, but it doesn’t seem to be working as expected unfortunately.

Better Filtering UX #

We could use the same approach in other contexts, such as filtering. We display all filter attributes on the left, and allow users to choose the specific values for these filters in the second vertical pane. That's what the filtering experience looks like on Myntra, an Indian eCommerce retailer pictured below.

If some filters don’t fit in the right pane, users can scroll to explore more, or even search for a specific filter in the selection. Of course, the "Apply" button has to stay floating. It would be lovely to see the total number of results on that button, too.

Filter Constructor UX #

We could take it even further though. For example, sometimes users need to select filters that are relevant to them, and define their values in the next step. In that case, we group all filters into a few categories or even sub-categories, and then present all categories and all filters in sub-categories side by side.

FT Screener with two panes, one for groups and one for specific filters.

With FT Screener, for example, users can add or change criteria by exploring multiple levels at the same time — both the labels for groups and the filters living within those groups. Once a filter has been chosen, it’s being added to the overview on the top. That’s a simple filter constructor for a sophisticated filtering on mobile.

Language Selector UX #

The vertical split could be used to quickly select one important present or make a single choice. That would be the case for a language selector, for example. We could organize all supported countries and languages as cards or accordions, but they could also work as vertical tabs, as it’s done in the footer of Oracle.

Oracle with a vertical-split menu for the country/region selection in its footer.

This way, we display only options that are relevant to users. They never have to go to irrelevant sections or pages since they get a preview and can navigate away from it quickly, should they wish to do so.

Wrapping Up #

This little technique works very well if we have a quite shallow content architecture, but it can become a bit difficult to manage with three or more levels. In that case, often filters or navigation options are accessible on individual pages, although it could work with an accordion as well.

The best part: vertical split is fast! It shows its strengths when the speed of navigation matters, and when users are likely to jump between sections a lot. It’s way faster than slide-in-menus but less flexible than accordions. Still, a great lil’ helper to keep in mind to make better use of available space on mobile.

Inline Validation UX

Vitaly Friedman — Tue, 08 Feb 2022 00:00:00 +0000

Undoubtedly there are major advantages of inline validation in forms. Most importantly, if an input expects a particular type of content, we can flag issues immediately, so users can fix these issues rather than operating under a wrong assumption.

Inline validation works well as a password strength meter.

However, inline validation can be problematic. Mostly because often we can’t really validate just-in-time when errors occur, and the reason for that is that we can’t really know for sure when the user has actually finished their input, unless they explicitly tell us that they have.

Clicking on a “Submit” button is a clear signal that users think they are done, but our implementations usually consider leaving an input field as a strong signal, although it’s merely an assumption, and often a wrong one.

Surely we don’t want to show “wrong” errors — when a user skips a field, or glitches in our interfaces that creep when we bake in some assumptions about what the user behavior is likely to be. The problem is that usually our assumptions are wrong.

How People Fill In Web Forms #

When we think about inline validation, we usually think about the error recovery speed. If we validate as users are typing, we should be able to help them fix errors almost immediately. However, as it turns out, when filling in a particular input, some people never look at the screen — they look at the keyboard, and specifically at the keystrokes that they are about to type.

When should the error message appear? On submitting the data, or when a user leaves the field? From Carbon Design System.

When filling in any complex input — be it lengthy coupon code, VAT number, IBAN number, or a credit card number — we often follow pattern matching. Rather than filling in the entire string at once, we either copy-paste characters in chunks, or fill in the input in steps. Premature inline validation disrupts that pattern, causing errors and a healthy dose of frustration.

Also, inline validation is supposed to help users make sure that they don’t miss anything important, yet just before moving to the next steps, many people — despite green checkmarks all over the fields — review their input meticulously.

Users do trust inline validation, but usually they don’t trust it enough to prevent severe errors — the errors that go beyond simple formatting issues. So users review, field by field, watch out for typos, double check if auto-filled values are right, and try to spot any kind of outdated data. The correct format of data doesn’t mean that the data is accurate.

The Downsides of Inline Validation #

In fact, these are some of the typical problems that often come up with inline validation:

Live validation always interrupts users. A user is trying to answer the question, but error messages keep flashing in front of them.
Live validation often kicks in too early or too late. Errors appear either when the user hasn’t finished their input yet, or she has moved to the next input field. Both of these options aren’t ideal: the user is focused on the next question, yet we prompt them to fix their previous answer. Live validation is often unreliable. The correct format of data doesn’t mean that the data is accurate. Even though an inline validator might give a user’s input green light, it can still turn into an error once the input has been validated on the server.
Validation rules aren’t error-prone to exceptions. They rarely include a wide range of exceptions and custom rules. They are often based on common assumptions that will eventually fail for some users.
Often error messages are removed too late. While the user is editing their input, often error messages remain until the user has left the input field. This leaves users in the dark as they think they’ve fixed the problem, but the interface doesn’t react accordingly.

When Inline Validation Works #

We’ve learned over the years that premature validation on focus isn’t useful. When a user just focuses on an empty input field, it doesn’t make sense to display, before users even get a chance to type anything.

So we have only two options: we either validate as users type (live validation), or after they’ve left the input field (late validation). As it turns out, in both cases, the experience can smoothless when there are no errors, and can be somewhat frustrating when things go wrong.

1. Show Errors For Empty Fields Only on Submit #

How and when do we validate an empty input field? The user might have indeed overlooked the input field, so we should be flagging the mistake early. But they might as well just jump in a wrong field and leave it right away. Or they had to jump back from one field to the previous field to correct an error. Or they just had to clear up their input as they copy-pasted the wrong thing.

In my experience, whenever we try to validate empty fields, too often we will be wrong, pointing out mistakes prematurely. Instead we could show error only when a user is certain that they are done with their input.

2. Reward Early, Punish Late Pattern #

If a user chooses to change previously validated input, we need to decide when we start and when we stop validating that input. That means, that we need to track the state and contents of each input field, and have thresholds for when we start validating, and then have rules for changing input fields that have been validated already, or that contain errors.

As Mihael Konjević wrote in his article on the Reward Early, Punish Late pattern, if a user edits an erroneous field, we should be validating immeditely, removing the error message and confirming that the mistake has been fixed as soon as possible (reward early).

However, if the input was valid already and it is being edited, we need to wait until the user moves to the next input field and flag the errors then (punish late).

As it turns out, the implementation isn’t trivial, and making it work in a complex form will require quite a validation logic that might be difficult to maintain if some fields have dependencies or show up only in certain conditions.

3. Allow Users to Override Inline Validation #

Because inline validation is never bulletproof, we could try to give people a way out when inline validation fails. That means adding an option to override validation if the user is confident that they are right.

What happens if the validator doesn’t know the address? We can allow users to override validator in some cases.

Then measure for a few weeks just how much money the company loses due to wrong input and how much money the company earns due to an overly aggressive validator. This will give you a comparison to see how costly inline validation actually is.

4. For Short Forms, Consider Validation on Submit Only #

Inline validation is indeed very helpful, but it might be a good idea to test its alternative — validation on submit only. With it, users are never distracted or annoyed and have full control over when their input is validated.

Many shorter pages tend to perform better than one long page. We can frame them as a part of the journey with a task list pattern.

The pattern doesn’t seem to work well for lengthy pages with many input fields. There, users often end up typing a lot of unnecessary data before they realize that their initial input wasn’t really applicable. Shorter pages usually perform better than one long page.

So for shorter forms, a better way to deal with complex journeys is to simplify them:

Split a complex form into small tasks = pages (with the one-thing-per-page pattern;
For every page, validate only on submit, as users are moving to the next page;
Don’t require a particular format and accept any input that’s unambiguous — the rest can be done as a post-processing step;
Provide users with a task list pattern and support navigation between them, with the option to save input and continue later.

Wrapping Up #

Inline validation is useful, but when it fails, its costs can be quite severe. With just-in-time validation, reward-early-punish-late-pattern and validating on submit, we avoid unnecessary distractions, complex logic and layout shifts altogether, and communicate errors without annoying users too early or too late.

The downside is of course the error recovery speed which certainly will be slower. Yet in the end, the number of errors might drop just because users are never distracted as they type. And that might be just enough to reduce the overall frequency of errors and increase completion rates.

Smart Interface Design Patterns

How To Measure The Impact Of Features

👩🏻‍🦱 1. Target Audience (%) #

🗂 2. A = Adoption (%) #

🗃️ 3. Retention (%) #

❤️ 4. Satisfaction Score (CES) #

Using TARS For Feature Strategy #

Conversion Rate Is Not a UX Metric #

High Conversion Despite Bad UX #

Low Conversion Despite Great UX #

Wrapping Up #

Useful Resources #

Designing Better Loading and Progress UX

The Psychology of Waiting #

Choosing The Right Loading Indicator #

Reducing Perceived Waiting Time #

Always Start Early #

TL;DR Useful UX Guidelines #

Wrapping Up #

Useful Resources #

Combobox vs. Multiselect vs. Listbox

Not All List Patterns Are The Same #

Never Hide Frequently Used Options #

How To Choose Which? #

Usability Considerations #

Wrapping Up: Not Everything Is A Dropdown #

Useful Resources #

Designing For People With Dementia

What Exactly Is Dementia? #

Design Patterns For People With Dementia #

Dignified Experience and Sense of Independence #

Wrapping Up #

Useful Resources #

How We Brainstorm And Choose UX Ideas

Giving People Time To Think #

Silent Brainstorming #

Booking.com's Brainstorming Model #

Individual Thinking First #

How Might We" (HMW) statements #

Sharing and Revising Ideas #

Wrapping Up #

Useful Resources #

Inclusive Design Patterns For 2025 (Free Video + Slides)

Product Designer's Career Paths

Run A Retrospective For Last Year #

UX Skills Self-Assessment Matrix #

Find Your Product Design Career Path #

Proactively Shaping Your Role #

Wrapping Up #

Useful Resources #

How To Design For (And With) Deaf People

Deafness Is A Spectrum #

Useful Things To Know About Deafness #

How To Communicate Respectfully #

Practical UX Guidelines #

Wrapping Up #

Useful Resources #

Useful Books #

How To Stop Endless Stakeholder Reviews

The Goal Is Not Just A Sign-Off #

Use Different Lenses For Different Stakeholders #

Always Show Ideas on a Spectrum #

Define the Meeting Type #

Wrapping Up #

Useful Resources #

Useful Books #

Designing Effective Dashboards UX With Action Dots

Why Dashboards Fail #

Poor Types of Action Indicators #

⚠️ Some Indicators Don't Work Well #

Alternative: Action Dot Dashboards #

Accessibility Considerations #

Bonus: Dashboard Design Patterns #

Wrapping Up #

Useful Resources #

Useful Books #

How To Build A UX Team From Scratch

First Steps: Scope The Design Work #

Hiring Strategy: Hire Slowly, People First #

Team Structure and Processes #