There are plenty of comprehensive pieces on the practice of product design out there—our own Kyle Turman has written an excellent post on the Pillars of Digital Product Design—but there’s a crucial layer of thinking that can sometimes elude the design process itself, partially because it’s so obvious that it’s hiding in plain sight.
“Of course my team and I design things people want,” you may be saying.
“We started by carefully analyzing the metrics to understand the pain points, my product partner wrote a brief based on those insights, we designed an elegant solution, validated it via rigorous usability testing—and boom, we shipped it!”
There is absolutely nothing wrong with any of that. In fact, it’s representative of a fairly typical product development process, one that I have been a part of on many occasions at various companies—and, most of the time, it works.
Ask yourself if the following sounds familiar: “We did all of the right things but we couldn’t figure out why so few people engaged with our Very Clever Product Feature™.”
It is difficult to talk about these things generically and, the truth is, there are many reasons why your existing or prospective customers might not respond to what you’ve built as expected, despite an honest attempt to build the best product experience possible. In such cases, when a product team is certain that they’ve followed the process to the letter, it is often discovered that there was a critical misunderstanding of what the user actually wanted or, situationally, was actually willing to do, despite ample signal to the contrary.
Don’t fool yourself
In his essay “How to Get Startup Ideas,” Y Combinator founder Paul Graham suggests the following when assessing product concepts:
“When you have an idea…ask yourself: who wants this right now? Who wants this so much that they’ll use it even when it’s a crappy version…? If you can’t answer that, the idea is probably bad.”
This is, of course, about how to arrive at viable product ideas for a young company, but the overall principle behind this kind of sanity check translates to product design work at any scale. Whatever the problem or roadblock, designers should pay attention to how prospective customers, or a product’s existing users, are living without the ideal solution now. What sort of solutions are they cobbling together from what is available to them? Often, your answer will lie therein. This sounds so basic, but in our pursuit of a metric, it’s easy to overlook an explicit request that is all but spelled out in our existing data and insights.
Visitors not clicking or tapping on the button you want? Sure, maybe it’s not prominent enough. Perhaps the CTA language is not as clear as it could be, and users are just not understanding a specific choice. But it’s possible that your users just don’t care about that action in the first place and that the motivation to complete the task is low in general.
Your first and most important step is to separate your ego from the user’s needs. Designers should focus less on how to further optimize a flow and more on whether the flow itself is solving a problem the user wants solved.
When refining the onboarding experience for people new to Slack, for example, this kind of self-directed candor is key. The only true way to determine what people want is to put ourselves in the shoes of those who may only have the faintest idea of what Slack is, only knowing that it is a tool to communicate—and, sometimes, not even that much. We ask ourselves how much patience someone trying to send their first message might truly have, for example, and, further, whether or not they truly want a feature explained to them right now, however beneficial that feature might be.
Your first and most important step is to separate your ego from the user’s needs.
Of course, this is not an either/or scenario. When it comes to assessing the success or failure of a solution, product designers should be looking at all possibilities. But designers often dig in and rule out this more nuanced perspective because it can be scary to question the premise itself, especially when they’ve already been working on the solution for weeks, or even months.
But if your goal is truly to create experiences that speak to real customer needs, it is essential to first separate reality from wishful thinking.
Move the goalposts
At times, you will need to not just follow user behavior but also influence it. It is incredibly difficult to fight the inertia of a learned behavior or to sway people from a trusted solution, but it’s important to remember that even this challenge is still about making things that people want. Even when you’re asking a user to change their ways, the same principle applies: if the solution isn’t addressing the actual needs of that user, you will likely get nowhere.
Small changes in behavior don’t have to be complicated. Business needs may require you, for example, to nudge a customer toward a specific path within a larger flow. The solution could be as simple as changing the prominence of the desired option, assuming that they were previously at parity. This kind of optimization is fairly straightforward and can be accomplished through rapid experimentation.
But when you want to drastically change the overall engagement with your product or feature—when an audio streaming service wants to turn their music listeners into podcast listeners, for example, or when a product known for booking vacation homes wants their customers to view them as an overall travel destination hub—you’ll need to take brand perception and existing expectations into account, on top of table stakes like usability and functional clarity.
Doubling down on what the customer wants and needs has never been more important — or more complex.
At Slack, with Slack Connect, we’re arguably designing for both scenarios at once. Slack is already known as a best-in-class collaboration tool for internal teams, and it’s crucial that everything our customers love about how easy it is to collaborate within their organization remains stable.
However, we now also want to show how powerful Slack can be when it comes to communicating externally with partners, vendors, and individuals. This is a big shift in how many of our customers understand Slack as a tool, so it requires us to stay especially sensitive to the expectations that already exist within the working world—considerations not just about privacy and security, but also ease of use. For us, doubling down on what the customer wants and needs has never been more important—or more complex.
By now, it might seem like I’m suggesting that you should only ever build something if you have airtight evidence people already want and need it. What about innovation? What about risk-taking? These stretches are hugely important when anticipating the ever-evolving needs of customers.
The tricky thing about committing to an ethos of designing things that people want is that, every once in a while, people don’t know what they want until they see it. How do you design for that blind spot? By paying attention to what’s missing. More specifically, it can be about paying attention to what customers don’t want.
2020 showed us plenty of things people don’t want. Among them: a jam-packed calendar, nonstop meetings in makeshift home offices, and an always-on camera.
At Slack, we often “dogfood” our own features at the very earliest stages, testing them on ourselves and, more crucially, a trusted group of pilot customers before launching to the public in any capacity. So when the team responsible for Slack Huddles launched the feature in an internal beta last year, we were all excited for the experiment. As an audio-based “tap on the shoulder,” the team designed Slack Huddles as a way for colleagues to simulate the immediacy of an ad-hoc hallway chat, all within an existing DM or channel. For the rest of us, we could tell it was going to change things, even if we didn’t know exactly how.
Every once in a while, people don’t know what they want until they see it.
Today, I can’t overstate how much the feature has improved the landscape of my workday. It’s given us a way to have a quick, unstructured conversation without the obligation of a formal calendar block or an on-camera face-to-face. During an incredibly challenging year in which the spontaneous conversation effectively vanished, Slack Huddles managed to revive it.
But Slack Huddles is also a solution that I would have found difficult to articulate as a user, had I not understood the very human need that inspired it: real-time, spontaneous connection in the workplace.
Noah Weiss, Slack’s VP of Product Development, who was also focused on leading this initiative, describes its genesis well, remarking that Slack Huddles “was born from triangulating between where the world was obviously going, what we were hearing from customers as pain points…and what we were feeling ourselves about product experiences we wish existed.”
You are the user’s first line of defense
Designers are in a great position to keep a product team honest. We live at the intersection of customer need, human empathy, business requirements, and product strategy, and are responsible for helping to create products that impact the lives of humans in ways large and small. As such, we are also responsible for keeping a very important self-reflective question at the forefront of our minds as we go to work: who asked for this?