UX case study: how qualitative research powered enterprise design

Design isn’t just about making a user interface. Discovering how users think, speak, and operate informs how we create experiences. Discover how qualitative research empowered multiple design teams to rally around a major sales product redesign.

A world-famous tech company was hemorrhaging money through missed sales opportunities. The software it had built for its salespeople made their lives more difficult, not easier. Sales teams wasted inordinate amounts of time dealing with poor systems, including:

• Acting like support agents instead of landing new business.
• Jumping between 7+ tools to complete basic workflows.
• Scrambling to collate client data before and during sales calls.
• Searching for surfaces not linked in the navigation.

Trained sales professionals were struggling to complete basic workflows. We’re talking cold calling, pitching solutions, and analyzing client performance, here.

Naturally, it needed a redesign. The company’s executives tapped their design directors to improve the sales experience with a few key directives:

1. Make sales workflows faster.
2. Give salespeople cohesive client information at a glance.
3. Let salespeople monitor client accounts with real-time data.

It all made sense. But then the executives said…

“Great. Show us the MVP in a few weeks.”

Everybody sprang into action: the product designers jumped into Figma. The engineers discussed infrastructure avidly. The data scientists ignored everyone and did their thing.

I still had a few questions, though:

• How does the sales team organize itself?
• Does every sales team have similar workflows?
• What do all these random terms mean?
• Do we even know all of our sales users?

Crickets.

* Cue cricket noises. *

Everyone knew that they risked repeating the same mistakes that created the product’s existing flaws, but they were all locked into a top-down management style that focused on short-term updates instead of long-term vision. Their jobs depended on complying.

This put the project at serious risk of flopping (again) because the company’s culture stressed speed over quality.

Even worse, this sales software redesign was just one part of a much larger project intended to unify sales software with related but isolated systems used by support staff and the company’s actual clients. Failure here would jeopardize the entire thing.

And we had no UX researcher to tell us basic questions, like “who are our users and how do they like the product?”

That’s when I decided to conduct my own qualitative research.

The process

The company had an uncomfortably large content debt that had grown over a decade of designing without proper support. Conducting qualitative research was my first step in balancing that debt.

Normally, that kind of work would be done well in advance, or even just given substantial lead time before design and engineering teams start prototyping. But executive leadership had told everyone to scramble, so I was working against the clock.

That meant product designers started work on their prototypes before UX researchers could run studies or interview users, or before the content designer could establish sales operating frameworks to transpose into a digital product. There were no UXRs or content designers on this project other than me, though, so I had my work cut out for me.

Two things bugged me in particular:

1. I didn’t understand the many fractured terms in the existing UI, and neither did anyone else.
2. I didn’t understand the big concepts that salespeople took for granted.

So that’s where I started. The several design teams working across this multi-project effort didn’t have this information either, so I set out to create a resource that explained it all.

Here’s why I chose this approach:

1. Uninformed UX writing would add confusion in the UI and miss critical concepts.
2. Product designers needed a guide to make DIY content decisions when I wasn’t available.
3. This qualitative research would set up future design work for years to come.

Excavating the sales division

Either way, I had to decode how the sales division operated. The first challenge was that this division wasn’t monolithic. It was split into two major groups, and one of those groups had fragmented teams, each with its own lingo and way of doing things.

There were 3 key challenges here:

1. The sales division operated with diverse frameworks, workflows, and terms.
2. Sales executives “rebranded” their groups internally every few years with buzzwords and empty concepts.
3. Internal documentation hadn’t been maintained for at least several years, so there was no source of truth.

I realized I was living through the kind of real-life inspiration that fuelled the satirical “Conjoined triangles of success” on HBO’s Silicon Valley.

Here’s how I went about conducting qualitative research for this project:

1. I found as much documentation as I could to get started (although there wasn’t much).
2. I talked to product designers who already had some familiarity with this area. This gave me some baseline context as well as notes that I could revisit to spot possible misconceptions in the future.
3. I interviewed the designers’ sales contacts, and then their second-degree referrals for insights.

Of course, the problem with interviewing salespeople is that they’re already strapped for time. They’re always out on the hunt for that commission, and they don’t have much time to chat. That’s just how it is.

I was able to get around that by meeting a few ex-salespeople who had moved into different roles while staying in the company. They could take the time to bring me up to speed.

They were a goldmine of information. Being salespeople, they knew how to engage with someone in conversation and adapt terms and concepts to their level of understanding—customer education is part of their skill set, after all.

They helped to corroborate workflows, to point out misconceptions, and—most importantly—to explain their biggest annoyances with the existing software.

I recorded all of this in a FigJam research-board-in-progress that the other designers could hop into at any time.

The action

Shortly after starting on it, someone asked me if I could turn the FigJam board into a guided resource. At the same time, I had recently learned that this company disseminated knowledge through presentation decks in most cases. Making this presentation deck with all of the visualized concepts I had made in FigJam seemed to be the ideal way to share what I’d learned with the maximum number of people.

I signed up to present it for the following week, inviting people to use it for their designs moving forward.

That was the first deliverable: a Sales 101 learning resource condensed for easy consumption.

The second asset was a comprehensive terminology document. As boring as it sounds, none of the design teams really had any source of truth for the terms and ideas they were batting around for their users. I collected, defined, and sourced 200 terms in a living document with confidence levels and contextual notes for each.

The third was a content audit of the existing software. It wasn’t a word document, though—it was a FigJam board so that the product designers could get a clear visual sense of what we were working with. It included all 37 fractured surfaces within this one piece of sales software. Many of them knew areas of the product very well, but didn’t always have a high-altitude view to spot redundancies and inconsistencies at a higher level—and now they do.

I made sure to give these assets visibility in the team’s weekly design updates. I presented these assets to the various design teams, and made sure they knew to treat them like living documents. Having them participate in the process helped to convince people to engage with it rather than just bookmarking it in their browser and forgetting about it.

I also walked a few teams through these resources directly to give them some hands-on experience with it. Letting them know it was okay to put their mark on these assets helped to give them a sense of joint ownership.

All of that was in service of making sure the team actually used these assets.

The result

At the end of this project I had equipped multiple design teams with the assets they needed to make smart content decisions at scale.

I empowered those teams to…

1. Build a new sales experience based on documented and vetted knowledge.
2. Make accurate content decisions on their own, scaled beyond my 1:1: support.
3. Design with a birds-eye view of the existing software, and to spot redundancies at the outset.

Bonus contribution: this also set up the company’s generative AI team for success by providing them with content to train its new large language model. Soon, this company will have an AI assistant that can assist salespeople based on well-researched content explained in plain language for everyone.

The dozens of designers and the hundreds of employees working on this large-scale effort now had tools to build a better sales experience, instead of repeating the same mistakes that led to this redesign in the first place

This project empowered over 10,000 salespeople to do their jobs more effectively.

• It saved them time.
• It reduced their cognitive load.
• It helped them build better client relationships.
• It helped them earn more revenue.

That’s how qualitative research from a content designer helped a large enterprise avoid repeating a project disaster.