You take over a project on Monday because your colleague will be away for two weeks.
They are responsible and experienced, so you expect the transition to be easy. The project folder is full. There are spreadsheets, proposals, meeting notes, presentations, screenshots, and email exports. Nothing important appears to be missing.
Then you start opening the files.
There is Proposal_Final.docx.
Then Proposal_Final2.docx.
Then Proposal_Final_Revised.docx.
And finally, Proposal_Final_Revised_FINAL.docx.
The spreadsheet has six tabs. Two contain different versions of the same figures. The meeting notes mention that the client chose one of the options, but they do not say which one. A presentation contains a number that does not match the spreadsheet, and you cannot tell whether that difference is deliberate or a mistake.
Everything seems to be there.
You still cannot move.
The work may have been complete for the person who created it. It is not yet usable for the person who received it.
Correct work can still create work for somebody else
Most of us judge our work first from the producer’s side.
Are the numbers correct? Did I complete every required section? Did I follow the instructions? Did I include all the necessary information? Did I finish on time?
Those questions matter. Accuracy matters. Completeness matters. Standards matter.
But another person eventually encounters the work from the other side.
They are not asking whether you worked hard on the spreadsheet. They need to find the number that matters.
They do not know how many drafts the proposal went through. They need to know which one they can send.
They do not know how carefully you documented every meeting. They need to understand which decision survived those meetings.
Technically correct work can therefore remain strangely expensive.
The cost has simply moved downstream.
The receiver spends time searching, interpreting, comparing, asking, reconstructing, and sometimes repeating thinking that somebody already did.
That is why usability belongs inside the definition of good work.
What is obvious in your head is not automatically visible in your work
Most unusable work is not created by careless people.
It is often created by people who know the work extremely well.
You have been inside the project for three weeks. You know why the second tab exists. You remember which figure is preliminary. You know why the team rejected Option A. You remember the conversation in which the customer changed the requirement.
You do not experience these things as missing information.
You simply know them.
That familiarity creates a blind spot.
When you look at the document, you see the document plus everything in your memory.
The next person sees only the document.
This is one reason work can look perfectly clear to its creator and confusing to almost everyone else. The creator unconsciously supplies the missing context while reading it.
The receiver cannot.
What is obvious in your head is not automatically visible in your work.
A good handoff cannot rescue unusable work
This is different from Make the Handoff Part of the Work.
A handoff is about transferring responsibility clearly. You make sure the next person knows what is finished, what remains open, what they own, and what matters enough to protect.
You can do that beautifully and still give them terrible work.
Imagine telling a colleague:
“This presentation is final. You own the client meeting tomorrow. The client cares most about the implementation date, and there is one open question about staffing.”
That is a clear handoff.
Then your colleague opens the presentation and finds seventy slides, three different implementation dates, no visible recommendation, and an unexplained staffing table.
Responsibility crossed cleanly.
The artifact did not.
The next question is therefore not merely, Did I explain the handoff?
It is:
Can another person actually use what I made?
Look for the hidden labor you push downstream
A useful way to inspect your work is to look for three kinds of unnecessary labor: search, guesswork, and reconstruction.
These appear in almost every kind of knowledge work.
Search
What does the receiver need first, and how hard do they have to look for it?
A manager opens a ten-page report because she needs to know which problem requires a decision today. The answer is on page eight.
A customer receives a long email because he needs to know whether his request was approved. The answer appears in the final paragraph.
A new employee opens a shared folder because she needs the current template. Twelve templates are stored there, and several have the word “final” in the filename.
Nothing is technically absent.
The receiver still has to work to find what matters.
Sometimes the best improvement is not adding information. It is moving the important information closer to where the person needs it.
Guesswork
What does the receiver have to infer that you already know?
Which version is current?
Is this number final?
Does “pending” mean waiting for approval or waiting for customer information?
Is the recommendation yours, or was it already approved by management?
Should they respond now or wait?
Every workplace contains abbreviations, habits, file structures, and unwritten assumptions that experienced people stop noticing. Some are harmless. Others make people guess about things that should not require guessing.
If you already know the answer and the receiver reasonably needs it to act, make it visible.
Reconstruction
What context will the next person have to recreate from scattered pieces?
Perhaps the client rejected one option during a meeting, but the decision never made it into the project note. Perhaps the spreadsheet contains the final number but not the assumption that produced it. Perhaps an employee taking over an account needs to read thirty emails to understand why the current agreement looks the way it does.
Some context genuinely belongs in history.
But if another person must repeat hours of reasoning merely to reach the point you already reached, part of the work has been done twice.
A usable output preserves enough of the useful reasoning that the next person can begin farther forward.
Do not document everything
Once people see this problem, the instinct is often to add more.
More notes.
More instructions.
More fields.
More explanation.
More documentation.
That can make the work even harder to use.
A spreadsheet with twelve explanatory tabs may be worse than one with three clear ones. A procedure with every possible exception embedded in the main flow may become impossible to follow. A forty-page briefing document may contain all the context while hiding the three things a new project owner actually needs.
Usability is not the amount of information you provide.
It is the relationship between the information and the job the receiver is trying to do.
Sometimes you need to explain more.
Sometimes you need to remove half of what is there.
This is where Name the Person Your Work Must Help becomes practical again. Once you can see the person and the moment in which they will use the work, you have a reason to decide what deserves prominence and what can remain in the background.
The receiver does not need everything you know.
They need what helps them use the work intelligently.
Do not remove necessary complexity
Some work is difficult because the subject itself is difficult.
A financial model may require financial knowledge. A technical drawing may require engineering expertise. A legal agreement may contain language that cannot responsibly be reduced to five friendly bullets. A medical procedure should not be simplified past the point of safety.
The goal is not to make every piece of professional work immediately understandable to anyone who opens it.
Do not remove necessary complexity. Remove unnecessary friction.
There is a difference between struggling because the decision requires judgment and struggling because nobody labeled the spreadsheet.
There is a difference between needing expertise to interpret financial risk and needing expertise to discover which file is current.
There is a difference between a process being genuinely complex and a process being poorly presented.
Good work respects the complexity that belongs.
It removes the difficulty that does not.
Expertise should solve difficult problems, not preserve avoidable mysteries
There can be a strange reward for creating work that only you understand.
People keep coming back.
“Ask Carlo. He knows where everything is.”
“Wait until Maria returns. She’s the only one who understands that spreadsheet.”
“Don’t change anything until Ben explains the process.”
Being needed can feel like proof that your expertise matters.
Sometimes it is.
There are judgments that require experience. There are difficult situations where the expert should be involved. There are things you cannot capture completely in a template, note, or process.
But consider what people keep asking you.
If they need your judgment on a difficult exception, that may be expertise.
If they need you to tell them which file is final every Tuesday, that is not expertise.
If they need your thinking about an unusual client situation, that may be expertise.
If they need you to explain what the column headings mean because you invented a private shorthand nobody else understands, that is friction.
A valuable professional does not need to manufacture dependence.
Expertise should solve difficult problems, not preserve avoidable mysteries.
Review the work from the other side
Before calling an important output finished, stop looking at it as its creator.
Picture the next person opening it without your memory.
Where will they search?
What will they have to guess?
What will they need to reconstruct?
You do not need to eliminate every question. Good work still creates conversation, especially when judgment matters.
But remove the questions that exist only because something useful stayed trapped in your head.
Maybe the recommendation belongs on page one.
Maybe the current file should be clearly marked and the obsolete versions archived.
Maybe one assumption needs to appear beside the number it affects.
Maybe the instruction needs an example instead of another paragraph.
Maybe the dashboard needs one fewer measure.
Maybe the email should begin with the decision instead of the history.
Small changes can remove large amounts of downstream effort.
Useful work can stand without you
There is a larger test beneath all of this.
What happens when you are not available?
Can the report still be used?
Can the customer still be served?
Can another person understand the work well enough to make the next reasonable decision?
Can someone improve what you created without requiring you to explain its basic logic again?
This does not mean your contribution has become unimportant.
It means your contribution has acquired range.
The work can travel farther than your personal presence.
That is especially important in Make Your Work Matter. Contribution should not be measured only by how much effort you personally continue supplying. Sometimes the stronger contribution is the piece of work that lets another person continue with less dependence on you.
A useful output carries some of your thinking forward.
Not all of it.
Enough.
Ask one final question
Before you send the spreadsheet, publish the guide, submit the report, close the folder, or hand over the presentation, look at it once from the receiving side.
Then ask:
What difficulty remains because this work is genuinely difficult—and what difficulty remains only because of how I prepared it?
Do not remove the first kind just to make the work look simple.
Remove as much of the second as you reasonably can.
Because completing the work is not the same as making it usable.
And the next person should not have to borrow your memory simply to benefit from what you already did.
Your work becomes more valuable when another person can use what you made without borrowing your memory.
Once you begin removing unnecessary effort from a single report, file, instruction, or tool, another question becomes visible: what recurring friction could be removed from the system itself?
Continue with Leave the System Easier to Use Than You Found It.