✤ Further reading:

Designing For Different States in The UI, by Shane Doyle
www.shanedoyle.io/post/designi...

The Nine States of Design, by Vincent Speelman
medium.com/swlh/the-nin...

All The User-Facing States, by Eric Bailey
ericwbailey.website/published/al...

✤ Recommended books:

– Design For Real Life, by Sara Wachter-Boettcher, Eric Meyer
– The End of Average, by Todd Rose
– Think Like a UX Researcher, by David Travis, Phil Hodgson
– Mismatch: How Inclusion Shapes Design, by Kat Holmes

Personally, I often start exploring errors and recovery flows early because they often leave users frustrated and disappointed. Looking into "broken" state helps you also figure out how you communicate to your users, your tone and voice, and hence the messaging.

Personally, I often start exploring errors and recovery flows early because they often leave users frustrated and disappointed. Looking into "broken" state helps you also figure out how you communicate to your users, your tone and voice, and hence the messaging.

Or optimistic actions where we assume access by default and hence reduce the perceived speed of uploading data. If it goes unexpectedly wrong, we flag an error and ask users for their input.

We need to avoid an entire page takeover, but rather lazy load content panes or use inline loading. Finally, we can improve the blank states by using skeleton screens where we show the structure and layout of the page early.

Our job here is to prevent people from getting discourage and giving up on our product. In the loading state, when users are waiting for an update to come through, we must avoid frustrating rage taps/clicks and allow users to set filters by being mindful on how we manage data fetching.

We start with the ideal state. It’s the zenith of your product's potential. We then explore the error state, when things go wrong, with unexpected problems, error messages and input validation UX. From there on, we move to the partial state — when the page is sparsely populated.

✤ Useful resources:

Practical Guide To Content Testing, by Intuit
lnkd.in/ewZSVT3i

Testing Content With Users, by Kate Moran
lnkd.in/eVzyQmvD

Five Fun Ways To Test Words, by John Saito
lnkd.in/eJ6uk-U2

Highlighting: Simple Way To Evaluate Content, by Peter Gale
lnkd.in/eRt4mDQz

#ux #content

And: a great technique I use to test how well a design matches mental models is the 🍌 Banana test. Replace all key actions with “Banana”, then ask users to explain what each action might mean.

It will tell you if your key actions are in the right place, if your icons and interactive elements work.

How to choose the right way to test?

💭 Do users understand? ← interview, comprehension tests, Cloze test
💭 Do we match the mental model? ← Banana test, Cloze test
💭 What word works best? ← card sorting, A/B test, tree testing
💭 Why doesn’t it work? ← interviews, highlighting, walkthroughs

Too often, users would say that a page is clear and well-organized, but when asked specific questions, you notice that their understanding is vastly different from ours.

Such insights rarely surface in unmoderated sessions — it’s much more effective to observe behavior in-person or remote.

With content testing, our goal is to learn how users actually perceive the content that we present to them. It’s not only about being confused, or not finding the right answer on a page, but also if our content clearly articulates what we actually want to communicate.

✅ First, write up a plan with goals, customers, questions.
✅ Bring questions and wait silently — avoid speak-aloud.
✅ Ask users to highlight helpful and confusing words.
✅ Ask users to explain a product, flow, concepts to you.
🚫 Don’t ask people what they like, prefer, feel or think.

🍌 Banana test ← replace key actions with Banana, ask to explain
🕳️ Cloze test ← remove words, ask users to fill in
🤔 Reaction cards ← write emotions on cards, ask to choose
🖍️ Highlighting ← ask users to highlight helpful/confusing words
🥊 Competitive testing ← ask users to explain competitor pages