Showing posts with label design. Show all posts
Showing posts with label design. Show all posts

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.

Digital Accessibility Training

Mike's Notes

I stole this content from all over the place. Sorry if I didn't credit you; I forgot where this came from. All useful stuff.

Resources

References

  • Reference

Repository

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

Last Updated

04/08/2026

Digital Accessibility Training

By: Mike Peters
On a Sandy Beach: 04/06/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Accessibility For Everyone (https://lnkd.in/dVvgMG29), a wonderful free book on web accessibility for designers, developers, content folks — pretty much everyone. Written 9 years ago, but still very much relevant today. With sections on disabilities, impairments, planning for accessibility, design and testing. Kindly released by Laura Kalbag.

Free Books on Accessibility

Giving A Damn About Accessibility, by Sheri Byrne-Haber (disabled)

PDF: https://lnkd.in/eqbz5Npw

  • Audio: https://lnkd.in/emYMbEDc

Web Accessibility In Plain Language, by Charlie Triplett

  • https://lnkd.in/e2AMAwyt

AccessAbility Playbook, by Government of Canada

  • https://lnkd.in/e2W3viJb

Appt Accessibility Handbook, by Jan Jaap de Groot, Paul van Workum CPACC

  • https://lnkd.in/e3V7eTU9

Accessibility Foundations (Free Guide), by Henny Swan

  • https://lnkd.in/erGd9vX7

WCAG 2.2 Card Deck (Updated!), by Johannes Lehner

  • https://lnkd.in/eQgDsY9j

Free Practical Books For Designers

  • https://lnkd.in/dsxAukXq

And a *HUGE* thanks yet again to wonderful Laura Kalbag and everyone sharing their insights, learnings, and experiences in wonderful resources like these — for everyone to learn from and build open. Your work doesn’t go unnoticed!

Jessica Kerr on Symmathesy

Mike's Notes

I was watching "A Learning System Made of Learning Parts" on Still Burning, an episode of Kent Beck's video blog.

Jessica Kerr joins Kent by the fire to argue that AI didn't take the programmer's job; it split it in two. The part we loved, crafting code by hand, has been commoditised like IKEA furniture. What's left is harder and more human: understanding what to build, proving it works, and stewarding the living "symmathesy" of people, code, and agents all learning from each other. They get into accelerated learning, why play is a signal you're learning, the loop that "becomes a noose," and choosing excitement over fear while the ground keeps shifting."

Resources

References

  • Symmathesy — A Word in Progress Proposing a New Word that Refers to Living Systems. Nora Bateson. Nora Bateson Foundation

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Still Burning
  • Home > Ajabbi Research > Library > Authors > Kent Beck
  • Home > Handbook > 

Last Updated

02/08/2026

Jessica Kerr on Symmathesy

By: Jessica Kerr
Jessitron: 15/04/2018

Jessica Kerr manages the Developer Relations team at honeycomb.io, because observability is one way our teams learn from our software. In speaking and teaching, Jess works across languages and communities, spreading cheerful deep thoughts. Code, tools, and people are not separable; all form the team that operates useful software.

Symmathesy is a term coined by filmmaker and systems theorist Nora Bateson in 2015 to describe a learning system made of learning parts, emphasising mutual learning that occurs within and between living contexts. Derived from the Greek roots sym (together) and mathesi (to learn), it serves as a response to mechanical, rigid frameworks by shifting the focus from individual elements to the dynamic relationships that generate evolution and adaptation.

In a symmathesy, learning is not an isolated process of acquiring information; it is an ongoing, multi-contextual process of mutual adjustment and calibration.

Collective problem solving in music, art, science, and software

A Learning System Made of Learning Parts

Everything to Gain from Thriving Southland

Mike's Notes

My notes from an all-day workshop organised for farmers, which I attended yesterday.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Thriving Southland
  • Home > Handbook > 

Last Updated

08/05/2026

Everything to Gain from Thriving Southland

By: Mike Peters
On a Sandy Beach: 07/05/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

I attended the all-day workshop "Everything to Gain" on 6 May 2026, held at the Ascot Park Hotel in Invercargill, New Zealand. Organised by Thriving Southland.

It was a day full of informative speakers on the global agricultural market, attended mainly by working farmers.



I learned a great deal from the objective data presented and from chatting with the farmers at our table. Hard times are ahead.

Thinking visually while listening

mentally ran the Workspaces for Agriculture, testing the model assumptions against what I learned.

I also did a brain dump by creating 12 A4 drawings and solving the problem with variables in the current Pipi Core buildout.

Lessons I learned

Shifting a working Pipi 9 from a laptop to a data centre led to several unexpected consequences.

I underestimated the impact of

  • The naming, generation, and pub/sub of variables.
  • Host environment.
    • OS
    • Java
    • CFML Engine
  • Needing to turn Pipi into 4 separate role-based editions, which then exposed some hidden problems.
  • Adding a nest structure between Pipi and the host environment.
  • The impact of all of the above when each engine can pub/sub and be both deterministic and probabilistic, with multiple copies of each engine, and many in different locations.
  • Path length constraint in Windows vs Linux.

This very hard problem can only be solved by running a simulation of all 18 engines in parallel and watching the interaction. Lots of feedback loops.

Yesterday, a lot of progress was made visually, answering these questions. The variable-naming convention used for 12 months has held up, despite some earlier false flags.

  • More work is needed on variable distribution rules (messaging) for automation.
    • Global
    • Local
    • etc

Today I did another 8 drawings. They were of the Messaging Engine (msg) routing variables between the engines in both deterministic and probabilistic modes.


I will sleep on all this for a few days to see if anything else pops out, then commit it to code.

Tim Cook is Leaving. Good.

Mike's Notes

The key takeaway of this copied article.

"make products you’d be proud to use yourself."

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Amazing CTO
  • Home > Handbook > 

Last Updated

05/05/2026

Tim Cook is Leaving. Good.

By: Tony Mattke 
Router Jockey: 27/04/2026

I’m Anthony Mattke, aka Tony. I’m a network engineer, infrastructure architect, and general-purpose technology geek located amidst the endless cornfields of north central Indiana. I’m a husband and father, and I hope to have superpowers one day. Seriously.

Your AirPods just connected to the wrong device. Again.

iMessage is taking twenty minutes to sync a message between your laptop and your phone sitting six inches apart. HomeKit forgot the kitchen lightbulb exists, and will remember it again in three hours like nothing happened. System Settings, which used to be one of the cleanest preferences UIs ever shipped, now feels like a bad Electron app pretending to be macOS.

These aren’t dramatic failures. They’re worse than dramatic failures. They’re daily proof that somewhere along the way, Apple stopped caring about the texture of using its own products.

This is Apple in 2026. And this is the Apple that Tim Cook built.

Cook announced his departure last week, and most of the coverage you’ll see is going to be a victory lap. A lot of it is earned. Apple is a three-trillion-dollar company. Services revenue is at record highs. Apple Silicon is one of the great hardware bets of the last decade. He took a company already at the top of its industry and made it bigger than the GDP of most countries.

So why am I glad he’s leaving? Because somewhere in all that growth, Apple stopped making products it was proud of.

What Steve Actually Said

There’s a passage in Walter Isaacson’s biography of Steve Jobs that gets quoted less than the famous ones. Jobs talked about how great companies die, and his theory was that the rot has nothing to do with competition or markets or innovation cycles. The rot starts when the salespeople end up running the company.

He named names. He pointed at IBM under John Akers. He pointed at Microsoft under Ballmer. He even pointed at the Sculley era of his own Apple as the cautionary tale. The phrase Jobs kept circling back to was that the people running these companies eventually “have no conception of a good product versus a bad product.” They can’t tell the difference. They can run a supply chain better than anyone alive, but they couldn’t tell you whether the radius on a button looks right.

That’s not a small criticism. That’s the founder of Apple, on the record, naming the disease and warning the company against catching it.

Then, in 2011, Apple promoted its head of operations to CEO.

I’m not saying Cook was a bad pick at the time. He was the right person to keep the trains running while everyone caught their breath after losing Steve. But fifteen years later it’s worth asking the question Steve himself would have asked. What kind of products are we shipping now?

The Tenet Cook Forgot

Of all the things Steve Jobs believed about Apple, one of them stands out as the most quietly violated under Cook: make products you’d be proud to use yourself.

Not just sell. Not just ship. Use. Sit down at the Mac on a Tuesday night, put your AirPods in, fire off a Message, set up a HomeKit automation, and feel proud of every single one of those things working the way you wanted them to.

Today’s Apple doesn’t pass that test. And the failures aren’t dramatic ones. They’re the small, persistent, daily-friction kind that the founder used to personally drive teams to fix.

You know the list. The 2022 System Settings redesign managed to take a perfectly usable preferences app and ship it as something worse, then leave it that way for three OS releases and counting. Notifications have been re-architected three times in five years and still work inconsistently across iOS, iPadOS, and macOS. Mail rules have been broken since the Obama administration. The Photos library will quietly drop items, sync ghosts, and offer no diagnostics when something goes wrong. HomeKit loses devices the way a child loses socks. Spotlight returns stale results and pauses for seconds at a time on hardware that should make it instant.

Each one of these, on its own, is just a bug. Together, they’re a culture.

They survive because they don’t move metrics. They don’t reduce revenue. They don’t show up in the quarterly. But they’re exactly the kind of paper-cuts that would have annoyed Steve at 9pm on a Tuesday, and they would have been fixed by Wednesday morning.

That’s the difference. Steve used the products. Cook signs the budget.

Before Someone Says This Is Just Nostalgia

Yes, I know. Apple under Steve wasn’t perfect. MobileMe happened. Antennagate happened. The hockey-puck mouse happened. Plenty of bad calls happened. Nobody is arguing for some flawless golden age that didn’t actually exist.

The argument is about standards, not perfection. Old Apple shipped mistakes too, and it visibly hated them. The bad release, the launch-day disaster, the public mea culpa, the engineering re-org. The whole company would visibly recoil and try to do better.

Today’s Apple ships friction and treats it like background radiation. That’s not the same thing.

The Counter Argument (-ish)

Yes, Apple Silicon is incredible. Yes, the Watch saved lives. Yes, the iPhone got better cameras and better screens and better batteries. The hardware story under Cook is strong, and pretending otherwise would be silly.

But here’s the thing about hardware. You can grow it through operational discipline. You can squeeze a process node, you can negotiate a better deal with TSMC, you can lean on a thousand suppliers until they bend. That’s exactly the kind of work Cook is good at, and it’s exactly the kind of work that doesn’t require a product person at the top.

Software is different. Software lives or dies on judgment calls a thousand times a day. Should this preference go in this menu or that one? Should this notification fire silently or with a sound? Should this Bluetooth handoff be aggressive or conservative? Those decisions can’t be operationally optimized. They have to be made by someone who actually uses the thing and has an opinion. Cook is famously not that person.

And the rot follows that exact line. Apple’s hardware reviews are still glowing. Apple’s software reviews… are not. The number of “I’m switching to Linux” or “I’m switching back to Windows” essays from longtime Apple loyalists has gone from a trickle to something that should worry someone on Apple Park’s executive row.

The grumbling isn’t about features. It’s about the texture of using the products. Which is the thing Steve cared about most, and Cook seemingly cares about least.

The Era of *aaS

There’s a related thread here. Cook’s Apple has gradually rebuilt itself as a services company that happens to make hardware. iCloud subscriptions. Apple Music. Apple TV+. Apple Arcade. Apple Fitness+. Apple News+. Apple One. AppleCare+ tiers within tiers. The recurring monthly nudges that show up in apps that used to be one-and-done.

There’s a real argument that this was a defensive move, and it worked. The Services line is now bigger than the GDP of small nations. But there’s also a reason long-time Apple users are uneasy. The company that ran the iPod silhouette ad is now the company that nudges you to try Apple Fitness+ when you open the Watch app for an unrelated reason. The texture changed. The thing that made Apple feel different is, slowly, less different.

And here’s where it loops back to the bug list. When recurring revenue becomes the thing the company optimizes for, the tolerance for friction goes up. A slightly annoying subscription upsell is acceptable as long as the funnel still works. A weird Settings menu is acceptable as long as nobody actually leaves. That’s how product standards quietly erode. Not through one dramatic bad decision, but through a thousand tolerated ones.

Was that the right business call? Maybe. Was it the right product call? Different question. And it’s the question Steve would have asked.

Enter John Ternus

The honest read on Cook’s tenure: he was the right operations CEO for the post-Steve transition, and he stayed long enough to also become the wrong product CEO for the post-iPhone era. That’s not a damning legacy. It’s just a long career with two halves that needed different people.

So who’s getting handed the keys? John Ternus.

If you needed to pick someone inside Apple to course-correct away from the operations-CEO failure mode, Ternus is the right person on paper. He’s been SVP of Hardware Engineering for years. He came up working on the Mac, ran iPad development, and was a key player in the Apple Silicon transition. He’s the one Apple keeps putting on the keynote stage to talk about new hardware. By any honest read, he’s an engineer and a product person, not a salesperson, not an operator. That’s the pick Steve would have nodded at.

BUT…

The piece I just spent a thousand words complaining about isn’t a hardware problem. Apple’s hardware under Cook has been excellent. The thing that rotted is the software experience. The bug list. And Ternus, for all his strengths, has spent his career running hardware, not software. Whether his product instincts translate into fixing the software stack is the open question of his tenure.

The hopeful read is that an engineer-CEO will demand engineering rigor across the whole company, including from the software org that’s been getting away with shipping half-baked work for a decade. The cynical read is that hardware engineers and software engineers are different cultures, and you can lead one without knowing how to fix the other.

I’m cautiously in the hopeful camp. The fact that Apple chose a builder over another finance type or another operations type says they noticed the thing this article is about. That’s not nothing.

But the proof is going to be in the next macOS release. Does System Settings get rebuilt? Does AirPods routing finally stabilize? Does Mail get a rewrite? Do notifications get a coherent strategy across all four operating systems? If yes, this was the right pick. If we get another year of shiny new features with five new bugs and zero fixes for the old ones, then Apple just rearranged the deck chairs.

Because that’s what made Apple. The rest is supply chain.

So yes. Tim Cook is leaving. Good. And John Ternus is taking the keys at exactly the moment Apple needs to remember what it was supposed to be.

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

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

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.