What’s in a name? Would a service blueprint by any other name work as well? These days, designers and product managers alike have plenty of frameworks to choose from when visualizing processes. Does it matter which one you choose?
“Process mapping” is exactly what it sounds like — mapping out workflows (whether they be user, business, or technical) that underlie the customer experience. Process mapping is both a powerful communication tool, and a great way to identify experience gaps for customers, employees, and partners alike.
I am intentionally using the word “process mapping”, and not “journey mapping”, “service blueprinting”, “architecture diagramming”, or even the non-offensive “flowcharting” because I often find that none of those prescribed formats usually gets at the full picture of what I want my audience to know. “Process mapping” is just a catchall phrase for the above frameworks, and more.
In short, it doesn’t matter what framework you use as long as you are designing for your audience. At the end of the day, you want to produce an artifact that is used by your cross-functional team — not stowed on a digital shelf. So don’t be afraid that you’re “doing it wrong” — start with a few templates, then Frankenstein the pieces you need together to create a framework that’s right for your team.
In my experience, journey mapping often focuses too exclusively on the customer, while blueprinting focuses mainly on the business-to-consumer touch-points. Don’t get me wrong, both are amazing tools. And as NNG points out, these two frameworks are best used in tandem. But while both frameworks together communicate the business and consumer needs, they neglect (or at least, de-emphasize) the technical layer that can have an equally great impact on the user experience.
My end-game is always to produce a mapping mashup that both developers and business stakeholders alike can reference to have a clear picture of what is happening at every level. But again, no two audiences are the same. Knowing who you’re talking to will help determine the scope of your artifact.
At the beginning of your journey, you’ll feel more like a historian or an investigative reporter than a designer. Start by interviewing the stakeholders and partners needed to build out your ideal process map. This should include product managers, engineers, product marketers, and customer care representatives at minimum. The archeological digging will pay off in two ways: 1) You’ll learn so much more about how your product or company works, and 2) You’ll be able to start laying down some swim-lanes and boxes without holding a 20-person inter-organizational meeting.
The reason I advocate for some initial heavy-lifting on the designer for this effort stems from efficiency as well as empathy: the only person who fears a blank canvas more than a designer, is a non-designer. And that is exactly whose help you will need in order to create this thing. Throw your stakeholders a bone by doing the leg work to collect the information and build an MVP flow ahead of time, before ever hosting a workshop.
As with user testing, it’s easier to give people something to react to than to hand them a pen and say, “tell me how you want it to look.”
Once you have something for an audience to react to, then you can bring cross-functional partners together to review, refine, and identify opportunities. NNG has great additional resources that address fails and fixes for this process.
Warning: this workshop will get messy, and you will get some things wrong. If you’ve created a flow diagram with connected boxes and arrows, editing them on the fly is going to cause some major nervous sweats. I would recommend writing the adjustments you need to make on sticky notes (either digital or physical) and then set aside some time to make the edits later, after the meeting.
The most difficult part of this process is doing something with the opportunities you identify. It is easy to point out experience pitfalls, places to improve the customer communications, or technology stacks that you should replace, but it is much harder to actually do those things.
Process mapping can catalyze stakeholders to actually want to make changes once everything is laid out clearly in front of them. Much like data visualization is useful for revealing insights in big data, process mapping can reveal insights in big companies. In today’s world, there is growing complexity that comes from increasing integration and collaboration. If we don’t lay it out in a way that makes sense, we’ll never get the chance to be told what we can’t do (and then find a way to do it anyway).
- LucidChart my is a personal favorite because of its flexibility and share-ability
- Omnigraffle is a classic for information architecture and flow diagrams
- Overflow.io is great for UI heavy flows (not as much for process)
- Or go analog: sticky notes and pens also work!