Attaining a Collaborative Shared Understanding

For a design, it’s a long journey from the first idea through the final implementation, involving many people along the way. Ensuring each person shares the same understanding about how that design should turn out is one of the biggest challenges we face.

I remember seeing an architect who talked about his best projects. When he walked through the finished building for the first time, he said it felt completely familiar because it matched exactly what he’d imagined years before. His intention had made it all the way through the implementation process.

Seeing our designs rendered exactly as we imagined them is exciting. It’s frustrating when our designs aren’t implemented the way we were thinking.

As we study what makes design teams successful, shared understanding keeps bubbling up to the top of our list. Teams that attain a shared understanding are far more likely to get a great design than those teams who fail to develop a common perception of the project’s goals and outcome.

While this seems obvious, many design processes don’t have an explicit goal of developing and maintaining a shared understanding. It’s almost as if the team members assume it will happen. Often just pointing this out to the team can cause change, at least temporarily. (It’s easy to fall back into old habits if you’re not careful.)

Even when the team has a goal of attaining a shared understanding, we’ve found there are two opposing approaches, which we call contractual understanding and collaborative understanding.

Contractual Shared Understanding

For many years, user experience designers relied on wireframes, design guidelines, and user interface specifications to express their intention. They created these thick, mind-deadening tomes with the intention of communicating every little design detail.

The point of these documents is to separate out the design portion from the implementation, creating a recipe, as it were, to be cooked. The more specific the recipe, the more likely the dish turns out correctly.

These documents become the contract between the design and implementation teams. The designers say what they want, and the implementors agree to deliver that. It’s a negotiated process, resulting in what everyone would like to believe is a rock-solid agreement.

The contractual approach has a huge advantage when it comes to predicting the design result and estimating the work involved. Experienced developers can accurately budget the cost and schedule the activities for every element in the specification. Management is happy because they know what to expect and when to expect it.

Unfortunately, lawyer-like precision comes at a price. First, documents like these take a long time to create. Though modern tools let us produce specifications faster than ever, with graphical annotations that make it simpler to explain the subtleties of the design, the result still takes time. Nailing every detail across the design is hard.

Leaving a detail open to interpretation causes the potential for a mismatch between the design team’s intentions and the implementation team’s results. Teams choosing the contractual understanding approach learn to increase specificity, which slows down how fast they can produce new features and ideas.

Additionally, a static document for an interactive experience is substandard. We’re using words to express behavior — something that’s very difficult. Talking about design is like performing an interpretive dance about architecture.

Another big problem with the contractual approach is its inflexibility to adapt to anything that pops up once the design is committed and agreed upon. If something changes in the environment or the team learns something new about the constraints or needs of the users, it’s hard to retrofit the documents and go through the agreement process again.

With the contractual approach, there are three possible outcomes to the implemented design. Ideally, the design works great for the user. Alternatively, it doesn’t work because the implementers didn’t follow the contracts correctly. Or it doesn’t work because, even though it was implemented perfectly, it was the wrong design for the users’ objectives. It’s the latter two outcomes we see most often due to the inflexibility of this approach.

Collaborative Shared Understanding

Contracts are about the letter, not the spirit. In a collaborative approach to shared understanding, you focus much more on the spirit of what the team intends.

Here the techniques are not about documentation and agreement. They are about exploration, experimentation, and, dare we say, enlightenment. What we’re trying to do is get to a point where we have an epiphany about the design — a revelation that makes everything clear.

We can see this emerge in two techniques of collaboration: prototyping and paired design.

Prototyping

In prototyping, we take ideas and render them, bringing the concepts to the forefront with the baggage of detailed implementation. The simplest form of prototyping is the sketch. Whether on paper or a whiteboard, an animated discussion in front of a sketch brings new life to ideas. In some ways, the scrawls summon spirits into the room that give everyone a deeper understanding.

For years, we taught teams how to use paper prototyping. With the entire team around the design, a user can move through tasks and activities. We love this technique for interaction design because so much of the subtleties of interaction can emerge in the representations of paper.

And it’s fast. Really fast. Working together, a team can create a complicated set of interactions in mere minutes.

This means the entire team, not just the skilled designers contribute to the construction. There’s something about tactile manipulation that speeds understanding, so the act of building the paper prototype contributes to the shared understanding almost as much as seeing the final prototype in action.

Paired Design

With the advent of easy-to-use front-end components, JavaScript libraries, web application frameworks, and prototyping applications teams can quickly render working digital versions of their ideas. Even clickable PDFs give a sense of reality that helps the team understand what they are trying to build.

While pre-made plugins and built-in operators make many interactions easy to produce, sometimes it takes advanced programming skills to see how a complex interaction will really work. This is where paired design comes in.

In paired design, a designer is paired up with a developer. They sit together and work on the design in parallel. The designer is constantly showing sketches to the developer, who is working quickly to realize those ideas in code. The code is messy and not at all the quality necessary for release, but does the job of getting the ideas in front of everyone.

The result of paired design is a level of communication about the intention that goes beyond what shows up in the prototype. Later, when the developer is working on details without the designer, they’ll have enough understanding of the spirit of the design to make great decisions.

There are two big downsides to the collaborative approach of shared understanding. First, it’s hard to predict what will be built and how long it will take, due to the iterative nature of the design process. Teams used to the clean estimation process of a contractual approach have trouble transitioning to a collaborative approach when they can’t easily estimate resources and costs. (For some business models, like agency-based design where a price needs to be established with the client up front, this makes a collaborative almost impossible.)

Second, the collaborative approach is intensely intimate over a long period of time. For it to be successful, designers and developers need to work in close quarters, surrounding themselves with the work in progress. This is very hard for remote teams who don’t have the luxury of being co-located for the duration of the project.

Right now, our research shows that, despite these constraints, it’s easier to produce great designs using a collaborative approach to attain shared understanding. If you really want to produce great designs, structuring your teams to work in this fashion, paying close attention to what everyone understands, is the best way to get there.

Originally published on UIE.com

Creating a design squad to build demo prototypes and pairing designers with developers are two of different strategies we discuss in our Creating A UX Strategy Playbook workshop. Learn how to bring your teams together with strategies picked specifically for your organization.

Join us for our 2-day workshop and help bring shared understanding to your team, problems, and designs. Look over our 2-day workshop agenda at Playbook.UIE.com.