That’s pretty straightforward to grasp and most of us would understand it intuitively. But communication itself is complicated since we all engage in multiple communication styles, types and have preferences for each. Some prefer email or telephone or face-to-face meetings whereas others may prefer Skype or Facetime. Some are not that keen on constant communication at all whilst others expect daily updates. Couple this huge diversity of approach with a complex project like web design and it’s easy to see how such projects can go off the rails.
When we think of communication we tend to think of ‘transmission’ rather than ‘reception’. By this, we mean that we more readily think of communication as the act of transmitting information and less about how it will be received. However, how communication is received is crucial to its overall success and whether it ultimately has any value or meaning. This is especially true of communication in technical projects where a failure in understanding can result in a failure in functionality or, at its worst, a complete failure of the project.
Imagine broadcasting the momentous moon landing only to find that everyone’s TV antennae are facing in the wrong direction. To the broadcaster, it’s a total success: What was communicated was of high quality, interesting and of great importance. However, because there’s no feedback on how well it was received there is no proof the communication was received, understood and appreciated.
Human nature does not make us check that communication was received and understood every time we communicate. (We just assume that the email has reached our recipient’s inbox, or that someone listened and understood what we said, for example.)
Not realising this tripped us up some years ago. We were involved with a large project and as part of the specification process, we wrote a very lengthy specification document detailing how the system was to work. We were quite proud of this extremely thorough and noteworthy tome. It was technical, weighty and detailed. What we didn’t realise was that our customer also thought it was technical, weighty and detailed and, for those reasons, didn’t read it (unbeknownst to us).
The specification was signed off and we began the build. Then after delivering the project, we started to realise that there was a gap between our customer’s expectation of how things were to work and what we had actually delivered. Surely there was a way of improving this?
It was a learning experience for us. We realised that we had communicated something in such a way as to guarantee that our customer wasn’t receptive to it. What we should have done is understood that they preferred face-to-face meetings and adjusted our content so it could be presented to them in a meeting and signed off the project a chunk at a time.
Hindsight tells us how we should have done it (doesn’t it always?) but the truth is no-one ever states upfront their preferred method for receiving communication. We’ve never heard anyone say: “I understand things best when I receive information by email” or “Hey, I only really pay attention to stuff when it’s spoken to me”. People muddle through and the communicator has to guess how best to handle them.
Yet if we knew that someone was blind we wouldn’t send them a printed book to read we choose a braille version or an audiobook. If we knew someone was dyslexic we might choose to verbal communication more often or use a dyslexic font when we wrote to them. If someone were deaf we wouldn’t use the telephone. These would be natural communication choices but when there aren’t clear indicators about how we should behave we choose to communicate in the method which suits us best as ‘transmitters’ and not what’s best for our recipient.
There are hundreds (possibly thousands) of communications that take place during web design projects.
There are hundreds (possibly thousands) of communications that take place during web design projects. Often there is no proof that messages have been received and understood until a problem occurs. ‘Problem’ equates to scope creep, inaccurate functionality builds, missed deadlines, crossed-lines and general project ‘fatigue’.
The solution is actually quite simple: Each contributor on the project describes their preferred method of reception and any communicator acknowledges that and does their best to communicate using the preferred method.
Whenever we start a new project we ask the question “What’s the best type of communication we can have with you?”. This has led to all sorts of changes to how we’ve communicated and frees us up to be creative in our approach. For example,
- One customer found it best to see their designs on foam-board and wanted us to talk through our technical notes.
- Another customer-preferred us to screen-share the wireframe and a demo version of Proteus (our Content Management System) so they could see how they would edit parts of their website.
- And another wrote copious notes to us, so we wrote copious notes back.
Every time we’ve asked the question we’ve got subtlety different responses that have enabled us to run ever smoother projects. But one of the most unexpected outcomes was that if people feel they can easily understand something they ask more questions. The more questions they ask, the better the results (but more on that another time).
Hope you enjoyed reading this but if you’d prefer to absorb it in a different way drop us a line. :)