Creating A Customer-Obsessed Design Culture: Validating The Why
Teams that design and build experiences can have radically different ways of approaching problems. You can see this in architecture and urban spaces. The photograph above from a street in Shanghai has a mix of spaces for people to interact. Did the architects think about the details of these interactions? Or was the large advertisement placed there as an afterthought to cover the construction going on? Or was it an add-on when someone in marketing realized that lots of people were congregating in the area? Was there a coherent plan or did incrementalism (the equivalent of adding features to a product) drive the final result?
A key element of building a customer-obsessed culture is framing problems in a way that considers the entire customer journey. This end-to-end experience can extend outside interactions with technology and solutions to the context and sequence of daily activities. Before someone even picks up their phone and decides which app to open, where are they? What are they doing? What are their goals? What choices do they have for how to spend their time? For these types of questions to become part of a culture, a shift typically occurs at the beginning of a project where the goals are set and the project defined.
Some projects start off with a broad question. This encourages the team to take the time to understand a range of customer needs and the opportunity. At Google, I lead the UX team for travel early on (formative concepts and strategy for flights, hotels, etc.). We were asked to solve for the query “Warm places to go in June” — specifically what should people see when they type that into Google? Hmm. Well, if they are traveling for work they probably want one thing. If it’s a family that’s another. What about a group of friends trying to coordinate a trip together? What’s important to these different groups? How do people plan travel and make decisions about where to go, where to stay, and what to do? You quickly start mapping out scenarios and thinking about the experiences, needs, and goals. That’s a different way to solve problems than adding features.
It’s not just how teams tackle a problem. It’s the type of questions and the way they get asked that shape the parameters, frame the problem, and provide indicators of the general culture for solving problems together. It gets quickly into values about what’s important. For design, part of these activities are how we represent the challenges and opportunities. Take a close look at how these get produced, circulated, evaluated, and acted upon if you want some insights into your current team and the company culture. And note the important differences between teams and people.
At Google, Dr. Frederik Pferdt launched a program to bring design thinking and innovation to teams across the company. I was the first UX person to get involved and co-led a few sessions with him early on in the US, Japan, and China where my primary project was at that time. Through a broad team of volunteers his Creative Skills Institute reached thousands of people across the company and introduced them to design thinking (I prefer the term design).
A key piece of these workshops were getting people to interview “users” (sometimes just people in the hall) and ask why? It was the first experience like this for many people and they had to ask why multiple times in response to questions and answers. The simple act of asking questions to customers sets up a dynamic of inquiry that is critical to creating customer-obsessed cultures and advocating for customer needs. I remember one backend systems engineering at an early workshop who was skeptical of the relevance of design thinking for his work. By the end of the session, he was excited because he had an ah-ha! moment where he saw how he could use the techniques to clarify requirements and build consensus with his stakeholders. He went back to his team as an evangelist for these new ways of working through asking better questions.
Ground-sourced efforts are more effective because they build on the existing beliefs and relationships of the people across the company. This was true for the Google work. This initiative was owned not just by Dr. Pferdt but by volunteers across the company. The ground-up buy-in was critical to developing, scaling and spreading a common set of beliefs and practices. This trajectory was similar to the way that the PMs at PicsArt adopted, changed, and spread practices around testing and user needs in the first article in this series.
We need to understand where a culture is now and build from there. You’ve probably noticed that many product teams start by describing how a product works and what they want users to do. This makes a lot of sense because it’s what engineering needs to build the product. In many cases, teams shortcut the foundational work of understanding their target audience and move right into building and testing using lean, agile, RITE, and other iterative methods that can over time uncover customer needs. The rationale is usually that we want to move quickly and not surprisingly that mindset becomes part of the culture. While this approach tends to move quickly at first, the iterative process can take a long time to land on a viable solution especially its off target at first. I’ve heard many PMs say that they don’t have time for a discovery phase and need to “just get something out”.
These feature-focused cultures need to see how customer-centered approaches are faster or that they have better results. I’ve demonstrated this repeatedly by quickly running user tests and getting results to teams within 24–48 hours. This approach gave the product teams some immediate actionable feedback — sometimes confirming their intuition and sometimes raising issues that afterwards they saw were obvious problems.
Getting teams to think about the questions they would ask people using their products is design’s subversive goal when running user tests. Running these tests requires teams to identify the driving questions behind the product which are needed to run the tests. The simple act of creating a test script surfaces all sorts of questions for the team because they need to think about the mindset and value for someone using the feature or product.
Creating a customer-obsessed culture and a practice of principled design requires more than just putting the user back into the process, doing some presentations, asking a few questions or circulating some visually soul-inspiring decks. Jennifer Gergen hit it right on in her article about launching Meetup’s design culture when she talks about accumulated design debt:
“Meetup, like all aging software products, had accumulated a lot of debt. Whenever this happens, it seems like half of the company wants to claw it back and clean things up while the other half is bolting after some new idea and adding to the mess. It’s not always obvious what is in the best interest of the user — and this user advocacy is the primary function of experience designers.”
A key part of customer advocacy involves building a shared understanding around the value of what we are creating and asking questions to make sure we have agreement on key elements of any experience or product.
At GoDaddy, we are building a set of common questions we ask at the beginning of projects. We call this Validating the Why:
- What is the challenge we’re solving?
- How do we know if it’s successful?
- Who is it for?
- Why do people care about it?
- What purpose does it serve?
- What is the value to the business or customer?
Ideally, teams work through these questions together. But we need systems that are flexible enough to handle different levels of specificity. In some cases, PMs will provide detailed answers to these questions at the beginning of a project. Other teams will provide very general product descriptions and UX needs ask these questions.
What I’ve found is that regardless of the scenario, developing a shared understanding of the questions and the answers is essential to alignment in the phase where teams are evaluating alternatives. Part of creating a customer-obsessed culture is embracing principled critique where alternatives are evaluated relative to customer needs. (This is the topic of the third article in this series.)
Ultimately, we should remind ourselves and those around us that the user experience is not owned by the UX team — it is owned by the entire company. A customer-obsessed culture knows that every touchpoint is an integral part of the experience — from sales to support to visual design down to the voice, copy, and tone of emails customers receive. As teams evolve in maturity, this focus on detail and craft can become part of the DNA of the company. Erika Hall in Conversational Design says, “The degree to which a product feels human and goal-oriented in its interactions reflects how well its creators interacted with each other.” People make products and if you want your products to be better, then focus on people and how they work together. That’s culture and design at its most human.
Note: This is the second article in a series. The first article in this series is Creating A Customer-Obsessed Culture
