惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

V
Visual Studio Blog
爱范儿
爱范儿
GbyAI
GbyAI
博客园 - 叶小钗
Last Week in AI
Last Week in AI
Jina AI
Jina AI
Microsoft Security Blog
Microsoft Security Blog
云风的 BLOG
云风的 BLOG
C
Check Point Blog
H
Help Net Security
P
Proofpoint News Feed
酷 壳 – CoolShell
酷 壳 – CoolShell
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
大猫的无限游戏
大猫的无限游戏
H
Hackread – Cybersecurity News, Data Breaches, AI and More
B
Blog RSS Feed
Y
Y Combinator Blog
U
Unit 42
T
Tailwind CSS Blog
MyScale Blog
MyScale Blog
N
Netflix TechBlog - Medium
S
SegmentFault 最新的问题
J
Java Code Geeks
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知

Giant Robots Smashing Into Other Giant Robots

Client success starts before kickoff 5 easy, actionable tips for software development in healthcare Announcing importmap-update: automated dependency updates for importmap-rails When to vibe code an app and when to hire someone Why leaders have to know about PMS 🩸 Is AI ruining my brain? Tech Leaders Meetup is coming to Edinburgh Designers already think in React Tech Leaders Meetups are back in London this autumn GPT and Claude go to heraldry school Inserting State Transitions in Postgres Don’t hire thoughtbot to write code AI makes creating software faster, but in regulated industries, judgment matters more Tech Leaders meetup in Amsterdam PMs Don't Need to Code, but They Do Need to Understand How healthcare tech teams innovate while balancing speed and security Can’t touch the DOM? Reach for :has() to style any element Buying Time, Choosing Words: Consulting Through Diplomatic Communication thoughtbot around the world, meet us at upcoming events Modeling State Transitions in Postgres Humid 1.0: React server-side rendering in Rails can be easy! A prototype is not a product. It's a conversation. New: The State of Software Delivery in Healthcare Sign in with Google for React Native What founders told us about working with AI tools for startups Join us: Building Secure Healthcare Systems Upcase has retired, but the learning continues The Bike Shed Ep 506: The Muppet Software Team Migrating to native stack navigation, with a surprise from iOS 26 Past and present thoughtbotters at LRUG this Monday
Toast: the 2-minute test that reveals how you think about...
Bethan Ashley · 2026-06-10 · via Giant Robots Smashing Into Other Giant Robots

Stop.

Right now, stop reading and take 2 minutes.

Draw how to make toast.

That’s it.

No further instruction. No clarification. Just those words on repeat.

“Draw how to make toast.”

The moment you say it, something interesting happens.

Everyone stops. Instantly engaged.

Then the questions start.

“What do you mean?” “Can I use a pencil?” “Do you want steps?”

And that ambiguity is the point. You don’t answer any of it. You just repeat the instruction and watch what happens next.

People either lean in or freeze. And both reactions tell you something.

No two drawings are the same

Once people get going, the room completely diverges.

Some draw only the outcome. A slice of toast on a plate. Done.

Some turn it into logic. Step diagrams. Flow charts. Almost mathematical. X + Y = toast.

Some focus entirely on actions. Open cupboard. Take bread. Put in toaster. Press button.

Some go deeper into detail. Which cupboard? Which bread? Where does the knife come from? What happens if the toaster breaks?

Some include emotion. Smiling faces. Breakfast scenes. Warm kitchens. Morning light.

And then there are my personal favourites.

The “jam people”.

They always add something extra. Butter, jam, toppings. A bit of joy. A small delighter that wasn’t asked for but somehow feels essential.

You can often tell when they’ve drawn it. There’s usually a smile when they explain it back.

No two drawings are ever the same.

Collection of hand-drawn images from different people illustrating 'how to make toast' with images of bread, toasters, smiley faces and instructional arrows.

What you’re actually seeing

This isn’t a creativity test.

It’s a bias test.

And once you’ve run it enough times, patterns start to show.

The outcome-first people

They draw the end result and move on. They’re not overly concerned with the steps. In product work, these are often the people who want the Figma file and assume the rest will follow. They care about getting to “done”, sometimes at the expense of understanding how.

The systems thinkers

Often more technical profiles. They translate everything into structure and logic. They get precision, but sometimes miss the human layer.

The action-oriented people

They naturally think in steps and journeys. These are often strong product thinkers because they instinctively move towards user flow and behaviour.

The emotional thinkers

These people don’t just describe the process, they describe how it feels. This is where good UX often starts.

The deep detail thinkers

Architectural minds. They want completeness. Nothing is left unresolved. The challenge is they often never finish the full flow in a time-boxed exercise, because they’re building it properly from the start.

And then the jam people.

The ones who look for delight, not just function. They think about experience, not just output.

Every one of these is useful.

The problem is not the bias itself.

It’s when you don’t know you have it.

Why this matters in product

This is where it becomes more than an exercise.

In product teams, these biases show up everywhere.

In how you write user stories. In how you design flows. In what you consider “done”. In what gets prioritised on a roadmap.

And often, they clash.

One person thinks the job is complete when the system works. Another doesn’t think it’s complete until it feels right for the user.

Neither is wrong. But without awareness, teams talk past each other.

This is also why some teams struggle with things like job stories or user-centred framing. It’s not always a skill gap. Sometimes it’s just a different default lens on the world.

Good products come from teams that can see beyond their own bias.

The moment it lands

At some point in the exercise, something shifts.

People look at their own drawing and then at others’.

There’s usually a pause.

Then a quiet moment of recognition.

“Oh… I didn’t think about that.”

That’s the point where it becomes useful.

Not because the drawing was right or wrong, but because it reveals something that was previously invisible.

How you naturally think about problems.

Why I use this with teams

I care about this exercise because it makes something abstract very real.

Product work is full of hidden assumptions. About users. About priorities. About what matters.

Most teams don’t realise they’re not starting from the same place. They assume alignment that isn’t actually there.

This is a fast way of surfacing that.

And once you see it, you can’t unsee it.

What changes after this

The goal isn’t to change how people think.

It’s to make them aware of how they think.

Once that awareness is there, something shifts:

  • You write better user stories
  • You ask better questions
  • You spot gaps in thinking earlier
  • You stop assuming everyone shares your perspective.

It also makes cross-functional teams work better. Because suddenly, different perspectives are visible instead of hidden.

Final thought

Good product teams aren’t made of people who think the same way.

They’re made of people who understand how differently they think.

And sometimes, all it takes is a simple prompt:

Draw how to make toast.