How to give feedback on a design you know nothing about
I love to look at software products and give my analysis of the design decisions and strategies being made. Admittedly I have almost no insight into how it’s made, but I like to try and reverse engineer what I see, or think about what could’ve been designed.
Where this thinking runs into trouble is product designers criticize openly with few facts, sometimes going as far as to post product redesigns in their portfolio, or make their way into people’s inboxes with unsolicited suggestions about how to improve a product. I think this can do more harm than good to any designer, because there is such a high risk of looking naive because of not knowing the backstory.
We see this in job interviewing as well, where hiring managers ask us to redesign one of their surfaces (or a competitor’s) without much context. Ethical issues about interviewing this way aside, it perpetuates a notion that product design and development decisions are easily analyzed without context, and just as easily re-envisioned.
I want to be clear that we’re talking about product designers analyzing shipped work. This isn’t about users coming in with feedback, or making suggestions. That is an entirely different type of feedback and honestly, it’s more valuable coming from them because it’s closest to the problems of products that have been shipped. This is about how we armchair quarterback product design, when we do not know what might be valuable to the business or people closest to the product.
Here’s some things we’re probably not going to know when we look at shipped products: We don’t know the internal stakeholders who influence the work. We don’t know the business goals, or goals set for the people who use the product. We don’t know the tech stack. We don’t know the people who will use the shipped product, or their motivations to employ it.
If we were consulting for a client, or contracted to design something for a client we’d be foolish not to understand (or define) the backstory at the outset of the work. So why are we doing this out in the world as we look at things? I think it’s because we’re surrounded by surfaces all day long, and we start to believe that that’s all there is. This is a really toxic part of design thinking these days.
To me this dynamic also illustrates a streak of arrogance in design thinking that comes from a long legacy of “genius” designers who have polluted our thinking by being celebrated for shooting from the hip, and ramming ideas through because they “have done this before”. Worse than this, is the arrogance can stem from what Jared Spool calls “unconscious incompetence” where product designers are unaware of the need to discover business value, create value for customers, and how bloody hard it can be to achieve product-market fit.
Here’s a fact: we don’t always have the facts, so why fake it? Even if we have tremendous past experience, our past experience speaks only to how we thought about things and made decisions in the past. Further, industry experience with a competitor is valuable, but new companies bring entirely new environmental dynamics that take time to fully grasp. Even if we have neither of these virtues, humility is a great character trait. Ask more questions rather than put forth naive suggestions. Being humble and cautious is a winning strategy for engaging assumptions about a product, while maintaining curiosity and an open mind.
Here’s some feedback to any designer or product person reading this: When it comes to suggesting product ideas or strategies, take a step back and think about what actually goes into a product, and how complex it is. Then ask…
What is the composition of the team working on this?
Who are the stakeholders they review the work with?
What problems is this team working to solve?
What is the purpose of the team working on these problems?
What are the goals or outcomes this team seeks to produce?
What kind of processes does this team employ to make decisions and ship work?
What is the tech stack being used?
When we can’t answer these questions, our analysis will probably be flawed, full of assumptions we can’t validate. That is perfectly ok if we fess up to it, instead of communicating our analysis with a confidence that suggests it’s fact.
Coming in hot with product suggestions puts you at risk of sounding naive. Chances are the company or team in question has already thought about, complained about, or made really hard decisions about technology and engaged ideas you’re going to suggest. Or worse, they’ll know they are simply not on the roadmap, or not feasible at this moment in time. So it goes.
Being kind, thinking about who is behind the product, and assuming competence and best intentions is a different method for engaging product decisions we observe, because it’s about maturity of thinking.
