Listening to Customers: Ain’t Nothing Like the Real Thing

In my last post, I touched on some of the conditions that make pervasive excellence in design possible. Now let’s unpack the first one: access to customers.

But first, a quick story…

I spent the first 15 or so years of my design career as a consultant. Among other things, this gave me the opportunity to pitch work to companies large and small, in all sorts of industries.

Being the a good UX professional that I am, I always tried to include user research in proposals, whether the engagement was huge and strategic or narrowly focused and tactical, whether it was impossibly short or only ridiculously short. (That’s consulting humor for those of you in the back.)

The funny thing was, clients almost never wanted to pay for user research. From start-ups to Fortune 500 enterprises, it was the one trait all had in common. Sometimes we could convince them it was necessary, but not always. In their view, research somehow benefited us, the agency, not them. Also, it “would take too long.” And anyway, they were paying us a lot of money to “have all the answers, right?” (Here is where I hear the voice of my husband, himself a design leader for 20 years: “A good designer doesn’t know the answers. A good designer knows the questions.”)

So, we had to find ways to sneak in the research in the margins of the project. Once, while redesigning an art museum website, my team played hooky for a day to hang out at the “in real life” museum and pester strangers with questions about the kind of experience they would want to have online. Another time, in redesigning a company intranet, we tested our prototype with our own coworkers. After all, we were all employees somewhere, right? Another time, after three no-shows on our only day allotted to user testing for a financial web site, I ran to the closest Starbucks. There I convinced a man in a blue, button-down shirt (standard business attire in San Francisco circa 2003) to give us 30 minutes of his time.

Obviously, this scrappy, seat-of-the-pants approach is flawed. But for me it reinforced a valuable belief — talking to anyone approximating a customer, under any conditions, was better than not talking to them at all. We could at least get fresh eyes on our prototypes to surface the most glaring design issues that we might otherwise have overlooked.

We can’t fake it anymore

At IBM, we design highly specialized software and hardware for people with highly specialized skill sets: reliability engineers, autoworkers, social responsibility executives, health care professionals, data scientists, security specialists…you get the idea. We can’t even begin to guess what all of these people need. We absolutely have to talk with them, observe them in their work, look at the other tools they use, and repeatedly get their feedback on prototypes until we hit upon the right solution. You can call this “user research,” “design research,” “participatory design,” or “co-creation.” Whatever you call it, we must have access to the people who will use the products and experiences we design in order to create things they will love.

Barriers to access

Here’s the challenge: As the things we design become more sophisticated and enigmatic, our need for user input increases. As our need for user input increases, accessing those users becomes increasingly harder. Why is that? Because reliability engineers and security specialists are not exactly thick on the ground. We can’t stand in the museum lobby and casually ask random people for ten minutes of their time.

In my first few months at IBM, I spoke with more than a hundred designers and design-adjacent employees to understand the current state of design. Lack of access to customers (potential buyers as well as end-users, partners, developers, and everyone else in the product and service ecosystem) came up again and again.

What this means for IBM Design

We will give renewed focus to our Research practice to ensure we have customer feedback when we need it most. We will also build a robust practice for sharing these insights so that they may inform company strategy and product roadmaps. Some of the ideas we’ll explore:

· Customer panels — In my experience, engaged customers will happily give their time to share insights when they know designers and product managers are listening. How might we formalize customer participation in product and service development across IBM? How might we leverage the relationships our Sales teams have to make this happen? How might we close the loop so customers know their input is making a difference?

· Co-creation — Our IBM Consulting teams have a stellar track record in co-creating solutions with customers. How might we translate this success to other design teams?

· Support case data — This is often a treasure trove of insights into customers’ most pressing pain points. How are we leveraging support case data today? How might we make it easier to access this data so that product and services teams can prioritize issues for resolution?

· Sales and Support –Sales and Support reps have a wealth of detailed knowledge about customer needs, pain points and, crucially, the objections that hinder our ability to grow market share and win new business. The same goes for other IBM employees who interact regularly with customers, from the Expert Labs team to customer success managers. How might we open lines of communication between design teams and the people who already interact with customers every day?

· Customer satisfaction data — Like many companies, we collect Net Promoter Score (NPS) data. This information is valuable, but not always effective for diagnosing specific experience issues. How might we collect and maintain actionable data on customer satisfaction, and set bold-yet-achievable goals for improvement?

· “Uber” personas — How might we abstract our understanding of customers into a small but useful set of data-driven customer archetypes? How might we disseminate these so that all IBMers share the same understanding of who our customers are, how they engage with us, and what they need from us?

· Research amplification — A lot of great research is already happening at the project level. How might we distill these insights into video clips, abstracts, or other light-weight media so that we can share that hard-won knowledge more broadly?

· Research tools — What is the core set of tools anyone (with or without the word “Research” in their title) needs in order to hit the ground running when they need customer input?

As always, I welcome your thoughts — both IBMers as well as others in the design industry — as we continue to define this new chapter of IBM Design.

***

The above article is personal and does not necessarily represent IBM’s positions, strategies, or opinions.