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:
Could you share your process of how you broke down the complexity of [X]?
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.
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 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:
- 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 touch points: 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! 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:
- 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 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.
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 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.
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 system below.
- I identified pain points and opportunities as a summary at the bottom, 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 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:
- 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 the area, I constantly revisit these documents because we are always learning more that can impact the whole.