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:
You did a good job of breaking down the complexity of [X thing]. Could you share your process and how you got there with other designers on the team?
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. Slightly amusing maybe, but nothing to learn and grow from. And frankly, if I can’t articulate what’s happening in the messy middle of my process to help others, how the hell can I improve it myself?
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.
Identifying problems
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 lens on 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. Why were some stickies red? Because I could see a distinct issue emerging for a larger pain point but I hadn’t landed on how I wanted to present hierarchy yet. So red = bad.
Yep, truly giving the hot designer tips. The reason I mention it is because 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 Jobber terms or “objects”.
It’s true that most feedback would map directly to the data model we use because our customers use our platform, but there’s 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:
- Feedback grouped by issue: the longer the column, the more our customers are asking about it.
- Feedback grouped by workflow stage: in this case, we can see most feedback is around “Doing the work”
- Feedback labelled by type of concern: our team was primarily focused on communication which is identified in green bubbles so that we could easily differentiate it amongst more general feature requests or other ux issues being raised. The bubbles grew or shrank proportional to the amount of feedback.
- Feedback grouped by specific touchpoints: Many aligned to concepts within Jobber, but we could see that this got fuzzy and less defined in the “job” stage, a potential opportunity to better define this in our client portal.
Okay! We have a deliverable! That’s all fine and good. It tells us some valuable things, but mapping to feedback only gives us insight into what users are taking the time to 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:
- What is the current experience between our service providers and their clients at each touchpoint outside of the feedback?
- What parts of the Jobber system are they interacting with and what action can or cannot they take?
- What are the opportunities coming out of the pain points identified?
Understanding the whole
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 too soon, in fact I rarely do until much later in 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 product 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.
A service blueprint is a diagram that visualizes the relationships between different service components — people, props (physical or digital evidence), and processes — that are directly tied to touchpoints in a specific customer journey.
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 doubt it): I don’t really use a lot of discovery methods as prescribed. I don’t see a lot of my peers doing so either, particularly as they develop further in their career. 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, they should try their best to follow design discovery methods quite closely so they can understand 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 touchpoints 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 for 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. Totally get it, 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.
Bending the framework
I made some adjustments that essentially resulted in a franken-child between a service blueprint and a customer journey map:
- I wanted to focus on the service consumer and client relationship, essentially bucketing their experiences at the top and “UI/system” (client portal/Jobber) at the bottom.
- I identified pain points and opportunities at the bottom as a summary, but left out the emotional flow typical of a journey map, as well as the support processes that you find in a standard service blueprint.
- I added notifications and methods that happened at different stages to more easily identify lack of communication flexibility across the experience.
- I added gaps or unresolved paths of the actual experience and physical user interface in red
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.
An actual process emerges
Reflecting on this process and trying to make sense of it after the fact actually 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 do design discovery, for better or worse, it would be this:
- I never use a specific template or design method at the beginning. I find it restricts my thinking too quickly, and gets me stuck trying to fit my ideas into the tool, rather than making the tool work for the problem I want to unpack. I might have an idea of the tool that would be effective, but I hold it very loosely in my mind.
- Focusing too early on how to present the information to my peers is an easy trap to fall into as a designer, because that’s our ultimate goal. But I don’t look at how to make it understandable to others until I understand it myself. Those are two different steps of the discovery process.
- I throw out pieces of tools that don’t work for me. If I don’t think they’re communicating anything of value for the specific goal I have, I don’t want it to be a distraction or just filler to be “complete”.
- Lastly, I try my best to keep things updated. As long as I’m working in a related area, I constantly revisit these documents because we are always learning more that can impact the whole.
Thanks for sticking around for this wild discovery ride.