On Both Sides of the Same Mistake
At work, we’re implementing a new curriculum, and it fell on my team to create the inventory system for all the materials. As part of that, I designed labels for the bins. Along the way, I made a mistake: for one grade, we labeled the physical bins “All Units,” but in the electronic system, we referred to the same materials as “Bin 1 of 2” and “Bin 2 of 2.” The mismatch was actually the result of a previous change meant to add clarity. But when a team member went to deliver the bins to classrooms, they had no way to translate one label into the other. I knew exactly what it was supposed to be, but because I couldn’t explain the discrepancy in the moment, I had to go to the school myself, sort out the bins, and move all 15 of them myself.
The same dynamic surfaced when trying to order supplies. A colleague sent me a spreadsheet of the supply order that was 100% clear to her. The problem was that the spreadsheet used common names for the materials, which didn’t always match the name on the vendor’s website. Think: “Pencil pack refill” and “Pencils” in the spreadsheet versus “#2 Pencils, 24 Count” on the website. The instruction was mostly clear, but the small amount of uncertainty caused several days of delay while we sorted out the issue.
I even saw this at home. While checking the summer camp spreadsheet my wife created to make sure I had the pickup times and locations correct, I noticed that this week’s plan was for baseball camp, which had to be just for my son. I asked, “Does Zola not have a camp next week?” Erin replied, “There are two tabs, one per kid.”
I had been looking at that spreadsheet for four years and never even thought to look for a second tab, believing that the kids always went to the same place each week. It was completely obvious once I knew what to look for. But until then, my wife and I were looking at the exact same thing and seeing something different. (Luckily, it hadn’t previously led to a stranded kid!)
Three versions of the same issue, and I was on both sides of it.
When I was a product manager, this issue came up frequently. We’d design something, accidentally assuming that “everyone knows” that, say, the sandwich icon on a mobile screen signifies a menu. But you don’t have to sit through many customer testing sessions to realize that “everyone knows” is a wild assumption on just about everything. Because we were so steeped in the design language and, critically, because we were the people designing the object, we could easily lose sight of what’s obvious and what requires explanation.
In that situation, the worst thing we could do is blame the customer for not understanding. They must not be listening or reading closely enough. Or more judgmental: They’re not smart enough to get it.
No—great designers know that if something isn’t clear, it’s on the designer, not the audience.
The same is true any time one person creates or says something and depends on someone else to receive it correctly—a business explaining itself to a customer, a speaker to an audience, a manager making a request to his employee, one spouse to another.
It’s usually not that the other person isn’t reading closely enough. I was looking hard enough at my wife's spreadsheet to know something was off — I just didn't know to look for a second tab.
It’s usually not that they aren’t listening closely enough. For example, as a colleague and I sorted through a miscommunication last week, she told me, “I heard what you said. I just thought it meant something else.”
And it’s rarely a matter of intelligence. The smartest driver in the world can still misread the road signs in unfamiliar territory.
Instead, it’s about taking ownership of clarity, even after we think we’ve already done the work to provide it. And it’s about not judging the person on the other side of the communication, since we’re likely to be that person in another situation.
Having been on both sides three times this week, I know.