There’s a lot of people out there, myself very much included, talking about what Blueprint does. We preach faster output, less rework, so on and so forth. That’s all cool and they’re great if you’re playing buzzword bingo, but I’ve been realizing that at least for me, that’s not the most interesting part. The interesting part is how it has changed the way people work together.
I’m in year 13 in this business, and I’ve come to see that for the most part, organizations have been in the same type of cycle. Business tells analysts what they need, analysts write it down, architects design it, developers build it, and round and round we go. By the time something finally ships, the business is upset because they claim it isn’t quite what they asked for. I’ve talked in prior posts about this dilemma and how every handoff loses something, so I won’t belabor the point.
I used to feel that this friction was just part of the job. But then as I paid more attention to the companies and teams getting good results with Blueprint I realized that they’re doing something different. Rather than using it as a business tool or tech tool, they’re using it as a reason to sit in the same room and hash things out together.
What I see happening a lot now is pair design, where (at least) two people from different backgrounds (usually a business SME and a designer) sit down and build a Blueprint together instead of playing phone tag (really more like email tag or IM tag, we need a newer name for this) with documents or ideas. It isn’t a new concept in and of itself, in fact it’s been referred to as Pair Design for about 30 years now, but it’s fun seeing how it evolves.
If I don’t give some examples here you’re probably going to stop paying attention so here you go. A claims manager was talking with a designer about the intake part of a claims process (where it all begins, for those of you outside of the claims world), and the designer was building in Blueprint in real-time, right in front of them. A few minutes into the conversation the manager says “Wait hold on, that’s wrong. If there are claims from an organization with more than 2,000 employees it gets routed to a different team, and they need to be reviewed by a nurse.” This wasn’t in the original requirements but that’s not a big deal, because the designer is Blueprinting right in front of the manager, so they overcome obstacles right then and there and can even preview how that will look and act.
Another example is in onboarding. A team of onboarding agents start describing one process, but 20 minutes later someone’s like “this should probably be 5 different paths depending on benefit type”. When everyone’s staring at the same thing instead of forwarding emails back and forth, that conversation happens day 1 instead of week 3.
Now looking at the other side of the equation, if you get a developer in the room they will ask completely different questions. Developers ask questions nobody else thinks to ask. “Do we already have a case type for this?” “We built this for someone else last year, right?” “Why are we building an integration to this system when it already exists in this other application?”
To the reader that doesn’t live my life, those may seem like deeply technical questions…they’re not. They’re design questions, and you’ll save a ton of time by asking those questions when the design is in a Blueprint instead of when the application is half-written.
You could be mid-Blueprint and realize you were about to rebuild something another business unit had already done, and only the developer knew it, because the business units unfortunately still operate as independent silos. One conversation will save them weeks, all thanks to the developer in the room.
Speaking of developers, most won’t ship code without some sort of code review. But what’s odd is that there’s not always a design review. These major decisions happen without anyone challenging them. Enter the concept of a Blueprint review, where a bad assumption can be caught early. I also live in reality though and understand that this doesn’t work everywhere. Distributed teams are harder, some organizations have too much political friction…but when it works, it’s fantastic.
Long story long, the groups that are killing it with Blueprint aren’t the ones with the deepest pockets. They’re the ones who figured out how to get business and tech in a room together earlier. It’s not rocket science. Most project failures are alignment failures, not technical ones, and Blueprint gives you the best way to catch that sooner.
Look, if you’ve made it this far, thanks for sticking with me. But I’m curious as to how this is playing out on your end. Are you guys doing pair design with your teams? Are you running Blueprint reviews? Or is this still pie-in-the-sky theoretical where you work?
What’s working? What’s broken? I’d rather hear about the stuff that didn’t work than the success stories (but I’ll gladly take both).