UIEtips: Attaining a Collaborative Shared Understanding

Jared Spool

January 18th, 2012

Sometimes, it’s easy to brand what we do as the “science of the obvious.” Here we are, doing all this research, and come up with something that is painfully obvious.

The latest of the obviously obvious findings we’ve come up with? That teams who don’t have a shared understanding of their design rarely succeed at producing a great product. See? It’s obvious.

Yet it surprises me that quite frequently the obvious is not what people do. Many teams that we’ve studied don’t pay attention to whether they have a shared understanding or not. They don’t create a process to ensure everyone is on the same page. Then they wonder why their results aren’t what they want.

In today’s UIEtips, I describe the two types of shared understanding we uncovered and how one of them is far more likely to end with a successful design. I’m betting this is an article that will create some interesting discussions amongst your team.

Read the article: Attaining a Collaborative Shared Understanding.

A collaborative shared understanding is a key component of successful Agile projects. Fortunately, on January 24, Anders Ramsay will be sharing his techniques for helping teams collaborate in his UIE Virtual Seminar, Designing with Agile. Bring your team and learn the best techniques.

Have you transitioned from a contractual approach to a collaborative approach to attaining shared understanding? We’d love to hear how it went (or is going). Leave us a note below.

3 Responses to “UIEtips: Attaining a Collaborative Shared Understanding”

  1. Jen Fabrizi Says:

    Here’s my experience: I am the lead of an internal UX research and design team. We have until very recently used a contractual – or what is really “time and materials” – job estimation approach even for embedded engagements. Because of agile’s iterative nature and the uncertainty going into an engagement of exactly what UX design tasks and deliverables will be done in which sprints/releases, I now estimate based on a completely different approach, which is analogous to a “retainer” model. Instead of estimating an engagement based on how many hours it will take to produce each deliverable, I now base the engagements on number of resources needed with specific skill sets. For example, one recent incoming engagement is going to be 50% of a UX resource with IxD/usability skills. Another project will need 2 resources with a range of strategic UX skills to integrate with product owners, as well as CSS skills. Staffing sources may include internal and external sources depending on resource skill sets and availability. It’s easier for projects to predict budget needs in some ways because the chargeback or cash flow amount stays the same per month. It seems to me this might work for consulting agency work, too, but I’m not sure. In any case, the “retainer” engagement model definitely frees me up as an experience designer to be more flexible as I alternately influence and respond to the needs of the team and the product owner within the scrum cadence.The flip side is that I have had to become less dogmatic about the order of UX work (do I write scenarios or run a guerrilla study this sprint…?) and that’s caused me some discomfort about the degree to which I’m compromising possibly effecting the design outcomes. But the collaboration and paired work with BAs and developers is really becoming effective. Additionally, Strategic work is defined in my mind as tight integration with the product owner team, providing the potential for more strategic UX influence. I could go on more about how collaboration is now beginning to work but I’ve made this comment too long as it is!

  2. John Doe Says:

    I’m at a large organization which uses a “semi-Agile” approach but I work with two very different project leads. One strongly favors the contractual approach. He has an agency background and by personality this approach gives him more security. All the problems you noted are in evidence, the most pertinent one for me being asked to develop a very detailed wireframe and IxD document for hand-over to development…with no input from development or a formal opportunity to share the thinking with them. The other leader has a much more iterative approach and works to make sure everyone is on the same page. I thrive in this type of collaborative project and believe the document overhead is lower as well.

  3. Cam Beck Says:

    I’m not as convinced as you are that a collaborative shared understanding is impossible in an agency environment, though exactly how one might manifest itself most effectively is still a bit of a mystery.

    There are a number of things working against it, including as you mentioned the client’s need to have costs and time defined up front — not to mention the fixation on deliverables as the outcome of UX activities (all activities, really) as evidence of progress and as a draconian substitute for desired outcomes.

    I believe in most cases these challenges can be overcome, as long as a client and agency can come to an agreement about what will be jointly accomplished immediately, and what activities they will pursue after the initial launch in order to meet the objectives and outcomes they’ve collaboratively defined at the outset, for those ideas that come up in the course of design that can’t be covered within the agreed fee.

    Accomplishing this demands first a shared understanding of intent of the product overall, as well as every activity (the sum of which will be used to estimate the t&m that will be required to define, design, and produce the product).

    Our focus should be on mutually beneficial outcomes tied to desired behaviors, with a thoughtful awareness of how those two form brand perception.

    Would love to hear more from UIE on this subject in the future.

Add a Comment