Showing posts with label UI. Show all posts
Showing posts with label UI. Show all posts

Designing Nested Tables: The UX of Showing Complex Data Without Creating Chaos

Mike's Notes

This gem was listed in a recent Smashing Magazine article. Will be included in a future update to the Pipi Design System.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Smashing Magazine
  • Home > Handbook > 

Last Updated

03/10/2026

Designing Nested Tables: The UX of Showing Complex Data Without Creating Chaos

By: Damilola Bamgbelu
Medium: 20/05/2025

Damilola Bamgbelu: Product Designer, best known for crafting great experiences that deliver audacious results for both users and stakeholders.

...

Nested tables have a bit of a reputation. They’re often seen as messy or overwhelming, but when used thoughtfully, they can actually help users make sense of complex, layered information, without jumping between screens.

UI comparison of single vs. multi-level nested tables showing category data, with notes on usability benefits for each approach

I remember the first time I designed a nested table. It looked amazing in Figma: beautiful rows expanding neatly into sub-rows. I thought I was a genius.

Until user testing.

One participant squinted at the screen, clicked a few times, then said:

“Wait… where am I now? What row was I just looking at?”

That’s when it hit me:

Nested tables aren’t just about organizing data. They’re about organizing thinking.

…If you’ve ever struggled to design tables that show parent and child data together , without overwhelming users, this article is for you. Let’s walk through it step by step.

1. Always Start with “Why Nest This?”

Imagine you’re packing for a trip. Do you cram everything into your backpack just because you might need it? Or do you only pack what you’ll actually use?

Nested tables are the same. If users don’t need the child data right now to make a decision or take action, don’t show it inline.

Always ask:

  • Why does this need to be visible right now?
  • What task does seeing both parent and child data help users complete faster?
  • Could a modal, tab, or progressive disclosure do it better?

If you don’t have a strong reason, nesting is clutter, not clarity.

As Steve Krug puts it in Don’t Make Me Think,

“Every element you add competes with every other element for your user’s attention.” [1]

The more things you show on screen at once, the harder it is for users to know what to focus on.

A designer processing thoughts on what design decisions to make. Source: Freepik

2. Keep It Shallow: Two Levels Max

Picture this: you’re standing at the edge of a swimming pool. Jump into the shallow end? Great. Dive straight into the deep end with no bottom in sight? Panic.

Deep nesting feels like drowning in data.

  • One level of nesting (Parent > Child) is good.
  • Two levels (Parent > Child > Grandchild) is manageable — if truly needed.
  • Three or more? Stop. Redesign.

Humans aren’t built to track endless layers while scanning a screen. This aligns with George Miller’s Law, which says:

“Humans can comfortably hold 5 to 9 items in working memory.” [2]

If you must use multi-level nesting:

  • Visually differentiate each layer (indentation, color bands, labels)
  • Limit nesting to 2 levels
  • Provide expand/collapse all and clear context cues

To borrow a thought Jared Spool and Steve Krug might both agree on:

“The deeper the nesting, the higher the cognitive load. Use with restraint, and always design for collapse.” [3]

3. Make Expanding and Collapsing Feel Effortless

Ever opened a drawer and it jammed halfway? Now compare that to one that slides open smoothly. That’s how expanding a nested row should feel: smooth, responsive and satisfying.

When someone clicks to expand a row, they should get immediate, clear feedback, such as:

  • A smooth animation
  • A skeleton loader
  • A rotated chevron

These are microinteractions, small signals that say, “Yes, that worked.”

According to Jared Spool:

“Good UX reduces uncertainty at every interaction.” [4]

If there’s silence, delay, or confusion, users hesitate or worse, assume it’s broken. Every tiny motion helps users trust what’s happening.

UI showing nested tables with chevron icons to expand/collapse rows and a skeleton loader for loading child data illustrating that expanding and collapsing should feel effortless

4. Prioritize Scanning, Not Cramping

One of the biggest mistakes with nested tables is trying to show everything at once. The result? A wall of numbers, labels, and rows that’s hard to parse.

You know that feeling you get when you walk into a store that’s so packed you can’t even move? That’s how users feel when a table is over-stuffed with information.

Your goal: Make it insanely easy to scan. If someone can’t scan your table in 2–3 seconds and find what they need, it’s too dense.

How to improve scan-ability:

  • Clearly indent child rows to show hierarchy
  • Use soft shading or dividers to separate levels
  • Keep typography clean and consistent
  • Add sticky headers to maintain context

As Edward Tufte famously said:

“Clutter isn’t about the information itself. It’s a failure of layout.” [5]

Table UI showing clear row indentation for hierarchy, soft shading to separate levels, clean typography, and sticky headers to maintain context while scrolling

5. Never Leave Users with a Blank Expansion

Expanding a nested table row should feel purposeful, not like a dead end. Think of it like opening a fridge expecting leftovers, only to find it empty. No note, no label, no clue what happened.

That’s what it feels like when a user clicks to expand a row and sees nothing. When there’s no child data to display, it’s not enough to show an empty cell. A blank space can confuse users and make them wonder:

Instead:

  • Explain the state: e.g. “No related tasks found”
  • Suggest the next step: e.g. “+ Create Task”
  • Make it visually distinct: muted icons, faded backgrounds, or subtle illustrations

This tiny design choice adds clarity.

As Luke Wroblewski advises:

“Empty space should guide users toward their next action, not leave them wondering what went wrong.” [6]

Nested table UI showing an expanded row with an empty state message and a clear call-to-action button

6. Build Accessibility in from Day One

You’ve designed a slick, responsive table. It expands smoothly. It works in dark mode. But here’s the test:

  • Can a screen reader user understand the structure?
  • Can a keyboard-only user navigate the table easily

If not, you’re unintentionally excluding users. As Whitney Quesenbery puts it:

“Accessibility is not a feature. It’s a foundation.” [7]

Nested tables add visual hierarchy and relationships that are obvious to sighted users, but completely invisible to users relying on assistive technologies.

Without proper semantic markup, screen readers can’t tell what’s expandable, what’s nested inside what, or even what content is currently visible. And for keyboard users, expanding a row should be as easy as clicking, but often isn’t.

To make a nested table accessible;

  • Use semantic HTML

    Use actual <table>, <tr>, <td>, and <th> elements — not divs styled to look like tables.

  • Use aria-expanded and aria-controls

    These attributes help screen readers announce whether a row is open or collapsed, and which section it controls.

  • Ensure keyboard navigation

    Users should be able to tab through parent and child rows, expand/collapse with Enter or Space, and not lose focus in the process.

  • Design an alternate flat view

    For users who don’t benefit from inline nesting (e.g. screen reader users), offer a simplified version — a grouped list or summary view that doesn’t require expanding/collapsing.

Accessibility doesn’t only benefit users with disabilities.

  • Clear structure improves usability for everyone.
  • Keyboard-friendly interfaces help power users navigate faster.
  • Screen-reader compatibility often translates to better semantic structure and more maintainable code.

Side-by-side nested table designs, one accessible with semantic HTML, ARIA support, keyboard navigation, where the other lacks these features.

Final Thoughts

Nested tables aren’t the enemy. Careless nesting is. When designed intentionally, they:

  • Reveal relationships
  • Enable fast decisions
  • Prevent unnecessary page hopping

But if poorly designed, they:

  • Confuse users
  • Increase cognitive load
  • Exclude those who rely on assistive tech

Designers must treat nested tables not just as containers of data, but as tools for clarity and action. That means:

  • Start with why
  • Design for scanning and accessibility
  • Plan microinteractions
  • Never leave users wondering what’s happening

Good UX isn’t about making data visible.

It’s about making it useful, usable and usable by everyone. Nested tables are powerful. Use them with care.

References

  1. Steve Krug, Don’t Make Me Think, 2000.
  2. George A. Miller, “The Magical Number Seven, Plus or Minus Two,” Psychological Review, 1956.
  3. Paraphrased synthesis of ideas from Jared Spool and Steve Krug on cognitive load and interface clarity.
  4. Jared Spool, quoted in multiple UX talks and writings on reducing uncertainty in interactions.
  5. Edward Tufte, The Visual Display of Quantitative Information, 1983.
  6. Luke Wroblewski, “Designing for Empty States,” blog and presentations on interface design.
  7. Whitney Quesenbery, quoted in A Web for Everyone: Designing Accessible User Experiences, 2014.

Accordion Icons: Which Signifiers Work Best?

Mike's Notes

Excellent NN Group article on Accordion Icons: What works and what doesn't.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > NN/g Newsletter
  • Home > Handbook > 

Last Updated

24/09/2026

Accordion Icons: Which Signifiers Work Best?

By: Page Laubheimer and Raluca Budiu
NN/g Newsletter: 23/08/2020

Page Laubheimer: Page Laubheimer is a former NN/G employee who worked on research, teaching, leadership, and design thought leadership. His expertise focused on web applications, AI, and projects in complex domains. His many research findings and recommendations were also informed by his background in library and information science, and his work often involved information architecture, navigation design, taxonomy construction, and ontology management.

Raluca Budiu: Raluca Budiu is Senior Director, Data Strategy, at Nielsen Norman Group, where she uses her data-analysis expertise to drive strategic decisions. She also serves as editor for the articles published on NNgroup.com. Raluca has coauthored many NN/g reports, as well as the book Mobile Usability. She holds a Ph.D. from Carnegie Mellon University.

...

Summary:

The caret icon most clearly indicated to users that it would open an accordion in place, rather than linking directly to a new page.

For good reasons, accordions are a popular UI element today: on mobile, they are an essential tool because they collapse content and make page length manageable, but even on desktop, they mitigate visual complexity and allow users to focus on the content most relevant for the task at hand (and are particularly appropriate in complex applications).

A question that is often asked in both our Mobile UX and Application Design classes is: which icon should we use to best signal that content will expand in place? In other words, what’s the best signifier for accordions?

We decided to investigate this question as part of a bigger study of navigation and subnavigation on mobile. We looked at several possible icons as signifiers for accordions:

  • Caret (or downward-facing arrow)
  • Plus
  • Right-facing arrow
  • No icon at all

There are some subtle differences in what these icons are commonly used to represent — while the caret and plus icons are typically meant to indicate that an accordion will open, designers have used the right-facing arrow icon to signal two different actions: either staying on the same page and expanding content, or visiting a different page. Also, after expansion, the caret will typically twist (maybe in a nice quick animation), and a plus sign will turn into a minus, to become a signifier for the reverse action of collapsing the newly expanded content.

Jennair: Accordion signaled by caret icon

Bolé Road Textiles: accordion signaled by plus icon

Ferrari: accordion signaled by arrow icon

Braun: accordion with no signifier icon

We performed a quantitative study to find out which of these icons is the most effective at signaling that it will open an accordion.

In This Article:

  • Methodology
  • Where Participants Tap
  • What Participants Expect to Happen
  • Key Findings
  • Design Recommendations
  • Summary

Methodology

Materials. We decided to study the accordions in the context of mobile navigation so we created 11 prototypes of mobile websites, each in a different type of industry — clothing ecommerce, big-box retail, auto parts, finance, news, local government, higher education, DIY home projects, consumer-goods reviews, healthcare, and travel. The prototypes were not interactive; they were simple mockups with the menu already open and a list of categories visible on the screen, to ensure that we were only measuring the interaction with the accordions, as opposed to users’ efforts to locate the menus, look at homepage content, and so forth.

For each prototype, we created a task that involved finding information in one of the accordions visible in the prototype. For example, on a prototype of a consumer-goods review website, the task was “Find reviews of dishwashers.”

We also created 5 different variations for each prototype; each variation used one of 4 possible icons (an arrow, a caret, a plus, a foil) or no icon. We created a foil icon (that had not been used before for accordions) in order to see whether the type of icon mattered at all or the presence of an icon next to the accordion name was enough to signal an accordion (but the icon itself did not matter).

The icons tested in this study included a downward-facing caret, a right-facing arrow, a plus, a nonsense foil icon (used as a control for comparison), or a blank space. The icons were randomly assigned for each task, meaning that participants saw a random assortment and order of these five icons.

An example of one of the prototypes, shown in all 5 icon variations

We placed the accordion icon to the right of its associated label, close to the edge of the screen and right aligned. (We acknowledge that another possible position is to the left of the label — our results may not generalize to that placement.)

As the length of the text labels might impact where users look or click, we ensured that label lengths in each prototype were distributed equally and that the “correct” answer for each task (i.e. the menu option that was likely to be chosen by users) was of a different length in each prototype. 

We also ran several pilot studies to ensure that the task success rate was high (over 90%) and that people would be able to easily identify the “correct” menu category that had to be selected in order to complete each task. After each pilot study we refined the task phrasing and labels in the menu. Thus, effectively, we ran several usability studies on our prototypes’ information architecture before we collected the quantitative data. This process ensured that figuring out the right category was relatively trivial for most participants — as our study goal was to test the accordion signifiers, not the difficulty of finding the information in the tasks we gave users.

Participants. Our study had 136 participants.  All participants saw instances of all the different icons (in different prototypes, and in different order).

Procedure. The test was conducted on UserZoom as a series of first-click tasks, administered on mobile devices. All participants were shown one version of each of the 11 prototypes and the associated task in a random order. After the participants indicated where they would tap to find the answer, they had to answer a multiple-choice question asking what they expected to happen (going directly to a new page, seeing additional menu options on the same page, or something else). 

We collected data on:

  • Tap location: Where the participant tapped (directly on the text label, directly on the icon, in the space in-between the label and the icon, or anywhere else on the prototype)
  • Participants’ expectations: The response to the post-task question about expectations (going directly to a new page, seeing an additional list of links on the same page, or something else)

Where Participants Tap

Taps outside the area associated with the accordion were relatively few (5–8%), and most taps fell either on the label or on the icon associated with the accordions (and not on the space in between the two).

Participants were equally likely to tap on either the text label or the icon, except for the caret icon, where there was a statistically significant tendency to tap on the icon over the text label. When no icon was present, users were much more likely to tap on the text label than the empty space where an icon would normally be.

An ANOVA on the data for when users tapped on the text label found a significant effect of icon type both when participants or prototypes were treated as the random factor. Pairwise contrasts indicated that the no-icon condition was significantly different than all other conditions.  In particular, there was a higher chance to tap on the label when no icon was present — a finding that is not surprising at all since the “icon area” was just empty space in this condition (we just tracked if people tapped on the place where an icon would normally be), but an important reminder that users typically choose to interact with obvious signifiers.

For none of the icon conditions was there a statistically significant tendency to tap on the icon more than on the label except for the caret (p<0.01) —  in other words, when the accordion was signaled by a caret, people tended to tap more on the icon than on the label. For all other icons (arrow, foil, plus), there was no statistically significant preference for the icon.

What Participants Expect to Happen

To analyze the responses to the post-task question (regarding expectations to stay on the page) we defined the new-page expectation as a binary variable quantifying  whether participants expected to stay on the same page (0) or go to a new page (1). A rate of over 50% for a particular signifier indicates that overall people expected to go to a new page. For an accordion, where we want to convey that the page won’t change, the rate should ideally be under 50%.

None of the standard-icon rates were significantly different from 50%, indicating that there was no strong expectation related to them — people did not necessarily expect to stay on the page or leave the page. With the foil and the no-icon conditions, however, there was a significant expectation that people will leave the page.

For the standard signifiers (caret, plus, and arrow), there was no strong expectation to leave the page (as the rate of new-page expectation is not significantly different than 50%, p >0.05).  Among all the standard signifiers, the caret has a significantly stronger expectation to stay on the page than the foil (p<0.05) or the no-icon condition (p <0.05) and the plus is significantly better than the foil (p<0.05), but not than the no-icon condition. The arrow is not statistically different than the foil or no-icon conditions, suggesting that this icon should not be used for accordions.

Key Findings

Our hypothesis was that having no icon would cause users to expect that tapping on the menu item would take them directly to a new page, and this hypothesis held up in our study. Likewise, the foil icon was presumed to not have any association for users with opening an accordion, and this also held up.

Then, we compared users’ reported expectations of the caret, plus, and arrow icons to the foil or no icon, as a test of whether or not they were superior signifiers for an accordion. We also looked at whether people tend to tap the label or the icon for these different signifiers, under the assumption that, if indeed there is a strong tendency to tap only on one of them, we could, perhaps, separate the functionality of the two (a la split buttons).

  • For accordion patterns, people tend to tap fairly equally on the icon and on the label for most standard icons. The only exception is the caret, where people tend to tap somewhat more on the icon, but still 29% of the taps fall on the label. This suggests it’s not safe to use split buttons for accordions — where the text label links directly to a landing page, but the icon opens the accordion.
  • Making up new icons for accordion signifiers or using no signifiers at all is not a good idea as they violate users’ expectations (which are that they will be taken to a new page).
  • None of the standard signifiers have a strong association with staying on the page. That being said:
    • Using a caret is definitely better than using no icon at all or a random icon in terms of conveying the expectation to stay on the page (and open an accordion).
    • Using an arrow or a plus is not better than using no signifier at all.

  • When no icon was present, users tended to tap on the text label, rather than the empty space in that row. While an obvious finding, this is more evidence that users tend to interact with strong, clear signifiers.
  • Interestingly, using a right-facing arrow icon (as opposed to a plus or caret) was NOT significantly associated with an expectation of going directly to a new page.  While many designers might think that an arrow icon implies “go directly to a page” whereas the same icon pointing down implies “open an accordion here on the page” that was not supported in our data.

Design Recommendations

  • If using accordions in your mobile menus, the caret appears to be the safest icon choice.
  • Do not have icons and text labels link to different actions (i.e. label directly to page, icon opening an accordion).  Our study findings further support our previous recommendations that you should not use split buttons for accordions. Our study showed that users tapped fairly equally on both the text label and the icon and did not expect them to do different things.
  • Decide if your menu items will either open a submenu accordion or go directly to a category-overview page.  If you choose to have your menu items link directly to a landing page, do not use a right-aligned icon.

Summary

Users tend to click fairly equally on both the accordion icon and the accordion label, so avoid dissociating those by assigning them different functionalities.  Use a caret icon to designate an accordion, whether on desktop or mobile — our study found that of the standard set of icons used in this context, only the caret performed better than either no icon or a nonsense icon at indicating that than it was an accordion.

Useful Books For Designers Working On Complex Problems

Mike's Notes

Another wonderful resource list from the one and only Vitaly Friedman of Smashing Magazine fame.

There were too many links to copy here, so check out the original post.

Thanks, Vitaly. 😎

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Smashing Magazine
  • Home > Handbook > 

Last Updated

12/09/2026

Useful Books For Designers Working On Complex Problems

By: Vitaly Friedman
LinkedIn: 14/08/2026

Vitaly Friedman: Vitaly Friedman loves beautiful content and doesn’t like to give in easily. When he is not writing, he’s most probably running front-end & UX workshops. He loves solving complex UX, front-end and performance problems. He also runs Smart Interface Design Patterns, a video course and UX training for passionate UX designers.

...

Chances are high that you are working on a challenging, complex product. And perhaps in a difficult and heavily restricted environment, too — a workplace with deep organizational hierarchy, domain complexity, entrenched culture, untamed legacy and conflicting priorities from opinionated stakeholders at every turn.

How do you thrive and survive in such environments? Well, there are no quick answers to that question. A few weeks ago I stumbled upon a fantastic overview by Daniel Burka, with books for designers who are setting out to make a lasting difference — in healthcare, education, public service, climate change. So I thought I'll put together a few of my personal book recommendations as well. Let's take a look.

My personal book recommendations for designers working on hard, complex problems.

My Personal Book Recommendations

  • How Big Things Get Done, by Prof. Bent Flyvbjerg and Dan Gardner. Fantastic research on why complex projects run late and over budget, why right-to-left thinking matters and how to minimize risks of failures and delays.
  • Factfulness, by Hans Rosling. A fantastic book on how to better understand messy reality by learning where progress has happened, where challenges remain and how evidence can guide better decisions.
  • The Phoenix Project, by Gene Kim, Kevin Behr and George Spafford. A fictional novel, but a truly insightful book on the importance of flow, bottlenecks and operations in a product/IT company.
  • The Goal, by Eliyahu Goldratt. A legendary classic on improving a system by finding and fixing bottlenecks — for PMs and product or staff designers.
  • Thinking in Systems, by Donella Meadows. Probably the clearest guide I could find about systems thinking, feedback loops and how to intervene at the right time, with the right pace at the right place.
  • Algorithms to Live By, by Brian Christian and Tom Griffiths. An insightful deep-dive into how people make daily decisions, and how to deal with overwhelming choices.
  • The Culture Map, by Erin Meyer. A wonderful book on how to communicate and work with truly global teams across cultures — from feedback and trust to collaboration and decision-making.
  • Articulating Design Decisions, by Tom Greever. A very practical strategic book on how to communicate UX work effectively to senior management and people who need to approve your work.
  • Narrative Economics, by Robert Shiller. A book focused on economy, but really about how ideas move markets. A great read on how contagious stories, not just data, drive decisions, events and spread impact over time.
  • Envisioning Information, by Edward Tufte. A deep, dense classic on how to deal with complex data and how to display it to maximize clarity. A must-read for every data visualization work.

Not really books for designers, and not books about design either. But great books about planning and thinking: How Big Thigns Get Done and Algorithms To Live By.

  • The Great Mental Models, by Shane Parrish. How people think, grasp new areas, find patterns and understand the world. A lovely series about mental models and how people think.
  • A Pattern Language, by Christopher Alexander. Actually a book about patterns in architecture, but also about how spaces are organized, and how to think of living and working systems.
  • Org Design for Design Orgs, by Peter Merholz, Kristin Skinner. How to build, structure and scale in-house design teams — on hiring, roles and operating models. Not a topic that's often covered.
  • Thinking in Bets, by Annie Duke. Perhaps a bit of a cliché recommendation, but a lovely book on how to make better decisions under uncertainty, when you don't have enough evidence.
  • The Missing Billionaires, by Victor Haghani and James White. To me, a fantastic book about risk management without being a risk management book. How to strategically approach risk and financial decisions over a long period of time.
  • Why Design Is Hard, by Scott Berkun. A lovely little book about the inherent complexities and challenges of the design process.
  • Practical Charts, by Nick Desbarats. The only practical guide to charts that I found incredibly easy to understand. A must-read for data viz and dashboard design.
  • The Laws of Simplicity, by John Maeda. A classic. A very short book that entirely changed how I think about design decades ago.

New Books For UX and Interface Designers

There are quite a few new UX books that I have on my reading list (and had on it for quite some time), but actually didn't yet find time to get into. So if you're looking for a new book for yourself or for your colleagues, here are a few recent ones that caught my attention (published between 2025 and 2026). I hope you'll find them useful, too.

UX & Product Design

  • Inviting Depth: Richer Research Interviews, by Brandon Berry PhD, Thomas Williams. How to conduct more meaningful research interviews and help researchers uncover deeper insights from users.
  • Research Practice, by Gregg Bernstein. With practical advice and frameworks for effective and ethical research practices.
  • Sentient Design, by Veronika Kindred, Josh Clark. A practical book on how to use AI effectively to design "intelligent" experiences, with many useful insights and practical techniques.
  • UX for AI: A Framework for Designing AI‑Driven Products, by Greg Nudelman. Quite technical at times, but packed with real case studies of how products teams design and build AI experiences from scratch. Currently reading.
  • The Designer's Guide To The Buttons, by Andrey Markelov. Actually a mix of a history book about interfaces and UI components — a comprehensive visual guide to the history, logic, and evolution of user interfaces, from Xerox Alto to Vision Pro.
  • Building The Research Engine, by Julian Della Mattia. A practical guide on how to set up a research practice from scratch and how to make sure that research efforts are noticed and its outcomes are actually used.

  • Shift Happens, by Marcin Wichary. An extensive (!) research on the history of keyboards, keyboard layouts — from early typewriters to the pixellated keyboards in our pocket. Sadly sold out at the moment.
  • Designed With Care, curated by Rachel Edwards. A beautiful overview of how to create inclusive trauma-informed content across various domains.
  • Staff Product Designer, by Artiom Dashinsky. A very honest and practical deep-dive into senior product design roles and career progression.
  • Everything is a Prototype, by Brendan Kearns. How to prototype better, with tools for more productive experimentation.
  • Accessible UX Research, by Michele A. Williams, PhD. Our new Smashing book, on how to conduct inclusive UX research — from planning and recruiting to facilitation, asking better questions, avoiding bias and building trust.
  • Good Services, by Lou Downe. Focuses on the principles behind designing digital services that actually work for people.
  • The Solo: Grow Your Own Digital Products, by Christine Vallaure de la Paz. A practical guide for designers looking to create and scale up their own digital products.

  • The Making of Prince of Persia: Journals 1985–1993, by Jordan Mechner. Per se not a classic design book, but a deep dive into how the legendary game I was playing for months came to be.
  • The Core Model Digital Strategy, by Are Halland. How to approach digital strategy and more strategic, collaborative design.
  • The Path to Senior Product Designer, by Artiom Dashinsky. Another book by Artiom, focusing on the journey and skills required for senior-level product design.
  • Hey UX, Hey PM, by Jeff Carpenter. Interesting: explores collaboration and communication between designers and product managers.
  • The Staff Designer, by 🐱 Catt Small 👩🏾💻. A guide for staff ICs on how to grow, influence, and lead effectively without moving into people management. Catt has a great Maven cohort as well.

Dashboards and Data Visualization

  • CHART: Designing Creative Data Visualizations from Charts to Art, by Nadieh Bremer. Very high on my list as I would trust Nadieh on everything data visualization! How to transform data into impactful visual narratives, moving beyond standard charts.
  • Dashboards That Deliver, by Steve Wexler, Jeffrey Shaffer, Andy Cotgreave, Amanda Makulec. New book on designing impactful dashboards with insights and drive action.
  • Speak Data, by Giorgia Lupi, Phillip Cox. An interesting book on how to communicate complex data effectively. Great for a kitchen table, too!
  • Practical Charts, by Nick Desbarats. A hands-on guide to designing honest and functional charts, with useful decision trees to use.

Cards & Cheat Sheets

For quick reference, here are few lovely card decks and cheat sheets:

  • Storyteller Tactics, by Steve Rawling. A legendary deck of cards to design compelling narratives for presentations and user stories.
  • UX Research Cheat Sheets, by Stéphanie Walter. Helpful user interview question cheat sheets, question cards and UXR workshop templates.
  • UI Fonts Checklist, by Oliver Schöndorfer. A practical guide to selecting typefaces for UI design.
  • Smart Interface Design Patterns, by yours truly Vitaly Friedman. My little collection of useful checklist cards for pretty much any UI component!

“But What About AI?”

There are strong voices arguing that many of these books belong to the pre-AI era, and hence they are slightly outdated and not particularly useful.

I strongly disagree. I don't really think that AI makes these books less relevant today — if anything, AI probably amplifies a desperate need for these books to be written and published and read. And I don't think AI can turn good intentions with poor ideas into good design — even with the best context and design harness provided to it.

In the world where we can generate hundreds of flows and prototypes quickly, or hyper-personalize experiences to every individual user, we need to make very, very good decisions on which flows are driving us towards a goal, and how our work drives users to their goals as well.

The books above are about better judgment, about critical and strategic thinking, human-led research, better sense-making and decision making. AI can surely augment it, but the quality lies in humans curating and choosing directions and making better decisions as a result. I'm quite skeptical about people allowing AI to fully take over decisions any time soon.

Useful UX Book Lists

And just in case you need more specialized book recommendations — for entrepreneurs, researchers, accessibility professionals, product managers or behavioral scientists, here are a few useful bookmarks of recommendations by other fine folks.

50 Short Books For Designers, brought together by David Demaree and the team at Bits&Letters.

  • 50 Short Books For Designers, a wonderful directory of free and non-free books, published by A Book Apart, but then disappearing from the web — now brought together in one single place, with freely available versions, references and links in one place. Kindly put together by David Demaree and the team at Bits&Letters.
  • Free Books For Interface & UX Designers
  • Book Recommendations, by Stripe Press
  • UX Research Books, by Stéphanie Walter
  • Inclusive Design Books, by Jessica Ivins
  • Books For Accessible Products, by Cat Noone
  • Books For Entrepreneurs, by Intercom
  • Product Management Books, by Paweł Huryn
  • Behavioral Science Books, by Robert Meza
  • Data Visualization Books, by Nadieh Bremer
  • Business Books For Designers, by Chris Do
  • Interface Design Books, by Adham Dannaway

Wrapping Up

The world desperately needs patient and passionate designers to improve the messy, complex and legacy-ridden systems that are so common and so frustrating in daily lives of millions of people.

You might feel stuck — in enterprise environments, education, healthcare and public services; yet that's exactly where your design work can make a tremendous impact for people who need it the most. It's at times a painful but extremely rewarding experience, as long as you bring along enough patience and care.

Just one final note. Many of the authors above also provide an incredible amount of free content for everybody to use and learn from. I kindly encourage you to support their work if you can, and always purchase books from their own recommended sources, rather than discount retailers. 

Do you have books you'd add to this list? I'd love to hear your recommendations for books that made a difference for you — please leave a comment below. I try my best to read and answer every single comment and email I receive, so please don't hesitate to reach out.

What I’ve learned writing for billions of users

Mike's Notes

I came across this gem in Smashing Magazine.

"What are the takeaways from writing for billions of users across dozens of languages, time zones, and cultures? Nick DiLallo has summarized everything he has learned writing for products used by a meaningful percentage of the world’s population. The result is a list of 70 valuable lessons learned that you can apply to your own writing right away." - Smashing Magazine

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Smashing Magazine
  • Home > Handbook > 

Last Updated

25/08/2026

What I’ve learned writing for billions of users

By: Nick DiLallo
Medium: 03/08/2026

Nick DiLallo is a writer based in Brooklyn. Past clients include Apple, Airbnb, Etsy, and Google. He currently leads UX writing at Clay.

...

Insights from products that grow and grow.

...

A few years ago, after running a complex global product launch, I wrote down everything I learned. To track my own ideas. To make sense of things. I’ve kept adding to it ever since.

I’ve worked on products used by a handful of people and products used by a meaningful percentage of the planet. The second kind taught me things the first never could.

This is what I’ve picked up along the way, writing for billions of users across dozens of languages, time zones, and cultures. Some of these lessons are about words. All of them are about people.

...

01: Most interfaces are mostly words. Take away all the text and screens stop making sense.

02: When you have a giant user base, people will interact with your product in ways you never intended. You’ll be shocked. You’ll also learn from them.

03: Good interfaces don’t need instructions. If you need to write things like “look for the arrow” or “scroll right,” the UI needs fixing. Words shouldn’t explain the design.

04: Naming features is hard. Renaming them is nearly impossible, especially if millions of people have already started using the product. You get one chance to get it right.

05: The typeface matters as much as the writing.

06: People have high expectations for software, and that includes the writing. World-class products don’t have mistakes, typos, or clunky phrasing.

07: Saying one thing is better than saying two or three things.

08: Fixing the writing can fix the entire company. Support tickets go down by the thousands. Conversion goes up. Users stay longer. There’s a reason the world’s best companies hire and value talented writers.

09: A shorter sentence is almost always a better sentence.

10: It’s always a good idea to fix things. You don’t need a rigorous business case for it. Don’t waste time trying to calculate the ROI of spelling “Connecticut” correctly.

11: People won’t read everything you put in the interface. They’ll skim and scan and scroll to what they want. You need to write for those people.

12: Rewrite everything twice. Rewrite important things twelve times.

13: Our relationship with technology changes. Writing can shape that change. Remember, we used to be afraid of using our real names online or entering our credit card.

14: Good writing just feels different. This can be hard to explain to non-writers. There’s a certain kind of click that happens in your head. Revise until you get there. You’ll know it when it happens. Developing this instinct takes a long time.

15: With a giant user base, you can get stuck trying to write “for everyone.” Try writing for one specific user. An Olympic athlete struggling to set a new record. A first-time mom who’s using your product at 4am. A surfer on their honeymoon in Tahiti. Choose one person and write.

16: Longer writing needs to be worth it. We expect more from a paragraph than a headline. Make everything the right length.

17: Users will read what you wrote, then do the exact opposite. It’s okay.

18: Details matter. The best teams spend time arguing over formatting and punctuation. Is it $45 or $45.00 or 45 (USD)? Do we say “July 5th” or “Next Tuesday”? Is it Settings or Preferences? You need to decide.

19: More opinions can sharpen your work.

20: Sometimes the last thing you need is more opinions.

21: A perfect error message is still an error message. Try to fix the root cause. Smarter inputs, clearer phrasing. An error is a last resort.

22: Words can’t do everything in an interface. Understand where other forms of information can help. A great description of a hotel room is no match for a photograph. A street address doesn’t show the same context as a full map.

23: Writing quality signals product quality. Users make judgments based on the writing. You can’t ask someone to trust you with their private data if they can’t trust you with your commas.

24: Small wins add up. A clearer headline here. A shorter error message there. A more direct call to action somewhere else. Fix enough little things and the product will completely transform.

25: Actions matter more than words. You can’t write one thing and do another. Don’t call it a “free trial” and then require a credit card. Don’t say chats are private if they aren’t. If you’re using writing to hide features or “convince” users, that’s a problem.

26: Most brand voice guidelines aren’t very helpful. Because most don’t say anything interesting or unique. Calling your brand voice “human” is not enough.

27: It’s usually a good idea to trust writers with writing. I’ve seen products fail because the wrong person was making decisions about words.

28: Grammar should be internalized. Learn the rules and break them when it feels right. But don’t talk about grammar too much. Using the phrase “past participle” in a meeting won’t get anyone excited. It’ll make them think of high school English class.

29: It’s hard to scale your product with a vague, meaningless value prop.

30: Tell the truth. I’ve seen a single vague sentence generate more support tickets than an actual outage. If something will take nine minutes, say it will take nine minutes.

31: Don’t invent words when you don’t need to. Digital products have a shared vocabulary that users already understand. Stick with common words and phrases. Log in. Save. Delete. Update. Edit.

32: Be careful about overwriting. This was something I saw lots of products doing for a long time, adding too much personality and too much text. Making a product “conversational” can sometimes just make it annoying to use.

33: A great onboarding will solve much more than an endless help center. First-time users who get confused don’t file tickets. They just leave.

34: You can’t evaluate writing in a spreadsheet or doc. Put the words in the interface and see how they read. Read them in the prototype. Read them on the device you’ll be using. Get as close to the real experience as possible.

35: Language is always changing. It happens faster than you think, and it’s the job of a writer to keep up. Look at the way people younger than you communicate, or the way your parents email. Nobody’s right or wrong. Language just moves.

36: Write without My or Your. Don’t call it My Photos or Your Photos. Just call it Photos. If you don’t, you’ll be chasing this down forever and confusing everyone along the way.

37: Writers who understand how products are built make better decisions. Learn as much as you can about strategy, technology, and business. A writer should understand how a company makes money and what their long-term vision is. Get as close to the decision-makers as possible.

38: Come back and read it tomorrow. Time away always helps.

39: If someone is using your product, they’ve already decided. Don’t market to them. You might talk them out of it.

40: Pick a word for something and use it everywhere, across every screen, for every user. Don’t call it a “folder” on one screen and a “workspace” on another.

41: Trust your own instinct as much as you trust your user research.

42: Users don’t know — or care about — your org chart. Your brand should have a single voice. It doesn’t matter if your emails, notifications, and support documentation come from different teams. Get everyone aligned.

43: Be careful with playfulness. A button that says “Pay” is clearer than one that says “Ka-chingggg.”

44: Word and image should work together. Give users context.

45: The things we build often reflect who we are. Selfish people build selfish products. Kind people build kind ones. To build the best product, build the best team and hire the right people.

46: Remember that translating for global products is a lot more complicated than swapping out text. Different languages reflect different cultures — and sometimes entirely different ways of thinking.

47: Be careful about making too many decks. You’ll start thinking in keynotes and bullet points, not UX and interface decisions.

48: Language has power. Writing makes people laugh and sob and get angry and feel joy and connect with other humans. A gradient can’t do that. A date picker or corner radius can’t do that.

49: Sometimes words can convey multiple meanings. “New” can mean exciting, but also unproven. Calling a transaction “safe” might make the user worry. Think about every word and what else it might be saying.

50: Not everything needs a login or account. Let people use your product. If they like it, they’ll stick around.

51: Not everything needs to be a subscription, either.

52: You get better by writing more. There’s really no shortcut to this one.

53: Know that your tools as a writer will keep changing. You’ll be working differently and using new software in 5 years. Maybe sooner.

54: One of the biggest challenges you’ll face is translating your product into right-to-left languages like Arabic or Hebrew. The entire UI starts to break. Icons, progress bars, and indicators might appear backwards. Build a writing system that can flex across all layouts and languages.

55: Never, ever mess around with money. There is no faster way to lose trust or infuriate a giant user base. Tell people what things cost. Don’t add “convenience fees” at checkout. Keep auto-renew off by default.

56: Good writing can’t fix a bad product. But it can reveal problems faster.

57: Get the first draft done. A bad draft is better than a blank screen.

58: Bringing writers in early is always a good idea. You can tell when a writer was added to the team the week before launch.

59: Delete as much as you can.

60: Good writing is not enough. You also need good layout, hierarchy, and typography.

61: The legal team will ask you to add words. Rewrite them so they make sense to regular people.

62: Laws are different everywhere. Required disclosures in Australia are different from those in California or the EU. Create different versions of the same screen if you need to. Don’t try to create one “hero version” that appeases everyone. It will end up being the clunkiest option.

63: Avoid the word “content.” It devalues everything it tries to describe. A film is not “content.” Writing is not “content.”

64: Users aren’t stupid. But they’re sometimes busy or distracted or tired.

65: Your writing will teach people how to think about your product. Clear language creates clear thinking. Vague or inconsistent language does the opposite.

66: Deliver bad news quickly and clearly.

67: Write for the user, not the press release or launch video. Too many companies get this wrong. They start with the marketing assets and then try to build the product around it. It usually doesn’t go well. Designing a screen for a keynote is different than designing it for a user, and great marketing won’t ever be able to fix usability issues.

68: It’s better to write something well the first time. A ten-second fix, multiplied across a billion sessions, is measured in years, not minutes.

69: If you’re making changes but things aren’t getting better, try fixing something other than the words. Use different components. Add animation. Adjust the navigation. Keep trying new ways to make the UI better. Don’t just rewrite. Rethink.

70: Accessibility can’t be layered on top of good writing. Turn on a screen reader and listen to your own writing. Use your product with different settings. You need to understand how people actually use your product, then write for them. All of them.

71: Build writing guidelines and documentation in the tools your team actually uses. Don’t make a PDF that never gets opened.

72: Users notice inconsistency before they notice almost anything else.

73: If you’re stuck, close your laptop and go outside.