Creating a Shared Understanding

Creating a shared understanding among stakeholders is crucial and that UX is really the best-positioned team to facilitate this. I have a specific idea of what a shared understanding means. Shared understanding means that everyone knows what will be built and why it will be built that way.

Collaboration for UX

Software development is a collaborative discipline, and a good UX team is the focal point of collaboration in a software development organization. In this series Andrew Mottaz explores these collaborations.

See all posts

Related posts:

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

Andrew Mottaz

Andrew Mottaz is the Founder and CTO of Site9, Inc., the maker of ProtoShare, a leading on-line tool for “collaborative prototyping.”

4 comments on this article

  1. David Hardwick on

    I whole heartily agree about doing prototypes to align everyone, that is our approach too. We do the Requirements only after the prototype and wire frames are viewed and engaged by the architect, the exec team, and (as much as we can) customers

  2. Andrew on

    Great perspective, Andrew.

    Wondering if you can chime in on the following situation: We are working with a client who has engaged a creative agency. The client and the creative agency worked together to produce designs that were subsequently signed-off on.

    As the technical agency (responsible for the technical aspects of making those designs “come-alive”), do we now go through the process of creating user stories? From my experience, user stories typically drive wireframes and design efforts. In this case, we are being handed completed designs. So what’s the best way of creating technical specs from these designs (for front-end/creative and back-end engineers)? What’s the best way to ensure that technical development activities fulfill what’s laid out in the designs?

    One approach I am considering is to have the designs annotated with interaction specifics, data sources/attributes, etc, so that the Development and QA team have a visual (rather than the typical flat user story) reference.

    Would love your thoughts.


  3. Andrew Mottaz on

    Thanks for the question — This is a really interesting, and very common scenario — development is in the dark until they get delivered an authoritative spec. Now you have the difficult task of figuring out exactly what was intended.

    If this were an issue I had, I would probably still write at least some user stories. You can write user stories quickly, and your client should be able to sign off on them just as quickly. If they can’t, then clearly the documentation they gave you isn’t adequate for you to successfully build the project. Better to learn that up front.

    I would also prototype as appropriate. The problem with the ‘frozen’ design you’ve been handed is how to handle unforeseen issues. What happens when a slight change to the design could result in huge development savings for the customer? How about when you uncover needed functionality that was missed in the flat development phase?

    The bottom line in your scenario is that the ‘shared’ aspect of shared understanding is missing. Spending some time writing user stories and/or prototyping key concepts will give your client important feedback about how you are interpreting the design documents you were given. They can correct you if you’re wrong.

    The step of creating technical specs to me comes after the user stories and prototypes. Once everyone understands what you’re trying to do, then have engineers find the best solution and adequately document tasks so that the work can be parceled out.

    Hope this helps.

  4. Pingback: It’s All About Collaboration | Wireframing Tool - ProtoShare