Welcome to the official, first documentation of the Practical Service Blueprint process using the official Omnigraffle template! This is a method and format that has been long in the making, and I am thrilled to finally have everything in place to be able to share and teach how I have been using the Practical Service Blueprint method and create powerful, real time digital blueprints using this Omnigraffle format.
There are a lot of artifacts and methods out there for mapping experiences. I had a great need that none of what existed could meet, so I took from all around me and came up with something new. That’s what is great about design and the creative process. We don’t have to be stuck with what we’re given, and we don’t have to stay idle and hope that someone else will come up with something to solve our problems first.
As the Practical Blueprinting process was invented by adapting from multiple inspirational sources, and the Omnigraffle template is something totally new, it takes some getting used to. This guide is here to help you understand how this particular method is being used in Omnigraffle, and how you can start using it right away in the tried and true method that we’ve developed. You can replicate the method in any software, I have just found nothing nearly as capable as Omnigraffle.
If you haven’t had a chance to see the Practical Service Blueprinting Guide and the companion Facilitator Guide, I recommend you go get those right now, otherwise you might be lost on some of what I’m talking about.
This article is broken into big chunks for easier scanning or reading. I recommend reading it all the way through, as you’ll be a real master at the format if you do, but if you feel like you just want to understand certain things, you can jump around at your leisure.
Before you start, download the template files so you can follow along:
Part 1: Video Demo
This is a demonstration of using the format in action. It captures a lot of what is written here, but was designed to be under 5 minutes, with the idea that a write up (this) would accompany it. I recommend watching the video before the article.
Instructional video on this method
Part 2: First Things First, The Legend
There will be a lot of terms and visuals thrown around, so let’s start with a legend of the Practical Blueprint components and quick definitions.
Phase Indicator: Shows when a series of steps are all a part of a logical phase.
Promise and Value Indicators: Shows where a value promise is made, and where it is supposed to be realized.
Front Stage and Back Stage Step Definitions: The descriptors of each step. Light gray to match front stage backgrounds, and dark gray to match back stage backgrounds.
Blueprint Layers: The colored layers that make up the detailed, surface to core view.
Front Stage Background: The light gray column background that indicates a front stage step.
Back Stage Background: The dark gray column background that indicates a back stage step.
Part 3: The File
There are a few things you need to know about the provided template file.
How the stencil is displayed: It’s a simple thing to overlook. Make sure you are using the compact view as shown in the screenshot. It will be very confusing if that setting is not selected. If your stencil looks like the screenshot, you’re good.
The stencil in Omnigraffle
The layer icons: On each of the colored rectangles that represent the layers of the steps, there are small white icons. These are not grouped with the rectangles – they will move freely and if you drag a layer box over without selecting the icon, it won’t come along. They can be grouped if you plan on not writing more than the default 2 lines of text, but I have left them ungrouped because if you need to make a box taller to accommodate more text in each box, the icon is attached to the box it distorts it all out like you see here:
A stretched out layer icon, no good.
The way it is set up, you need to just take care to drag in the icon and box at the same time. It is a little cumbersome, but I do not know of a workaround. You can avoid this by not using icons at all and just the boxes, but the feedback from people who view and use the document is that the icons are helpful.
The Grid Settings: The grid and stencil are setup to snap in 1/12th of an inch increments. The elements in the stencil are all sized to that, and will snap quite nicely. If you start a document and it is not set to 1/12th inch increments, nothing will line up uniformly, and you’ll have to change the grid settings and line it all up by hand, and that is a real pain. So be sure to have the grid set ahead of time, or use the blank template provided.
The grid settings panel
You can turn the gridlines on or off. I prefer using turning off the major grid lines as there is no real need to see the 1 inch increments, just the sub increments.
Using Touchpoint Images: The teal touchpoint image boxes each have a transparent black box layered on top of them. These are meant to be the place you drag in external images. Omnigraffle works in a way that when you drag an image onto an object, it gets placed into the object. This makes it super easy to drag over photos, screenshots, and other visual files, and have them sized perfectly inside a box.
Dragging an image to the placeholder box. Click to animate
NOTE: When you drag in an image, it is saved inside the file. If it is a large, hi-res image, that resolution is maintained when you size it down. This means when you zoom in, either in Omnigraffle or in a PDF program, the image will be hi-res and crisp even when you zoom. Of course, this adds to the file size, which you’ll read about in the next section.
Flat File or Package: Omnigraffle has an option to save the file as a package, which is basically a zip file with a bunch of files inside, or as a flat file, which is just a single file you can’t open. There’s benefits to each, just be aware that things like Box or Github can have a hard time knowing how to sync a package file.
File save options
NOTE: If you drag in a bunch of large screenshots or images, those files are added to the Omnigraffle document – they are not externally linked. So if you add 100 one megabyte files, your Omnigraffle file will be 100 megabytes. Way too big to email. This is when Dropbox is handy, as you can just export the file as a PDF and then link to the file through a Dropbox link without having to email it around, and if you change the file and re-export, the link still works.
NOTE 2: If the PDF is larger than you like, which is can easily be when there are tons of images inside it, there is a little-known feature in the OS X Preview that lets you shrink a PDF. Go to File > Export and then in the Quartz Filter dropdown, choose “Reduce File Size.” This will compress it right down to a much, much smaller size. It uses some sort of magic, I am not sure what. Images do lose some of the resolution, but since they are just there for reference, usually it goes unnoticed.
OS X Preview app “reduce file size” setting
Part 4: Real Time Construction Process
The abridged history of this template is pretty simple. The concept behind the format started as a mix of sticky notes and digital transfer. The sticky note process became cumbersome, as well as the transfer to a digital format that happened at a separate time.
A sticky note version of the Practical Service Blueprint method
After many learnings, I started doing it digitally in real time. This is done with the Omnigraffle file projected onto 2 or 3 white 4’x8’ foamcore boards.
Using Omnigraffle on a projector for group collaboration
When you become reasonably quick with Omnigraffle, this is a very effective technique. The main
benefits to this are:
- It allows the whole group to look at a central artifact, and not be stuck at their computer screens.
- It allows people to walk up to the projection and gesture to it, as it is as larger or much larger than sticky notes would be.
- The “cinema” style workshop keeps people engaged and makes things go faster as you can all see what someone is pointing to with their hand or a laser pointer.
It is a true collaborative production. The power of active participation can’t be beat.
The text inside the elements can become quite small when you are zoomed out, so often a mid-sized TV makes things worse. Use a projector if you can.
If a huge TV or projector isn’t available, doing a screenshare where everyone looks at it on their laptops is the last resort. This is also the only way to do it with remote people as well. It definitely limits the experience, but sometimes there is nothing you can do about it.
An alternative can be doing the sessions with sticky notes, and having a scribe also be building the Omnigraffle in real time. The stencil, grid, and template you build should make this relatively easy. Make sure you have a facilitator that can allow the group to pause if the scribe falls too far behind.
NOTE: Take it from me, having done this with sticky notes and whiteboards, and tried to then digitize it into the Omnigraffle later (or any digital format) is -very- difficult, prone to error, and frustrating. Having to copy it all to a computer while the stickies are still sticking, the boards you stuck them too still up, or the walls you were using still available, is a real drag. Plus if you lose your stakeholders and need reminders, it’s hard to get follow up answers.
NOTE 2: Many have asked about other programs; Illustrator, Sketch, PowerPoint, Vizio, Axure, Excel, Google Draw, and more. If these are your preferred tools, you can recreate what I have here just by copying what you see. I’ve tried many programs that might be better at creating a visual end-result artifact, but none have the rigid features like Omnigraffle does for boxy-grid manipulation. The key to the format is the lack of flexibility. Stray at your own risk.
Part 5: The Process
Here is how I recommend using the file in the course of a blueprinting working session. You can read about the whole Practical Service Blueprinting lifecycle in the guide and facilitator addon. This article is just about the file format.
Setting up the scenarios: Before diving into a full blown working session, I recommend setting up your step definitions across the top layer first. Either yourself, or with a SME partner, should know the use case – this all assumes you’ve gone through the preparation steps and are ready to create the blueprint stubs.
Set up your columns on the column layer. You can over-estimate, I would start with 15 or 20 and see how many you use. On this layer, you will have the column backgrounds and the step numbers. This is important, you will be locking this layer later so that you can drag the other boxes around without moving the column backgrounds.
A locked background layer
Background columns set up and locked
One your columns are there, lock the layer and move to a new layer on top. Drag over the step definition boxes and fill them in as best you can. Be prepared to modify them since new details in the scenario will come up. You are just trying to get the basics fleshed out at this point.
A layer on top of the backgrounds, unlocked
Step definitions added on the upper layer, not the background layer
Once you think you have them in there, you end up with the column backgrounds and the steps all in a row. You’re ready to move forward.
Dragging Layers and Objects: Once your bottom layer is set up and step definitions added on top, you can start dragging. This part is pretty simple. Over in the stencil tray, drag your mouse and select the layer color you want and the icon in a single drag. Sometimes you will miss the icon, but that’s ok, just grab it and bring it over if you do, it will snap to the grid as it is exactly 2×2 grid squares in size. You can opt to not have the icons, but I recommend you leave them in, I have found in my useage of this format that people like them there as a guidepost.
Dragging blueprint layer from stencil to document. Click to animate
Try and stack them in the order they are in the stencil. You will definitely end up with more than 1 of the types of layers in most cases, so having it all digital makes it easy to rearrange them. From here, the process is just rinse-and-repeat, there’s not a lot of sorcery to stacking the layers. You just keep on doing it.
A fleshed out sample
In the event you want to add more detail, all you have to do is drag the box bigger. You can see by having the icon ungrouped, it stays in the top left corner like it should.
Making a blueprint layer box bigger. Click to animate
Part 6: Adding Other Elements
In addition to the fundamental column and layer pieces, there are currently 2 additional elements that add more utility to the blueprint: the phase indicator, and the value promise indicator.
The Phase Indicator: This is a simple bar that stretches across a series of steps and groups them into a logical phase. If your scenario was a purchase, install, and use, then you would have 3 phase indicator bars that stretch across the relevant steps. It’s a helpful element for a quicker mid-level view that many stakeholders prefer.
The tan phase indicator above steps
The Promise & Value Indicator: The other element is new for 2016, and that is the promise made & value realized indicator. This allows you to call out where a value promise is made in the scenario you are documenting, and when it subsequently kept or not. Even though there is a specific set of steps in the scenario where the value is supposed to be realized doesn’t mean it is; the indicator may very well call out that this step is a total failure in delivering.
This is a much more nuanced element that requires some judgement on just when it happens, and if it occurs across many steps. An arrow can show the connection between the initial promise, and the realization. There may be more than one set as well since each scenario may be making multiple promises and realizing value in multiple places.
The promise indicator in red, the value realized indicator in orange
Take a step back and analyze your scenario once it has been fleshed out, and you and your stakeholders can look at it end to end and ask “where is the value realized?” Usually there is a crucial set of steps that are the only actual parts that realize the value you’re trying to create, the rest are just pathways to or from it. In the case of an on-demand car service, you could say the value is realized when you are dropped off; not the ability to call the car from an app, not when you are picked up, and not when you are riding. You could consider the pickup as the promise being “you will be taken to your destination quickly, politely, and with minimal hassle.” Once the passenger is dropped off, the value is realized if those conditions are met.
A promise of value might have multiple criteria to be noted as well, to indicate if there is a partial failure in delivery. If in the example above, a ride was supposed to be quick, polite, and with minimal hassle. In a scenario you are trying to fix, the “quick” aspect might be missing, say in the case of when the service is used in very bad weather.
The promise and value indicators are a new features to the Practical Blueprint and still under iteration, so feel free to experiment and send in feedback.
The Branch Indicator: There is one other indicator which is a blueprint layer like the other boxes, I call the branch indicator. This is a pointer that guides people to other blueprints when you want to indicate a branch without having to break up the current blueprint. Since this format is not well suited for visualizing large branching trees, this element gives you a way to say “at this point, there is a branch that can be located in another blueprint.” It is not meant to act as an actual visual branch in each blueprint.
Rearranging: Once you’re in a groove, you’ll be adding and arranging lots of boxes. I recommend keeping them in the layer order, so you’ll have many of the same color stacked together. Using the grid makes this easy. You might have to move some around off to the side to make room, then just move them back. Be sure you leave the column background layer locked so you don’t end up dragging around the layers as well.
Part 7: Doing Multiple Blueprints
If you are going to be doing multiple blueprints, likely they are around the same set of scenarios. If this is the case, you can reuse sections by simply copying and pasting them from one canvas to the other, as standardized processes are probably not too different from scenario to scenario if they’re all rooted in the same place. For instance, if you have 5 scenarios that all start with “the customer walks up and opens the door” (simplified example), just copy and paste those steps, and only map out the new deltas.
This will let you share or print the different scenarios easily without having to manually recreated parts that are near identical.
Part 8: The Question of Looping or Cyclic Scenarios
Aside from the format usage, this is the second-most asked question. “How do you show things that loop around in a cycle?
The purpose of this format is to show a scenario as it plays out from the perspective of a linear timeline – a specific linear story. If you have a loop or cycle, even though conceptually they are loops to us as the outside observer, to anyone who goes through it, it is still a linear journey.
This means that if you have distinct and different scenarios that go through a loop or cycle multiple times, those would be different scenarios in different blueprints. This might feel redundant, but the key here is to remember the format is meant to show scenarios that happen over time so you can attack the scenarios, not a view of a process and all its options at once.
If there is a “loop”, think of it like riding a carousel – on your first try, you might have gone around once. On another try, you might have gone around 3 times. On yet another, 10 times. Even though from the outside we say “people can go on the carousel an almost endless amount of times, how do we show that the carousel is a variable?”, you still treat each scenario as a story.
In this case, you would have 3 blueprints. One where a customer goes around once, another where a customer goes around 3 times, and a final one where the customer goes around 10 times. Most of these will have redundant steps that can be copied. The first part and the end part are probably the same. It’s the middle that is different. Even though they look like loops to you, they are still individual scenarios for the customer – people can’t experience more than one experience simultaneously, that would break the laws of physics (unless you count quantum physics).
If you have so many scenarios to document because your looping is so out of control, you might want to take a step back and analyze everything leading up to the need to have so many looping permutations, and if you can solve things farther upstream so that the blueprint doesn’t need to account for so many divergent paths. But that’s a topic that strays pretty far from how to use the Omnigraffle template.
Go forth and blueprint, practically!
I hope you enjoyed our time here together today. Both myself and Megan have put a great deal of time into this format and process over the last 2 years, as well as others who have used it and contributed ideas and critiques back to continually improve it.
I have found the format to be exceptionally useful and have had many successes with it in my real-world applications. I hope that the format can continue to grow and become one of the standards in any service or experience designers toolbox.
Take the format and use it, improve upon it, or find its flaws and shortcomings and fire back your criticism. It’s a document and process in constant evolution, and it can only get better by using feedback from the community!