What Leaders/Managers Can Learn from The Design of Everyday Things
Marcus rolled out a new expense-approval workflow to his department of forty people, confident the steps were logical because he'd mapped them himself on a whiteboard. Within weeks, half the team was submitting expenses the old way, emailing screenshots instead of using the new system. Marcus assumed his team was simply resistant to change and sent a stern reminder about "following process." Then he sat beside a team member trying to submit a report and watched her stare at a screen with three unlabeled buttons, none of which said "submit." She'd guessed wrong twice before, been rejected without explanation, and quietly gone back to email rather than risk a third failed attempt. Marcus had built a workflow that made perfect sense to the person who designed it and no sense to anyone encountering it cold, and the cost showed up as a management problem instead of the design problem it actually was.
The whole book, compressed
This edition works through 4 core lessons — take them one at a time, not all at once.
What's different for your conditions
Tap whichever ones sound like you. Nothing here is sent or saved — it's just for your own noticing.
0 of 5 selected
The core lessons, applied to you
Making the possible visible at a glance
A workflow, dashboard, or org process should show people what steps exist and what state they're in without requiring a separate explainer document. If someone has to ask a colleague "wait, how does this work," the process itself has already failed as a piece of design.
A performance-review tool has five hidden tabs behind a single icon, so most managers only ever complete the one tab they stumbled onto first.
Ask three people on your team to walk you through a process you designed, without coaching them, and note every place they hesitate or guess.
Giving feedback the instant someone acts
When an employee submits a request, flags a risk, or completes a task, they need a clear and immediate signal about what happened next. Without it, people either chase managers for status updates or quietly assume nothing is being done.
A team submits ideas through a suggestion form that gives no confirmation and no follow-up, so within a quarter almost nobody bothers submitting anything at all.
For your team's most-used process, add one visible confirmation step, even something as small as an automatic acknowledgment message, and watch whether follow-up questions drop.
Matching your process to how people already work
New systems succeed faster when they borrow the shape of habits people already have, rather than inventing an entirely new mental model for the same familiar task. A request that looks and feels like the last one a person filed will be trusted more than one built on unfamiliar logic.
A leader introduces a project-tracking tool with its own unique terminology for status labels, and the team keeps translating it back into their old vocabulary in every meeting.
Before launching a new process, list the terms and steps of the old one, and keep every part that isn't actually broken.
Treating repeated mistakes as a signal about the system, not the person
When the same error keeps surfacing across different employees on a team, the honest read is rarely that the team is careless; it is that the process itself sets people up to fail in a predictable, repeatable way. Leaders who redesign the workflow when this happens build teams that trust the system, while leaders who blame the individual each time keep absorbing the same error indefinitely, one person after another.
Visibility and feedback can pull in opposite directions: showing every possible option keeps a process transparent, but adding a confirmation step for every single micro-action can slow a team down and feel like noise. The balance is to make status visible passively, at a glance, and reserve active feedback for the moments that actually carry risk.
Name one thing, honestly
Which recurring mistake on your team have you been quietly attributing to carelessness rather than to how the process itself is built?
Good. Now look back at the "Try this" line under whichever lesson feels most connected to what you just wrote, and treat that as this week's actual assignment — not all 4 at once.
The practices from this edition
0 of 3 selected
Run this for seven days
Before launching a new process, list the terms and steps of the old one, and keep every part that isn't actually broken.