Communication within projects or: the broken telephone game

Communication within projects or: the broken telephone game

words

This is not specific to UX projects, but I guess to all kind of interdisciplinary workflows. As soon as people with different skills, different backgrounds and different mindsets come together, we need to be careful about that thing called “communication”. Statements, conversations, discussions that seem to be clear and understood by everybody can easily lead to chaos and big misunderstandings. Why?

Everybody is touching the big elephant and “sees” something different in the same thing.

There is another reason: information is often transported from one person to another. And while the information is being passed around, it changes slightely. Just like it happens in the broken telephone game. One person gathers the requirements, hands them over to the interaction designer (in a list or as use cases), that person interprets the listed items and creates wireframes, hands them over to the developer, who builds a product based on what he sees in the wireframes…

There is a lot of room for misunderstandings and loss of information. Martin Crisp summarizes that problem beautifully in his article on UXmagazine.

And he comes up with solutions for this communication trap:

  • Interview the customer with cross discipline teams
  • Combine and evolve use cases, UI mockups and UI storyboards into an integrated deliverable
  • Write use cases and storyboards with testing in mind
I agree to his points. I am a big fan of collaborative work and knowledge sharing through the process.
But even if a cross discipline team is involved from the very beginning, how do you make sure that everybody gets the same understanding?
So I think it’s not only about talking to each other and working collaboratively. It’s very much about involvement: people need to get the feeling that they are “part of the whole”. Everybody in the project team needs to be informed about the big picture – and the main decisions that happend on the way to make that picture become reality.
I like Martin’s idea of an integrated deliverable very much. That deliverable should also show the “formation”, the main decisions and its reasons, that the project team has agreed on so far.
Barnabas Nagy has come up with a great idea of how to take different deliverables and combine them to a “flow”, a set of artifacts, that summarizes the process: User Flow/ User Journey.

I want to experiment further with that idea and create integrated documentations of the (decision) process, that transports the formation and development in a comprehensive way to avoid misunderstandings and information loss.

If anybody has ideas or works on something similar: feel free to share your experiences and thoughts.

Leave A Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.