It can take professionals a few years to find their voice. Younger developers often don’t have the experience or the confidence to speak at a conference, let alone guide a room of stakeholders through the complex process of building an application. Developing a communication style in which you can be comfortable and confident can take years. Recently, a project reminded me that sometimes success has little to do with our voice and everything to do with the voices of the people we’re working with.
As a UX practitioner concerned with the quality of everything delivered by any team I’m on, I wear many hats. Many of those hats are defined by communication. The best work often comes from the best teams, because without strong communication, details inevitably get missed. I regularly wear the hat of a translator in meetings and workshops, working to make sure everyone is on the same page. My best tools are images (often sketchnotes), because they are quick and leave little room for ambiguity, but it is not always about what I can bring to the table.
Success hinges on understanding the language everyone else is speaking.
If we struggle to pull information from our subject matter experts or misinterpret what they share, the project might never get off the ground. Our output can only be as good as what we input.
Early in that recent project, our team prepared to communicate from three angles: words, maps, and wireframes. Our words were a document describing our understanding of the business and our solutions to the problems outlined at the outset of the project. Our maps communicated the breadth, depth, and flow of the solution. Our wireframes communicated the details and actions available on each screen. The business people and technology managers I have worked with often gravitate towards words, because that is where they are most comfortable. Our project team was shocked when this client patently ignored the words and the maps. Obviously, we had found their language.
I was happy. Communication was quick and clear. All of the work I had to do back at my desk was already in the format I needed it to be in. I was unconcerned about missing steps or key conversations that usually happen alongside the words and maps we typically use, as long as we walked through every facet of the application in the wireframes.
But this focus on wireframes caused a deficit elsewhere and as we began to wrap up our documentation, we had to close those gaps.
Our team was able to deliver good work, because we followed through to get the details right. As soon as we realized that quality review of the other material wasn’t going to happen, we had a team meeting in which we made sure we had a clear view of the things that had to happen to deliver good results. We were able to use the strength and experience of our team to close those gaps. It was good experience and a great reminder.
Consider the language your clients or project teams are speaking and make sure you can identify when they’re not able to communicate. Maybe you haven’t given them the tools they need to contribute to the discussion or provide good feedback.
Maybe you’re just not speaking their language yet.