Bad things happen as we stop solving people problems and start solving business problems
Ask a designer who the most important stakeholder in their design process is and they will dutifully answer “the user.” It’s been drilled into us that our job is to represent the people who will use our products. We “empathize” with them and put their needs in the center of our decision-making process.
On paper, this sounds great, and many organizations wear the badge of human-centered design with pride. But when you take a step back and start to consider all the negative consequences that are created by these very same organizations, it becomes clear that something is amiss.
How could a process predicated on empathizing with people result in things like rampant data manipulation and exploitation, addictive features that hijack human psychology, systemic abuse, disenfranchisement, and predatory dark patterns? The answer is that it can’t. This can only mean one thing: We aren’t actually practicing human-centered design. And, unfortunately, the more established your company, the truer this statement is. As companies scale up, as they all strive to do, their priorities and incentives become less and less aligned with the people using their products.
The dehumanization of design
Taking an idea from concept to business means moving through a series of gates. In the Silicon Valley model the gates look something like this:
- Develop an initial product concept and launch a Minimum Viable Product (MVP).
- Iterate on MVP to reach product/market fit.
- Scale up.
- Cash out.
Driven by venture capital money, the goal is to cross these gates as quickly as possible. They’ve even coined a phrase for it: “blitzscaling.”
The problem is that as a company moves through each gate, the organization and its underlying incentives fall farther out of alignment with the needs of the people using the product and align more and more with the needs of the business. While an org may preach human-centered design, this growing imbalance of incentives and priorities runs counter to the tenets of that practice and makes it increasingly difficult to maintain them. Here is my generalized representation of how that looks:
Let’s walk through each phase to get a sense for what this means. We are going to use the example of a ride-sharing app to illustrate the point.
1. Initial concept development/MVP
If human-centered design exists in any phase, this is it. We discover a real problem that people are having in the real world and we set out to solve it.
Maybe you notice that it’s not easy to get a ride home from college if you don’t have a car, and you want to solve that problem. At this stage your design challenge might be something like:
How can we make it easier for people to get a ride without needing their own car?
This is a people problem. Addressing this problem means understanding the larger human context behind it and then developing a solution that delivers real-world value. That is human-centered design.
In this case, you decide to create an app that allows people to share rides. You design, test, and prototype with potential customers, build your MVP, and launch it into the world.
This step of the process is as customer-focused as you will likely ever be. Your vision is clear and competing priorities are incredibly limited. All you want is for your solution to solve a real human problem. Ironically, this is also the moment where human-centered design begins to die.
2. Reach product/market fit
As soon as your MVP is live, the incentives underlying the design process change dramatically. Provided your solution isn’t completely off base (in which case you basically move back to phase one) the next step for your app is to improve the experience and iterate on the feature set.
This shifts your focus away from the external human context of the problem and narrows it to the internal product context. You aren’t solving real-world problems anymore; you are solving product-based problems that you created with the way you designed your solution. In our ride-sharing app example, a problem in this phase might be something like:
How do we make it easier for riders to rate drivers?
This is a product problem. It didn’t exist until you created it. Yes, it is affecting people and addressing it means you need to understand the behavior of those people, but only within the context of your product. This may feel like a subtle difference from the MVP phase, but it is a critical distinction. This is a key first step in dehumanizing the design process. First, it represents a narrowing of our view of who the people we are designing for are. We begin to form a bubble where “understanding the user” means understanding their interaction with the product, not understanding the context of their life. This is the step where “humans” become “users,” and the way they interact with the business becomes how they are defined.
Second, this is where we start to introduce numbers, in the form of engagement metrics, as a proxy for people, creating a new layer of separation between us and them. For example, in the case of the driver rating problem above, our key indicator of success will not be based on individualized feedback, but rather on whether or not the overall percentage of riders who rate their driver goes up. This kind of measurement is unavoidable, but we rarely acknowledge its dehumanizing effect. Users become an amorphous blob masked behind our business metrics.
While this kind of product problem is still largely focused on user issues, the business-centric context shift alters our definition of what’s important and primes us to focus more on business needs.
3. Scale up
Once a product has traction, the question becomes “How do we grow?” This introduces a new focus: maximizing key growth metrics. In the case of our ride-sharing app a problem in this phase might be:
How do we increase the number of rides people take?
This is a business problem. No human is walking around saying, “Man, I wish I had to use my ride-sharing app more often!” This type of problem is the antithesis of a human-centered problem.
In order to increase rides, you either need to squeeze more value out of existing customers, convince new people to start taking rides, or both. While some of this is about driving awareness, much of it centers on convincing people that they have a problem, or in the worst case, actively creating new problems. This is no longer about uncovering an unmet need and developing a solution.
It is this step where things can really start to turn and those negative externalities emerge. This is the realm of addictive product loops, invasive notifications, email drip campaigns, dark pattern tricks, data manipulation, and whatever else we characterize as growth hacking these days. It’s countdown timers in checkout flows, 0% down offers, Prime Day, and planned obsolescence. A lot of the advertising world makes its hay here as well.
When teams are incentivized solely around moving metrics all manner of unsavory things become fair game.
Solving these problems means you are designing to extract value, not to deliver it. To “understand the user” in this context means understanding how to change or manipulate their behavior in order to move a metric. When teams are incentivized solely around moving metrics, all manner of unsavory things become fair game. This is where your ride-sharing app might develop something like Greyball.
4. Cash out
This is the last gate. You now have a successful product operating at scale. Your new problem — and the core focus of the organization — becomes:
How do we maximize our market value?
This is a market problem. The goal is to position the company in the best light possible for IPO or acquisition, or some other liquidity event. This is the final step in dehumanizing the design process. You are now designing for the investor.
The most likely outcome for the people using your product is not some new solution to a real problem they have, but a doubling down on the extractive tactics you employed while scaling. Make no mistake: Growth hacking is not some short-term stop-gap; it’s like a drug. Once you get hooked there is no turning back. You’ve created a beast that must be fed, and good luck getting off that treadmill. So for many, this becomes the new normal, and negative externalities become the cost of doing business.
It doesn’t stop once you cash out, either. If you go IPO, for example, you are legally obligated to prioritize increasing investor value for as long as you are in the public market. If you get acquired, it’s likely to be by some other publicly-traded company under the same requirements. The idea that you could swing back to focusing on the needs of your customer at this point is foolishly idealistic.
The principles of human-centered design evolved over decades, but it really took hold in the 1990s, when it was popularized by IDEO and other design consultancies. Human-centered design is the perfect tool for a consultancy like IDEO, which takes on the task of uncovering new problems and proposing new solutions. It’s also why this mode of design works so well in the first phase of product development. But consultancies rarely build and scale things; in fact, they almost never leave the first gate. Building and scaling is up to the client. That’s not a bad thing, it’s just the way the relationship works.
But what this means is that human-centered design is not something you can just drop into any organization and expect it to improve outcomes for customers. For a lot of companies with existing products, the concept doesn’t fundamentally align with the incentives of the org. It’s also why it becomes increasingly difficult for teams who employed human-centered design principles early in the life of a company to effectively maintain the practice long-term. The growing misalignment of incentives creates major headwinds to selling through and leveraging the resulting insights. There are too many competing priorities, and the context through which the company views “the user” fundamentally changes. This is where things break down and bad things can happen.
Negative externalities emerge as “human-centered” technology platforms grow because the reality is that their focus shifts deeper and deeper into business-centric thinking. The bubble that begins to form when we move from creating an MVP to focusing on “product problems” only gets bigger over time, and teams become increasingly disconnected from the real world. It’s a slippery slope where the problems of the business overtake the problems of the humans the business serves, and it warps our perspective.
Delivering real human value isn’t a benchmark for business success. Instead, success is defined by speed, scale, and growth.
This is an incentives issue deeply rooted in our culture of technology. Delivering real human value isn’t a benchmark for business success. Instead, success is defined by speed, scale, and growth. When an entire business is incentivized to scale at all costs, it takes a lot of effort and intention to separate yourself from that context. It’s unnervingly easy to be swept along not realizing how far things have drifted from your original goals. When we do talk to customers, it’s shaded by this context. Our research goals are driven by the needs of the business. We ask the questions that will get us the answers to complete our current task.
The first step to solving all this is awareness and being willing to have honest conversations with ourselves. If we hide our heads in the sand and insist that everything we do is human-centered, we are less likely to question our choices and the choices of those around us. But awareness is just the first step.
If we ever want to truly align the kind of design we say we do with the kind of design we actually do, we need to be willing to question our cultural definition of success. Reaching for scale and endless growth drives us to do unnatural things as we lose sight of the human value we were trying to deliver. As the negative impacts of our technology choices continue to grow, it’s time to consider that speed, scale, and growth are flimsy proxies for success.