Users do things
differently
under different circumstances,
where UX’s ideal states might fail.
Visualize and learn about non-ideal states
where your experience might break.
under different circumstances,
where UX’s ideal states might fail.
Visualize and learn about non-ideal states
where your experience might break.
I often use this triangle to get stakeholders on the same page.
Everyone wants the best work, at the lowest cost, and delivered yesterday.
In reality, you can rarely optimise for all three at the same time.
The useful conversation is not “Can we do everything?” but “Which corner are we willing to compromise on?”
I picked up this distinction from an AWS tech leader, and it changed how I work with engineers.
Designers generally welcome change — we explore, iterate, challenge assumptions and keep looking for something better.
Engineers often have a different relationship with change. They have to think about existing systems, dependencies, stability and what might break.
Understanding this helped me present new ideas as evolution of the system, rather than disruption to it.
I learnt the value of self-service at Tropogo and later saw it play out again at Amazon AWS.
If users can solve small problems themselves, the core product and engineering teams don’t have to become the support team for everything.
Simple tools, controls and configuration can take a surprising amount of operational work off the team.
Done well, self-service isn’t just a UX improvement — it can become a soft-cost saving mechanism.
I don’t think accessibility needs to look the same for every product.
For an early-stage or fast-moving product, a bolt-on approach can make sense — address the most important accessibility gaps once the product has some shape.
As the product matures, accessibility can become built in through the design system, so every new feature benefits automatically.
And for products where accessibility is fundamental from day one, it should be born in — considered across the entire system from the start.
We usually design the happy path, followed by a few obvious error states.
But the real world has too many variables for the product to always stay on that path.
One small change in user behaviour, operations, data or the environment can send a workflow somewhere we never planned for.
I’ve learnt to spend more time asking “What else could go wrong here?” before the product goes live.
Especially in operations-heavy products, I’ve found a simple hierarchy of research: do it yourself, watch someone do it, then ask them about it.
Doing the task gives you context that is almost impossible to get from a meeting room.
Watching users execute certain task can also be beneficial — but once isn’t enough. Repetition reveals things that the first observation doesn’t.
Every time I shadow the same workflow, I usually notice something I missed the previous time.
I’ve worked with a lot of design thinking frameworks over the years, and each has its place.
But in fast-paced environments, JTBD has become my most useful weapon.
The more complicated the product gets, the easier it is to lose sight of what the user actually came here to do.
JTBD gives me a simple filter: What is the person actually trying to accomplish? Once you have that answer, it get much easier to drive the conversation forward from there
Documentation is probably one of the most underrated tools in a designer’s belt.
A decision that exists only in someone’s head will eventually disappear.
Writing things down forces me to clarify what we decided, why we decided it and what we still don’t know.
And six months later, it saves the team from having the exact same conversation all over again.