Learning to Observe
With the right background, an observer can find so much more value in their observations. But when the background of the observer is different than the intended audience, an observation can become a huge liability.
Design can’t be relegated to a single role. We all care. We all want to make a better product. Unfortunately, we all too often forget the most important member of the team: the customer.
Customers are occasionally involved at the start during some intial discovery research. From time to time they’re around during testing. Now and again they receive a survey after a new product or feature is launched.
This isn’t how I would describe a team member. This sounds more like a patient or guinea pig. And to top it off, an overwhelming majority of the decisions we make on their behalf don’t come from direct participation. They come from the narrative — our imagination — we build internally from the data they leave behind.
I get very uncomfortable when someone makes a design decision without coming into contact with the people actually experiencing the problem. Ideally, they should be coming into contact with them while experiencing the problem so they can see it and feel it first-hand.
Not everyone has the time, patience, energy, or ability to talk to customers like this. Which is totally cool. Not everyone needs to.
But… And this is a very big but…
If you’re aren’t in direct and regular contact with customers, you shouldn’t be making product design decisions.
I know that’s a hard line to draw. I don’t meet those requirements with everything I do — not even close. It’s an aspirational line in the sand and may not be realistic on a day-to-day basis. But it’s an important line. You should at least know when you’re crossing it and avoid veering on the wrong side of it as often as possible.
The more you hang out on the wrong side of that line, the more likely you are to succumb to dangerous biases. Your margins of error will increase. Others won’t be able to learn and build on your work. Toxic assumptions will weave their way into the product.
In short: If you can’t reliably trace the theory behind a design decision back to a situation that a customer is experiencing, you’re building a house of cards. So really, the customer shouldn’t just be a person your team consults from time to time. The customer should be an actual member of the team.
Yes, it is. Figuring out what the customer is actually going through, not what you think they’re going through is excessive, not to mention expensive. That level of awareness is probably too high a bar for any reasonable software company to achieve.
But for design to truly be a team sport, it has to happen. Everyone on the team needs to know what your gold standard is for making a design decision: Solving for the customer. And what’s often even harder to execute on is that everyone needs to know how to critically evaluate design decisions — how to accurately and consistently trace these decisions back to the gold standard. Or to discover that the chain of reasoning doesn’t lead there at all.
This requires lots of checks and balances on how your team operates. You obviously need to trust one another, but still ensure that there’s no sloppy or rushed thinking.
Letting a design decision hide behind a sloppy theory is how flawed thinking, introduced with the best of intentions, gets folded into the way a team permanently operates. Which is one of the most costly and morale-draining things that can happen to a team.
Many people I respect and admire occasionally forget to challenge what first comes to mind because it just feels right. Just because a thing feels right doesn’t mean it will meet the need of the customer. It takes effort and willpower and humility to share your thought process, to be transparent about what you’re basing your decisions on, and give everyone else in the room the data and tools they need to draw their own conclusions.
I forget to do this, too. A lot. If I counted up all the times I’ve failed to do this over the last few months, I would be too embarrassed to share.
But I keep fighting against that path of least resistance. I fight that son-of-a-bitch every single day.
Note to self: even when it frustrates me off in the short term, I’m grateful to anyone who asks me to prove an idea. I should thank people more for this… I know I don’t do it enough.
A team that fights this fight with me. One that reminds me that a theory is just a theory. One that expects more from me than a guess. One that expects a real-life story with a real-life customer to be at the heart of every idea. One that also wants the same thing in return.
A collection of independent choices supported and vetted by people with the same goal. Where imagination is respected, even admired, but never left unchecked.
As far as I can tell, that’s the only way to consistently make good design decisions. And it takes a whole team. And that team includes your customers.
Originally published on my Medium account as Design is a Team Sport.
With the right background, an observer can find so much more value in their observations. But when the background of the observer is different than the intended audience, an observation can become a huge liability.
In short, I’d like to get specific about the fundamental skills involved in product design, a few brief examples of the type of work that can be done for each skill, and how they’re mapped to common product design roles.