You can see immediately why shared understanding is different from a BDUF spec document. Spec documents are focused on what will be built and how it will be built.
Let’s examine how shared understanding might work in practice. End users request feature X. Business stakeholders agree that customer acquisition and renewal will be higher if feature X is implemented. Sales validates that the lack of feature X has killed deals. These stakeholders may even have an idea of what an implementation should look like. (“Just move this over here and add a menu.”) All of these stakeholders think they understand this feature. Yet they almost certainly do not share the same understanding, and whatever understanding they do have is probably fairly shallow.
UX needs to process this input and come up with a user experience hypothesis for implementing the feature. The UX team then needs to communicate this back to the business stakeholders to make sure it meets their needs and to test the hypothesis with end users. You can use any appropriate artifact for this communication and testing: sketches, prototypes, written documentation, code, Photoshop or Play-Doh. The key is that you can effectively communicate your idea. (I prefer interactive prototypes for reasons I’ll discuss below.)
Once you have a design hypothesis, with whom do you share it? In an ideal situation, everyone. The first group I would bring on board would be engineering. They can tell you if it’s feasible, consistent, difficult, whether there are alternative solutions that would require less effort. In addition to the valuable feedback you’ll get from developers, this is also your opportunity to help them understand what’s being proposed and why it’s important. This understanding will help them during development.
After engineering, run your proposed solution by the business stakeholders, or at least a representative or proxy for the business stakeholders. After all, if your solution doesn’t solve their problem, there isn’t much use testing it with end users.
Then you go to end users. If they validate your hypothesis, you can then create whatever formal artifacts you need to get the feature implemented – user stories, wireframes, prototypes, or more formal documentation. My preferred artifacts for passing user stories off to development are user stories with associated prototypes. If you’ve been collaborating with engineering on the development of the prototypes, you’re halfway home. You’re creating documentation solely for the purpose of communicating to your developers and other stakeholders.
Interactive prototypes are the best way to communicate your design hypothesis to all parties. Sketches work well for some processes, such as when you’re in the same room discussing them. But there is one key ingredient to effective collaboration that makes prototypes the best option: engagement. You have to get your stakeholders engaged.
One of the problems we always run into with BDUF spec docs is that key stakeholders don’t engage with them. Yes, they’ll sign off, but let’s face it, no one can understand them. People like to play, experience, react. In terms of getting engagement, your best option is actual working software. Next is an interactive prototype, next is design comps, then wireframes, then sketches, with written documentation bringing up the rear. Here’s the thing though: just because written documentation is the least engaging doesn’t mean you’ll never use it. All of these techniques have a place. I find that prototyping has the right payoff most often – significantly faster than working software, significantly more engaging than other visual artifacts. (You might expect me to say that since at ProtoShare we build prototyping software, but try it for yourself, and you’ll find the right balance among the tools in your toolset.)
Shared understanding of what you’re building and why is a simple concept. It’s part of the power of Lean UX and Agile development. While shared understanding is more baked into these methodologies, it’s a pretty simple principle that you can use in virtually any organization to improve your development efforts. Find ways to keep your stakeholders engaged. Share information early. Listen to feedback.
Thumbnail image CC by Kris Hoet