The messy reality of the discovery process

There are few questions that genuinely make me sweat as a designer. I love sharing anything from deeply considered rationales to flimsy gut takes. At least the latter gets the conversation going, right? But one question that weirdly stumps me is usually phrased something like this:

Simple enough, right?

I’m genuinely embarrassed to admit that I don’t remember how I got where I did most of the time. Design discovery for me is akin to entering a fugue state where I’m just stumbling to an output that hopefully has some semblance of clarity for others.

There’s nothing particularly inspiring about that though. Nothing to learn and grow from. And frankly, if I can’t articulate what’s happening in the messy middle of my process, how the hell can I improve it for myself or others?

So here’s one attempt to break down a recent example to grow that observational muscle of how I work. Or at least function as a reminder to keep one eye open as I’m going through the design process going forward.

Recently, my team had begun ideating how to enable better communication through our client portal service. It was an area that had not gone through too many updates over the last couple of years and we had enough anecdotal insights from customers to know it could be a much more effective relationship management tool for them.

We were going to take a holistic approach to improving the portal, from first to last contact between a service provider and their client. So, to better understand the touch points of this service overall and identify the biggest pain points, my first instinct was to map the relationship between the two.

I began collecting feedback directly related to the client portal and mapping each item to our established workflow buckets: Winning the work, doing the work, and getting paid.

I divided the feedback by what our customers were saying, and what their clients were telling them on the other end into columns of related issues. I could see standout issues emerging for a larger pain point that I began marking in red for memory’s sake but I hadn’t landed on how I wanted to present hierarchy yet.

At this point the board was just a tool for myself to work through the information and I wasn’t concerned about how to effectively present it to others. I would just create visual reminders in whatever way suited me that I knew I wanted to return to later.

Within the three workflow buckets, I could see that my columns could be organized on a more macro level. This was expected, but I wanted it to develop organically from the feedback itself rather than being overly restrictive too soon based on established product terms.

Although most feedback would map directly to the data model and product terminology we use because our customers are speaking to us about our platform, there’s is always an opportunity to identify gaps in the grey areas that align better to the mental models of our customers based on how they talk about the work.

After all feedback was organized on the board, I began looking at a more effective way to present hierarchy and label each type of concern to pull out themes.

The final diagram has multiple layers of context that help to create a full portrait of the client portal and it’s issues:

Okay! We have a deliverable! It tells us some valuable things, but mapping to feedback only gives us insight into what users are taking the time to reach out and tell us. This realistically is a very small percentage of the user base, and clients of our customers would never reach out to us directly so we are one big step removed from their experience as well. This leaves a lot of blindspots.

This deliverable can’t completely answer:

To answer those questions, I started loosely mapping out my experience as I audited the product, something akin to a workflow diagram. I don’t normally reach for a specific method or design discovery tool early on, usually leaving this till the end of the process.

I’m sure this is what a lot of designers can relate to - the messy police investigation board stage. A mix of UI screenshots, triggers plotted, potential gaps identified, and questions at confusion points…frankly, a diagram of chaos that only the designer can understand and interpret. It’s only at this point that I start figuring out a specific visual tool to use so my peers don’t have to look at this map and get concerned for my wellbeing. In my case, I chose the service blueprint.

Nielsen Norman Group (https://www.nngroup.com/articles/service-blueprints-definition/)

Sounds like exactly what I need, right?

This might be a bit of a designer-sin to admit (but I kind of doubt it): I rarely use discovery frameworks as prescribed. I don’t see a lot of my peers doing so either, particularly over time. It’s a bit like “Who’s Line is it Anyway?” - All frameworks are made up, and the points don’t matter.

When a designer is first learning how to break down problems and set a direction, I do believe strongly that they should try their best to follow design discovery methods as closely as they can so they can begin to break down the value of them and how to use them effectively. But after a certain point, no one’s grading you on your ability to follow the rules. What’s important is creating an outcome that has an impact.

All that being said, I initially tried my best to fit with the prescribed framework as popularly defined:

I didn’t like what was emerging at this point. A service blueprint can be effective at communicating how the business touch points relate to the customer experience, but I was struggling to fit in the relationship of our customers and their clients in a way that was easy to understand. Plus the terminology generally used (backstage, front stage, line of visibility) didn’t resonate with me, and I wanted it to be more self-explanatory to my team.

At this point, there might be a service designer out there more well versed in this type of methodology that is screaming at me because I don’t understand how to use these tools the right way. Likely true! This is just an attempt to articulate how I get the output I need to make decisions, not to prescribe it as a hot take that others need to follow.

I made some adjustments that essentially resulted in a franken-child between a service blueprint and a customer journey map:

Here’s where it ended up:

Now I had a tool that made it possible for stakeholders to evaluate the whole system, and identify their own observations and opportunities that could get baked into the diagram over time.

This has been an effective tool to create a shared understanding of how our client portal performs currently as well as the potential opportunities and gaps we need to address. Our specific team has already used this to identify a theme of improvements that addresses multiple touch points across the system.

Reflecting on this discovery process gave me an awareness into how I work that I was struggling to communicate beforehand. If I could offer any summary of the way I approach this type of discovery, for better or worse, it would be this: