Skip to content

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:

1. Develop an initial product concept and launch a Minimum Viable Product (MVP).
2. Iterate on MVP to reach product/market fit.
3. Scale up.
4. 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.

—

“Human-Centered Design Dies at Launch” was originally published in Medium on July 31, 2019.

The process of user-centered design focuses a lot of attention on finding the right problem. There are many tools and processes that can be used to suss out user needs and motivations and boil it all down into clearly defined problems to be solved. But with all these tools at our disposal, how can we still end up with less than optimal and often negative outcomes for the people we are supposed to be helping?

The issue is that our obsession with solving the correct problem frequently takes our focus away from an even more important aspect of the project. While we can’t move forward without a defined problem, the way we define success for a project actually carries more weight in the final outcome than problem statements or initial insights from user research.

Raise your hand if this has happened to you: You see an interesting headline, maybe something like, “The 10 Best Vacation Spots in Mexico.” You click the link with the hope of reading through a concise list of locations to help you get some inspiration for your next trip. But that’s not what you get. Instead, you get a page so crowded with ads it’s hard to tell where the article starts and the ads end. On top of that, you don’t even get a list of places. Instead, you get one of the list items (usually the bottom of the list) and you have to click “next” to cycle through the remaining nine items. Each time you click, the page reloads and you have to wade through a new set of ads to see the next item in the list.

This all-too-common experience is not driven by a designer who identified the wrong problem or didn’t have enough insights; it’s driven by a business-centric definition of success.

—

Typically, sites that post articles like “The 10 best vacation spots in [insert exotic location]” survive on advertising money. Each time a page on that site loads, it shows a set of ads. This is called an “impression.” The more impressions a site can generate, the more revenue it collects from the ads. For this kind of business, a key metric is often page views (i.e., how many times the individual pages on a site are loaded in a given timeframe). Every new page view means more ad impressions, which means more revenue. In the eyes of the business, the more page views the site can generate, the better.

This sort of definition of success will shade every part of the decision-making process and can push people to do things that run counter to what we would expect from a user-centered design process.

If a designer creates an article layout that shows all 10 of the Mexican vacation spots in one list on a single page, it would be easy for the reader, but it will only generate a single page view. If instead, the designer creates a layout where the user has to click “next” to see each item in the list, and each click results in a new page being loaded, then someone reading that article generates 10 page views (assuming they click to see all 10 items).

With this change, the designer has now multiplied the performance of their design. For the user the resulting experience is shit, but for the company’s definition of success, the experience is excellent.

Increasing page views (or even “increasing revenue”) focuses solely on the outcomes and needs of the business. This kind of goal is a signal from the company that they don’t care what solution a team comes up with, as long as it moves the numbers. But forcing someone to load 10 pages in order to see all the items in a list is just one way to meet this measure of success. Another way to do it is to write better, more interesting articles with layouts that are more user-friendly and readable so that more people are willing to read and share.

Users have to carry an increasingly heavy burden of the decisions made to meet business-centric metrics.

One of these two design options is easier than the other. (Hint: It’s not the one where you write better content.) And when jobs and performance bonuses are on the line, easier is, well, easier, even if it means less than optimal outcomes for customers. A business-centric definition of success leaves both options on the table. And the onus is frequently on the team to determine the implications of their solutions, the company or team leader having effectively absolved themselves from establishing any guardrails or ethical guidance.

—

Being intentional about the way you word your definition of success can completely change the thought process for your team. In the example of our article site, what if, instead of saying we need to increase page views (or increase revenue), the company said we need to improve article quality? This shift completely flips the conversation, and we move from a business-centric thought process to a user-centered thought process. Unlike increasing page views or revenue, increasing article quality delivers actual value to the user, while still driving the same business outcome. Better articles mean more reads and more shares, which means more page views, which means more revenue.

Many of the same solutions that could be applied to “increase page views” can still be applied to this new, user-centric definition. You might even still measure this in page views, but by changing the words you use, you have actively taken certain solutions off the table and set the parameters for what is acceptable. When the goal is to improve article quality, an unreadable layout with 10 clicks to get to the end of the article no longer makes the cut.

For about seven years, I was head of product and UX for a streaming video subscription service similar to Netflix. As a monthly subscription service, our key business metric was user retention as measured by Lifetime Value (LTV). The more subscribers we could keep month over month, the more revenue we would generate from each customer, increasing their LTV. As such, “improve customer retention” became a driving mantra within the company.

As a team, we tried and suggested lots of different things to meet this definition of success. But one recurring suggestion really stuck out to me. Over the course of seven years, on at least four separate occasions, someone suggested that we remove the cancel button from our website and force customers to call our customer service line in order to cancel. Now, I’m happy to report that I was able to fight that back each time, and we never actually did it. But it kept coming up. And honestly, no one really even wanted to do it, not even the people who were suggesting it. It’s an objectively shitty thing to do. So why did we have to continually waste valuable time debating it?

The issue was that our definition of success—improve customer retention—was business-centric. Again, like the page view example, there are lots of ways you can improve subscriber retention. For a streaming video service you could:

1. Add new features
2. Improve existing features
3. Add new content
4. Make it harder for someone to cancel

All of those options fit when the goal is to improve customer retention. The business-centric definition leaves it to the team to make the determination. The metric itself doesn’t do any of the heavy lifting to narrow the options or provide ethical guardrails.

What if, instead, we had talked about it as “we need to improve customer satisfaction”? Again, this drives toward the same end state. A more satisfied subscriber will stay longer. But it changes the list of available options. Now a team could:

1. Add new features
2. Improve existing features
3. Add new content

Making it harder for someone to cancel no longer makes the cut because it does not match the definition of success.

Talking about metrics in a user-centered way sends a clear signal about who and what is most important in what you are doing as a company. You draw an ethical line in the sand signifying that some solutions are off the table no matter how easy or viable they are. This kind of shift can have a ripple effect throughout the entire culture of a company.

Users have to carry an increasingly heavy burden of the decisions made to meet business-centric metrics. The addictive nature of social media, the impact of algorithmically driven echo chambers, the overly aggressive harvesting of our data—these are all propagated and sustained due to business-centric thinking and business-centric definitions of success. Making sure you are solving the right problem is important in a design process, but understanding the impact of the way you define success is even more critical. They say you can’t win the game unless you know how the score is being kept. As a company or a team leader, you have an opportunity to define your scorekeeping in a way that nudges your team toward better outcomes for everyone.

—

“How You Define Success Is Hurting Your Users” was originally published in Medium on December 9, 2019.

In our drive for speed, we have conditioned ourselves to ignore our most vulnerable users. We design for the happy path, and society pays the price.

The happy path

To create digital products, designers often start by developing a set of scenarios or use cases. These scenarios help determine the features, interactions, and technological infrastructure required in a product.

As an example, let’s think about Facebook. When Mark Zuckerberg was initially creating the social network he may have had a scenario like this in his head:

“An undergrad who wants to share pictures from a party with her friends.”

This is a straightforward statement, but even something as simple as this can help a designer conceptualize the kind of solution required. In the case of a digital product, they can start to imagine the screens that might be needed, the elements on those screens, and so on.

Scenarios come in two basic flavors: happy path and edge cases.

The happy path is a scenario where everything is perfectly aligned for the feature/product to work exactly as the designer intended:

“A benign undergrad goes to a party and takes some inoffensive pictures. She comes home to her computer [remember this is early Facebook] with excellent internet connection, she logs in and uploads her photos with no issues, they go into the database and are disseminated to her friends.”

This is a happy path as we think of it today. As Goldilocks might say, everything is just right.

Many designers start with the happy path because it’s the path of least resistance. It takes the least amount of effort to conceptualize because it removes many of the inconvenient complexities that might exist. That doesn’t necessarily mean it’s easy to design; it’s just comparatively simplified.

The second type of scenario is the edge case. Edge cases deviate from the happy path and, theoretically, they happen less frequently than the happy path. There are two types of edge cases.

The first are technical edge cases, where something goes wrong in the technical flow of the scenario. Maybe there is an error in the photo upload process and it never goes through. Or maybe a user inputs incorrect data in a form field. This is the kind of technical complexity a QA person can test for. Very often a design process will address these kinds of edge cases, or will at least address the major ones. Any decent designer or engineer knows it is important to handle errors and help the user recover from them.

Then there are what I call contextual edge cases: behavioral deviations from the happy path. In our photo upload scenario, a contextual edge case might involve the user uploading a photo that is offensive or pornographic, or uploading a photo of someone else who doesn’t want that photo to live on the site. This kind of edge case can have very significant real-world implications. Unfortunately, these are also the edge cases that rarely get addressed in the design process.

The drive for speed

Today, success in the tech world is defined by speed, scale, and growth — how big can a company get and how fast can it get there. Facebook’s motto is “move fast and break things,” and product teams throughout the industry obsess over how quickly they can “ship features.” VCs even write books about how to run startups in hyperspeed, so you can validate (or invalidate) your idea as quickly as possible and waste the absolute minimum amount of people’s (read: VCs’) time. They call it “blitzscaling.”

The idea of moving quickly has become deeply ingrained in our culture of design, technology, and business.

One of the ways we achieve speed is by focusing on the happy path. Often a team’s strategy is to get the happy path done first as an MVP (minimum viable product) so they can quickly get it out to users before they put more effort into handling edge cases. The problem is that teams rarely come back to handle edge cases. Inevitably, new priorities come up and everyone moves on. What was once considered an MVP is now considered a final product.

Over time, this constant deprioritizing of edge cases conditions designers and engineers to just start ignoring them. Overloaded with work and impossible deadlines, it becomes easier to just pretend edge cases don’t exist.

The impact of the happy path

A few weeks back, a startup called Superhuman released a new “read receipt” feature for their email client product. If I send you an email using Superhuman and you open it in whatever email client you use (Gmail, Yahoo, etc.), the read receipt feature sends me a notification telling me you opened it. Straightforward enough. But there were two twists with Superhuman’s implementation. First, the read receipt didn’t just tell me that you opened the message, it also gave me location data of where you were when you opened it. Yikes. Second, you, the recipient, had no way of opting out of the feature. Regardless of the settings in your email client, you would always send me a read receipt. Double yikes.

This kind of feature has huge implications for victims of stalking, abuse, and so many other negative scenarios. Unsurprisingly, there was an outcry, and Superhuman modified the feature. But the feature should have never left the gate in the first place. When the controversy happened, Superhuman wrote a blog post and the CEO tweeted an apology:

“We did not imagine the potential for misuse.”

If this tweet is to be believed, it seems the idea that there could be deviations from the happy path didn’t even come up in the design process. It wasn’t even on their radar. Our drive for speed has conditioned us to design as if edge cases don’t exist. It’s not that we just decide not to solve them, it’s that we don’t even imagine them. These are practices handed down across companies and design schools. Many of us are so well trained at this point, slowing down doesn’t even guarantee a better outcome; ignoring edge cases is subconsciously baked into our process.

As companies push for scale and growth at breakneck pace they are weaponizing technology against groups that fall outside of their defined happy path.

We’re watching the cumulative impact of this play out on the web every day. Massive platforms like YouTube, Facebook, and Twitter were all architected with a best-case-scenario, happy-path mentality — a benign user sharing what they had for lunch or posting a video of their cat. The edge cases of abuse, harassment, and misinformation were all but ignored until they reached a scale where public scrutiny made it impossible to continue ignoring them, but by then it was too late. Addressing edge cases is not in the DNA of these companies. When you have spent 15 years fusing your business model to the happy path, your processes, organizational structures, and mentality are not geared to think beyond it. So these platforms are either slow to respond or completely incapable of it.

Happy path design is not human-centered, it is business-centered. It’s good for businesses because it allows them to move fast. But speed provides no benefit to the user. As companies push for scale and growth at breakneck pace they are systematically weaponizing technology against groups and use cases that fall outside of their defined happy path.

Who is in the happy path?

Part of the justification for happy path design is that edge cases are rare. In some cases, they might only affect 1% of a product’s users. Mike Monteiro points out the fallacy in this thinking in his book Ruined by Design:

Facebook claims to have two billion users…1% of two billion is twenty million. When you’re moving fast and breaking things 1% is well within the acceptable breaking point for rolling out new work. Yet it contains twenty million people. They have names. They have faces. Technology companies call these people edge cases, because they live at the margins. They are, by definition, the marginalized.

On top of this, the actual process of happy path design often involves having a default user persona who fits nicely into your complication-free use cases. This compounds the happy path problem because it means we are not only looking at a contrived view of the scenario itself but also at an artificially small slice of potential users.

After all, the happy path is free of risk and complication. By definition, the people with the least risk and complication are the least vulnerable users of a product.

Everyone else, as Monteiro pointed out, sit at the margins and are given almost no thought until after the damage is done and there is some kind of outcry.


More often than not, the humans who sit on the margins of our products are the same humans who sit on the margins of society.

When Superhuman was designing their read receipt feature, they weren’t designing it for people at risk of stalking and abuse (statistically, most likely women). They were designing it for their default user, who I would assume is some VC (statistically, most likely a man) sending off an urgent email to a founder (statistically, also most likely a man).

I’m making an assumption here — maybe they include women personas in their design process — but here is the real rub: Their personas are irrelevant. Despite what we say about having empathy in design, the default user is always ourselves. The idea of designer empathy is the biggest trick we’ve ever pulled on ourselves. Unless the person you are designing for shares your life experience, you cannot put yourself in their shoes in any meaningful way. Uncovering consumer insights is not the same as empathy, and human-centered design is not a magic shield against bias.

The humans who sit on the margins of our products are the same humans who sit on the margins of society.

A quick perusal of the Superhuman website shows that their product and engineering team is 83% dudes. Maybe someone pushed back on the read receipt feature, maybe they didn’t. But it’s almost guaranteed that a dude made the final decision. By and large, dudes don’t walk around afraid of abuse or stalking. It is, by and large, not our life experience.

“We did not imagine the potential for misuse.”

Designing for speed has trained us to ignore edge cases, and the overwhelming prevalence of homogenous teams made up of the least vulnerable among us (read: dudes) has conditioned us to center their life experience in our design process.

The canary in the coal mine

Miners used to take canaries with them into the coal mine. The idea was that the canaries were more vulnerable to the harmful gases that can build up in a mine. If the canary was fine, everyone knew things were safe. If something happened to the canary, it was a sign for everyone to get out.

This is a robust system. If you design for the well-being of the most vulnerable, you design for the well-being of everyone. We don’t design like that today. Today we design for the least vulnerable and then pretend nothing bad ever happens in a coal mine.

The breadth of the scenarios we consider determines how resilient our products are to deviations in the intended behavior. Today we are building massive platforms, with massive reach and impact, yet they are massively fragile. If we are honest with ourselves, these platforms represent a failure of design. Their success hinges on an intentional disregard for human complexity, and society pays the price for it.

The real happy path is not the path of least resistance; it’s the path of most resilience.

We have to redefine what a happy path is and relearn how to embrace complexity. In our Facebook photo-sharing example, what if our initial scenario looked something like this instead:

“A guy shares a compromising photo of a woman with his friends, and the woman is able to remove it from the site.”

This is what a happy path should be. It gets us to the same place as the original statement, and we still have to design and build the interactions required to let that guy share his photo. But it also does something crucial: It centers the most vulnerable user over the least vulnerable. It bakes the idea of misuse and negative outcomes into the core of our thought process and fuses it into the DNA of the organization.

—

The real happy path is not the path of least resistance; it’s the path of most resilience.

A lot of entrepreneurs talk about “first principles” as a way to identify their assumptions and guide their product development. While it may never have been explicitly stated, the inherent bias in our product development approach has meant that our underlying first principle has been to ignore human complexity. Redefining the happy path means establishing resiliency as our underlying first principle and moves the vulnerable to the center of our thinking. It forces us to embrace complexity and understand that when we design for the vulnerable, we design for everyone. No more half solutions.


Would this approach slow teams down? Maybe a bit, but we are not talking about creating “perfect solutions,” just slightly more robust ones that center someone other than your average white guy. I would also argue that if the success or failure of your company is determined by a few extra days/weeks of development time, there are bigger problems going on.

We will never be able to come up with scenarios for every possible edge case; it’s impossible and that’s not what I’m suggesting. We also don’t need to. By starting with even one, we fundamentally change the foundation of our thought process. This kind of structural shift can enable individuals and organizations to cultivate the competencies and capabilities required to not only flag potential future issues, but to bring real solutions to the table when they inevitably emerge. That’s a happier path for everyone.

—

“Edge Cases Are Real and They’re Hurting Your Users” was originally published in Medium on September 4, 2019.

Late last year, I wrote a piece titled “Design Won’t Save the World.” It focused on the limits of human-centered design and its failure to impact the big problems we face. The morning the piece was published, my wife sat in our living room reading through it. When she finished she said, “we need bee-centered design.” Since that moment I’ve been thinking about what that would mean.

Wikipedia defines human-centered design (HCD) as “a design and management framework that develops solutions to problems by involving the human perspective in all steps of the problem-solving process.”

Hasn’t our entire existence been about involving the human perspective in all steps of the process? I mean, at one point we literally believed that we were the center of the universe. Empirically we’ve figured out that we’re not the center of everything but practically, we pretty much still carry on as if we are. We are very aware of the vast and powerful interplay between the parts and pieces that surround us, but we continue to see the world as one big show unfolding in service to us. When you get right down to it, human-centered design is just an extension of this belief in both name and execution.

Humans have a lot of problems that need solving — and we should try to solve those problems. But humans don’t exist in isolation; we are but one very small piece in a very large puzzle. While centering the human perspective can help foster more humane design outcomes, it also perpetuates myopic navel-gazing.

By centering on the human perspective, we also center our narrow definition of success.

When we observe a problem that impacts people, our process dictates that we solve it. Very often, these solutions are developed in isolation, exclusively from the human perspective. This creates a solutions-at-all costs mentality in which we often ignore any risk of broader impacts, rarely asking ourselves if the problem should even be solved in the first place. This inward-looking approach leads to a lot of human-centered solutions — but it also leads to a lot of collateral damage to the larger systems around us.

By centering the human perspective, we also center our narrow definition of success. We believe that business metrics and economic growth are the end-all, be-all of human progress. But when we infuse that belief into all steps of the problem-solving process, it becomes the frame through which we view all outcomes. In many cases, a solution is not deemed successful unless it carries a financial upside. (This doesn’t have to mean actual revenue; it can simply mean shareholder value, as we see with many web companies.) Whether the solution solves the original problem or not is almost entirely irrelevant. This prioritization of profits over progress puts a ceiling on the amount of real, human value we can actually deliver. It also papers over any resulting collateral damage.

While centering the human perspective has allowed us to make important gains, it doesn’t scale. In an interdependent system, continually over-prioritizing the needs and desires of a single component will eventually cause the entire system to collapse.

It’s time for us to broaden our perspective. We need to start looking beyond the ends of our own noses.

What is bee-centered design?

So, what does bee-centered design really look like? I’ve realized that it’s not necessarily a literal concept. We don’t gain anything by actually putting bees at the center of our decision-making processes, or by spending lots of time creating solutions to problems that the bees didn’t even know they had. Rather, it’s about shifting our mindset to open up a much-needed new perspective for the things we create.

The “canary in the coal mine” mentality

The scale of our impact on the environment is enormous. In our current design paradigm, we largely assess that impact based on short-term outcomes for ourselves. If something doesn’t kill us immediately, we’ll give it a thumbs-up. But we are the strongest link in the chain and in an interdependent system, the chain is only as strong as its weakest link. Unfortunately, our approach to design has been knocking off weak links left and right.

So far, we have largely shielded ourselves from this downside with our technical resilience. But there is a limit to what we can withstand.

Bees are a sentinel species. They are more fragile and susceptible to environmental changes than species further up the food chain, and their health is an early indicator of impending ecological issues. If our design process shifted to center them, or to focus on other weaker links, we would have to consider the impacts of our actions beyond our immediate health and safety. This small change could mean a complete shift in our tolerance for risk, and in our patterns of creation and consumption.

This principle isn’t just about sustainability; it’s also about the quality of our design solutions. In a previous career, I was a health inspector. The regulations I used to enforce food safety were developed based upon risk tolerances aimed to protect the most vulnerable among us: young children, the elderly, and the immunocompromised. While this system created a more stringent set of rules, it also made the rules significantly more effective. A standard set to protect a baby will almost always protect a healthy adult.

Nothing we create exists in isolation; it all lives within the overall natural system. If we architect our solutions with tolerances that support the more vulnerable aspects of that system, we’ll actually craft a more effective solution. If we design for the health of the canary in the coal mine, we will also be designing for the health of the miner.

A common goal

Bees work in service of their hives. The hive system delivers maximum value because everyone feeds into it and moves in the same direction. The key to the hive’s effectiveness is that every bee within it has a clear view of where they are going. Humans don’t have that; on the whole, we don’t have shared goals. The closest thing we have is the profit motive (and, I guess, basic survival).

Where are we going and to what end? Are we just making shit for the hell of it? Do we want to pile up money? Solve all human problems? Fill every possible niche with a product? These are obviously big questions but they aren’t questions that our existing design frameworks even remotely try to address.

We’re trained to ask questions — but why don’t we question the validity and value of our obsession with solving problems that affect only us?

Instead, our current frameworks root us in processes and problems. Design thinking, for example, is rooted in “empathy, optimism, iteration, creative confidence, experimentation, and an embrace of ambiguity and failure.” This is all about process, not outcomes. It provides a playbook for how to find problems and steps for how to develop solutions, but it doesn’t guide the outcomes for those solutions. It doesn’t get us all moving in the same direction.

What if the core of our design framework was rooted in a set of universal outcomes? What if we had a common set of goals to pull toward, regardless of what product we’re designing or what industry we’re working in? These goals could be built around things like empowerment, inclusivity, sustainability, equity, and opportunity. They could become a base filter through which we evaluate all of our designs.

Having collective goals would not negate the need for process altogether. Instead, it would ground that process in a shared ethos, amplifying the power of all of our efforts in a common direction rather than pushing each of us to grasp in isolation for something greater.

Widening our view of the world

Bee-centered design would also, quite simply, widen our view of the world. It would mean taking a moment to get out of our human bubble and look around. We’ve told ourselves so many stories about the way things are supposed to be; those stories play on autopilot every time we create something. We’re trained to ask questions — but why don’t we question the validity and value of our obsession with solving problems that affect only us?

Why do our companies need to become monopolies in order to win? Why do our products need to maximize engagement? Why is convincing people to upgrade every 12 months a good thing?

Does every product deserve to exist? Does every problem need to be solved?

Human-centered thinking keeps us locked in our human-centered bubble. We need to break out.

—

“Human-Centered Design Is Broken. Here’s a Better Alternative.” was originally published in Medium on March 27, 2019.