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

• https://www.linkedin.com/pulse/useful-books-designers-who-work-complex-problems-vitaly-friedman-v237f/
• https://www.hardproblems.com/articles/books-designers-hard-problems

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

• https://uxdesign.cc/what-ive-learned-writing-for-billions-of-users-f4db0c1aa9cb
• https://nickdilallo.com/
• https://www.smashingmagazine.com/

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.

Realworld AI Coding Agent Exercise

Mike's Notes

An open-source version of Virtuoso will be installed in the data centre to explore possibilities. Kingsley Uyi Idehen's articles are all fascinating. I first came across him via the Ontology Forum.

The original post on LinkedIn has more links.

Resources

• https://www.linkedin.com/pulse/realworld-ai-coding-agent-exercise-kingsley-uyi-idehen-pxdic/
• http://www.openlinksw.com/
• https://www.openlinksw.com/data/screencasts/new-fct-demo-1.mp4
• https://linkeddata.uriburner.com/fct/facet.vsp
• https://www.linkedin.com/pulse/building-llm-wikis-turn-any-document-url-living-queryable-idehen-u4zue/

References

• Reference

Repository

• Home > Ajabbi Research > Library >
• Home > Handbook > 

Last Updated

08/04/2026

Realworld AI Coding Agent Exercise

By: Kingsley Uyi Idehen

LinkedIn: 07/02/2026

Founder & CEO at OpenLink Software | Driving GenAI-Based AI Agents | Harmonising Disparate Data Spaces (Databases, Knowledge Bases/Graphs, and File System Documents).

This post explains how I used Claude Code (Pro level, powered by Opus 4.5) and Mistral Vibe (whenever Claude Code rate limits kicked in) to modernize the aesthetics of our uniquely powerful faceted search and browsing interface for knowledge graph exploration—essentially giving the UI around the core engine a facelift.

At OpenLink Software, we strongly believe that LLM-powered AI Agents are exactly the right tools for tackling this long-standing challenge—provided the RDF-based knowledge graph runs on a platform that isn’t constrained by dataset size. In other words, one that scales naturally in linear fashion—such as our Virtuoso multi-model platform for managing data spaces spanning databases, knowledge bases, filesystems, and APIs.

Situation Analysis

As with many aspects of RDF (Resource Description Framework), challenges in tooling creation often stem from general misunderstandings about the framework itself. RDF-based knowledge graph representation is one such area, and linear visualization is another.

In the case of linear visualization, the goal is to present the description of an entity of interest (the subject) along with its associated attributes—i.e., predicate–object pairings that express attribute names and values.

Compounding the difficulty is the fact that, although faceted search UI/UX patterns have long served as the conceptual foundation, implementing them at the scale typical of RDF-based knowledge graphs remains extremely challenging. This challenge is further amplified by the complexity of delivering such interfaces in HTML leveraging CSS and JavaScript.

Virtuoso's Faceted Search & Browsing System Workings

Fundamentally, this system allows you to perform text search, attribute-name lookup, or entity-identifier–based exploration across one or more knowledge graphs hosted in a Virtuoso instance. It provides a property-sheet–style interface that presents entities (subjects) alongside their associated attributes (relationship predicates) and values (objects).

Thanks to Linked Data principles, hyperlink-based denotation of entities, attributes, and values (optionally) creates a Web of data. This enables the same “click and explore” experience—also known as the follow-your-nose exploration pattern—that users enjoy when interacting with web pages through a browser.

Old System

Here are screenshots depicting the UI/UX for a simple search sequence along the following lines:

• Text Search Input: Virtuoso.

• Initial matches presented in a list, sorted by text score and entity rank (think: page rank for data).

• Add filters by attributes such as "type" (rdf:type) and "name" (schema:name) where the name value is "Virtuoso".

• Click on item from the result to obtain a description of Virtuoso via the entity description property sheet based page.

New System

Original resource: New Virtuoso Faceted Browser Showcase Screencast

Here's the same demonstration sequence, but experienced via the revamped UI/UX.

• Text Search Input: Virtuoso.

• Initial matches presented in a list, sorted by text score and entity rank (think: page rank for data).

• Add filters by attributes such as "type" (rdf:type) and "name" (schema:name) where the name value is "Virtuoso".

• Click on item from the result to obtain a description of Virtuoso via the entity description property sheet based page.

Additional Notable Faceted Search & Browsing Features

These include the following:

1. Handling the fact that lots of attributes (thousands+) could be associated with an entity sources for a massive collection of source knowledge graphs during the filtering stage via a sticky scrollable paging control
2. Handling the fact that a select entity description can also comprise lots of attributes (thousands+) via a stickly scrollable paging control
3. Spreadsheet-like table (with resizable, moveable, and sort enabling columns) for handling query results from filtering or when presenting entity descriptions
4. Ability to export the description of an entity in a variety of formats (JSON-LD, RDF-Turtle, RDF-XML, N-Triples, RDF/JSON, CSV, etc)
5. Permalinking for sharing interaction state e.g., a filter page or entity description page
6. Ability to reveal underling SPARQL query that drives filtering
7. Metadata that provides information on source named graph(s) from which attributes and values have been sourced for an entity description by way of entity (subject) or value (object) role in the source graph triples
8. Metadata that automatically identifies explicit (via owl:sameAs attribute values) coreferences (via values of attributes that are uniquely identifying i.e., inverse-functional e.g., email addresses or any other attribute with the inverse-functional designation in a loaded ontology)
9. Settings for enabling or disabling reasoning and inference informed by built-in or custom inference rules

The Refactoring Process

I achieved this very difficult refactoring task, alongside my other daily duties, by prompting Claude Code and Mistral. Claude Code (using the Opus 4.5 model) handled most of the heavy refactoring and planning work through the initial working ports.

I brought Mistral on board once rate limits kicked in, which became an important part of the experiment—namely, determining what’s possible with the Pro edition of Claude Code.

That said, Mistral also impressed me to the point where I see it as the closest rival to Claude Code in the battle for coding agent market dominance. Its CLI aesthetics and assistance mode are top-notch.

Live Demonstration Instances

URIBurner

This is a live Virtuoso instance since 2008 functioning as a Linked Data utility showcase and bridge to the massive Linked Open Data Cloud Knowledge Graph collective.

1. Text Search: Virtuoso
2. Entity Types associated with text pattern: Virtuoso
3. Attribute Filtering on Type, Name, and Value: Virtuoso Universal Server (Row Store & Cluster Server Edition)
4. Selected Entity Description Page

Conclusion

Software development is evolving before our eyes. True power now comes from pairing capable AI Agents with human expertise—letting judgment guide automation, producing dependable outcomes, and delivering real-world value. The age of AI isn’t just about smarter tools; it’s about amplifying what humans do best.

Why So Many Info Tips Are Bad (and How to Make Them Better)

Mike's Notes

Another excellent article from Kate Kaplan that I can use to configure the CMS Engine (cms).

Resources

• https://www.nngroup.com/articles/info-tips-bad/
• https://www.nngroup.com/articles/tooltip-guidelines/
• https://www.nngroup.com/books/digital-icons-that-work/
• https://www.nngroup.com/articles/gestalt-proximity/
• https://www.nngroup.com/articles/microcontent-how-to-write-headlines-page-titles-and-subject-lines/
• https://www.nngroup.com/articles/interaction-cost-definition/
• https://www.nngroup.com/articles/deceptive-patterns/

References

• Reference

Repository

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

Last Updated

23/03/2026

Why So Many Info Tips Are Bad (and How to Make Them Better)

By: Kate Kaplan

The NN/g Newsletter: 23/01/2026

Kate Kaplan specializes in applying human-centered design and research practices to enterprise UX challenges. With over 15 years in UX, Kate has extensive experience in both conducting research and helping teams understand and apply user insights to overall business strategy.

Summary:

Information tips can clarify complex UIs, but they should not hide essential information, trigger redundant information, or disrupt the current workflow.

Information tips — those helpful little messages triggered by tapping or hovering over a question mark (?) or info (i) icon — can help users make faster decisions and increase the understandability of UI elements. But in practice, they’re often overused, misapplied, or bloated with unnecessary content. When info tips hide essential instructions or bury users in redundant explanations, they create confusion rather than clarity.

In This Article:

• What Is an Info Tip?
• Representing Info Tips in User Interfaces
• The Problem with Info Tips
• Pitfalls of Bad Info Tips
• Pitfall #2: Hiding Critical, Task-Assistive Information
• Pitfall #3: Interrupting the Task Flow

What Is an Info Tip?

An information (info) tip is a brief, contextual message designed to offer supplemental information about a specific interface element or step in a workflow.

It’s typically activated by hovering over or clicking on a small icon — often a lowercase i or a question mark — and is attached to a specific element within the interface (e.g., a text field, icon, button, label).

✅ An example of a useful info tip from the Ease Employment Benefits Portal: Clicking on the ? icon reveals a concise explanation about why specific data is collected and how it’s used.

Info tips can be revealed through two primary patterns:

• Tooltips, which appear on mouse- or keyboard-hover gestures within desktop sites
• Popup tips, which are similar to tooltips, but are triggered by clicking or tapping an element’s associated icon

Both types serve the same core purpose: providing extra context to those who need additional clarification or guidance without overwhelming the interface with text.

Representing Info Tips in User Interfaces

The i Icon: General Information

The encircled lowercase i icon is broadly understood to indicate optional, helpful information.

In our icon-related research, participants interpreted the i icon primarily as representing an option for “more information” and expected it to reveal supplemental information such as:

• Definitions
• Additional details or brief explanations
• Promotional terms

This makes the i icon a good fit for general information or nice-to-know guidance, but not urgent or error-related content. It is a solid choice for representing info tips that support user understanding without interrupting flow.

The ? Icon: Help and Support

The encircled question-mark icon (?) is also used frequently to trigger info tips. In our research, it was more strongly associated with help and support than with general supplemental information.

People expected this icon to lead to:

• FAQs
• Customer-support contact information
• Help content or tutorials

However, when placed directly next to a specific interface element (such as the form field label in the example above) the ? icon is also an effective trigger for contextual help about a specific element. The key is proximity: When the icon is close to what it refers to, users interpret the help as local and relevant, rather than global or generic.

The Problem with Info Tips

Unfortunately, info tips are often abused as band aids in the interface, used to:

• Cram in explanations that should’ve been designed into the UI
• Hide critical instructions in the name of a “clean” interface
• Offload poor labeling or UX copywriting onto the user

Info tips are not a catch-all solution for decluttering the interface by sweeping essential content into a hidden layer. Nor should they be used to bury large amounts of information that disrupt users’ flow when revealed — what we call the “jump scare” scenario, where a user expects a quick tip but gets an entire modal or screen takeover instead.

But info tips aren’t inherently bad. When well-implemented, they offer concise, helpful, and contextual information that improves usability without cluttering the interface.

Well-crafted info tips can:

• Clarify jargon or technical terms
• Explain why specific data is requested
• Guide users to locate needed information
• Reassure users about data usage

However, a good rule of thumb is to assume that most users will never see the info tip. Those who do have extra motivation for seeking them out are confused, stuck, or need clarification or reassurance. That’s why info tips should deliver clear, in-the-moment guidance that directly supports the user's immediate task.

Pitfalls of Bad Info Tips

Info-tip misuse generally falls into three categories:

• Wasting users’ time: Displaying obvious, redundant, or irrelevant information
• Hiding critical information: Burying essential guidance or constraints most users will need upfront
• Interrupting the task flow: Using intrusive patterns such as modals or overlays that take users away from the task at hand

Pitfall #1: Wasting Users’ Time

Every info-tip interaction — even just that one small click or hover — incurs a small but real interaction cost. Redundant or obvious tips waste users’ time and undermine trust.

Don’t use info tips for:

1. Marketing fluff
2. Restating visible content or instructions
3. Reexplaining the obvious

Info-tip icons like the i or ? signal to users that something might be unclear or needs elaboration. When they instead reveal generic marketing fluff, users can feel misled and frustrated.

❌ Doodle.com: The info tip displays marketing information (The quickest way for two people to meet) to further sell the Schedule 1:1s feature.

Info tips also waste time when they restate what’s already perfectly clear in the interface. These tips give the illusion that additional explanation exists, but deliver only repetition.

❌ State.gov: Clicking the i icon next to the City of Birth form field triggers the message: Enter the city of your birth. These tips simply repeat what's already on the screen, making users feel like there's more to learn when there isn’t.

❌ In this example, a ? icon next to Paper Type appears promising. Users might expect guidance on how to choose between options like Satin, Gloss, or Uncoated. Instead, it produces an obvious, unhelpful message: Choose your preferred paper type from the options below.

Pitfall #2: Hiding Critical, Task-Assistive Information

Info tips should not be used to bury essential instructions, constraints, or legal disclaimers. Doing so turns important guidance into a game of hide-and-seek and could even be a deceptive pattern in some cases.

Avoid putting in info tips:

• Constraints or rules
• Form-field limitations (e.g., character limits)
• Legal agreements or disclaimers
• Complex instructions or explanations

Complex instructions that help users make decisions should be visible, not hidden in a tip. People need to reference these explanations while completing tasks, not break their flow or current view to search for guidance.

❌ U.S. Find a Grave Index: These complex explanations for proceeding with a simple task are too overwhelming for an info tip. If a task truly requires this much upfront guidance, the information should be integrated directly into the interface, where it’s always visible and easy to reference.

Instead of hiding complex instructions in an info tip, it’s more effective to display key information at the primary level of the interface. When users must weigh multiple options or make nuanced choices, surfacing that guidance upfront enables quick comparison without disrupting task flow.

✅ Microsoft Test and Learn: The design provides clear, inline explanations for the various output types (Result Grid, Trend Chart, and Category Impact) without requiring multiple clicks or hovers to reveal. This approach helps users compare outputs and quickly make an informed decision without having to hunt down hidden descriptions.

Additionally, any constraints, rules, or limitations for inputs should be displayed on the primary level.

❌ USPS.com: The form field hides character constraints within an info tip. This information should be displayed on the primary level. If the form fails due to unseen constraints, users are left frustrated and rework is required.

Pitfall #3: Interrupting the Task Flow

People expect clicking an information icon to reveal brief, helpful messages that they can reference in the context of their current workflow — not modal windows or full-page takeovers of walls of text.

Don’t surprise users with:

• Overly complex, verbose content
• Modals or overlays that block their task
• New pages that take them away from the workflow

When possible, ensure that info tips are displayed inline or adjacent to the relevant element. Obscuring the current step or view of the interface makes it harder for users to connect the guidance with the task at hand.

❌ CapitalOne mobile site: Clicking the i icon next to About payment options replaces the current view with several explanations of the different amount options. While the information is useful, the pattern disconnects users from the content they need to reference while comparing options.

Modals and full-page overlays are jarring when used for info tips. Keeping the guidance adjacent to the element it supports allows users to maintain context and better understand the relevance of the information.

❌ GSA.gov (1 of 2): Users are likely to expect that clicking the i icon next to First & Last Day of Travel will reveal a brief definition of the term as defined in the travel policy.

❌ GSA.gov (2 of 2): Instead, clicking the icon triggers a darkened overlay that obscures the workflow and a surprising modal dialog at the top of the page.

Even more disruptive is launching an entirely new page from what appears to be a simple info-tip icon. This approach not only obscures the context but also forces users to abandon their task.

❌ Nextdoor.com (1 of 2): The site displays a ? icon next to the Sign-in code field label. Users are likely to expect that clicking the icon will display a brief description of what a signin code is or where to find it.

❌ Nextdoor.com (2 of 2): Instead, clicking the ? icon next to the Sign-in code field launches a new page containing a full explanation of two-step verification. The information about where to find the signin code is buried within the verbose content.

Conclusion: Use Info Tips Wisely

Info tips can enhance clarity when they offer just-in-time, supplemental guidance within the context of the current workflow.

Do:

• Use info tips for supplemental content
• Keep them short, contextual, and easy to dismiss
• Represent them with familiar icons (i or ?)
• Assume users who activate them need quick, in-the-moment guidance

Don’t:

• Hide essential or frequently needed information
• Use info tips as a crutch for poor labeling or dense layouts
• Trigger popups or overlays that hijack the user’s focus or flow

When thoughtfully implemented, info tips reduce confusion and increase user confidence. But they should always serve the user’s goals, not the designer's desire to declutter at all costs.