Architecting a System of Effective Communication

It’s a time-honored test: Do you see a rabbit or a duck? Some see one, some see the other, some see both alternatively.

Source

Perception is the underlying theme here. Seeing a problem from one point of view doesn’t mean that other points of view are incorrect. As long as both parties always assume positive intent, the project outcome is attainable, despite how you get there.

Experience designers and software architects by nature have different worldviews and priorities, and often are the two critical stakeholder groups behind getting a project off the ground and completed successfully. In order to produce consistent, timely, and impactful outcomes on projects, it’s important to have a system in place for effective communication.

I, along with Seth Dobbs, HS2’s VP of Engineering, presented on how to architect a system of effective communication at the IA Summit in Chicago in March 2018. Drawing from our own experiences driving HS2’s design and development practices, we know that figuring out the ideal experience for the user isn’t always easy. By creating a standardized vocabulary and culture of inquiry between both competencies, we’ve found a way to bring the complexity together and make it work.

Communication Ground Rules

Much like defining parameters for what a project’s success looks like at the onset, establishing some communication ground rules in a project’s early stages can create an environment that fosters inquiry. One key tenet to keep in mind during laying this foundation is that communication goes both ways. Communication should have a goal and purpose - and not just be speaking to make sound.

“The ability to listen is as important as the ability to speak. Miscommunication is always a two way street.” - Sheryl Sandberg, Lean In: Women, Work, and the Will to Lead

In order to communicate the right message, it’s the listener’s job to participate in active listening and replay what they heard back to the person directing the communication. For example, you could say, “I see that you see it X way. Tell me a bit more about that.”

Seth shared a similar takeaway in his presentation from the O’Reilly Software Architecture Conference, specifically about the power of the read back.

Conflict Isn’t Inherently Bad

Whether it’s overcoming a challenge related to coding or a customized wireframe, designers and developers want the same thing - to deliver a successful product. It’s about what you do once you discover it. At HS2, our main form of communication is inquiry.

We approach design thinking by focusing on three domains: business, technology, and human. The goal of human centric problem solving is to balance these three points of view by building something that humans want, that is technically feasible, and that is viable for the business. We’ve learned that the different groups will want to pull people into their circle which can create friction. We instead try to use inquiry to help drive each other to the best balance in order to create the best results.

Don’t Fall for the Illusion of Communication

In lines of communication, there are two types of disconnection between parties: actual disconnect and perceived disconnect. When both actual disconnect and perceived disconnect are obviously present, a discussion can prove extremely helpful.

When there’s perceived disconnect, clarification is a great tactic to employ. Take time to slow down and try a line such as, “I think we’re saying the same thing.” This is an opportunity for both sides to discover new vocabulary.

It takes hard work to have a highly functioning team. But that doesn’t mean that highly functioning teams don’t ever have disconnects. Rather, good communication moves quickly to shift to an aligned team in order to squash any illusion of communication. Consider the following types of illusions and questions you can ask yourself:

Types of Illusions                                        

Questions You Can Ask Yourself

I told them that.

Did you message get effectively transmitted to your audience?

It was in an email.

Did you verify your message was understood?

They were in the room when it was discussed.

Are you taking ownership for the success of the communication?

It’s on the Intranet/SharePoint/DropBox, I gave them a link to the wires, etc.

Did you confirm that the other person agreed to the same thing you think they agreed to?

They said they could do it.

Do all necessary parties have the same shared understanding?

                                                                                                                

Creating the Right Environment for Good Communication

Seth and I don’t always agree, but we communicate with purpose and the end-goal in mind. We know that success or failure is a team outcome.

At the end of the day, communication is a learned skill that requires practice. With practice, projects can be run smoother from the get go and more efficiently realized.

 

Share This

About the Author:

Amanda is the VP of Experience Design. She likes to understand problems, identify patterns, overcome obstacles, design solutions, test hypotheses, and create amazing digital products. In short, she figures stuff out and makes it awesome.