Skip to main content
All Posts
Strategy

4 Essentials of Cross-Discipline Communication

When you work in a digital agency, you’re often put in the position of needing to work with someone whose area of expertise is very different from your own. You’re tasked with solving all sorts of problems, and often the people bringing these problems to your attention will choose to use words that are very different from the words you would have chosen to describe that same problem–if you can even figure out what their actual problem is. There are times when one simple request becomes a confusing mess of miscommunication because no one can agree upon what to call “the thing on the page that asks the user to do something” (we like to call it the “Call to Action”).

To avoid the vast majority of the headaches that spring up due to poor communication, here are a few guidelines I’ve tried to follow that have worked wonders for our teams:

Start with Why

The most important rule of problem-solving is “know the problem you’re trying to solve.” Most of the time the problem we think we’re having isn’t really our issue at all; It’s merely a symptom. It’s amazing the effect simply asking “why” can have.

When developing applications, before we begin designing or building any part of it, we first like to figure out what we’re gonna be designing or building. Often this figuring is done in the form of something we call “user stories”, where we write a list of product requirements from the perspective of the people who will ultimately be using it. These stories follow a very formulaic structure

  1. User: As a user,
  2. Feature: I would like to do a thin
  3. Reason: So that my goals are met

It can be tempting to spend a lot of time defining the user and listing off all the things they want to do without taking the time to focus on the reason for each feature. Defining users can be fun and listing features can feel easy, but figuring out the why is hard.

I remember sitting in a meeting once where my impatience kept getting the better of me. I felt like we were wasting time having to continually come up with the “why” for all these features; the reasons for the features were “obvious”. Then we listed a feature I’d been certain was absolutely necessary, and when they asked me to give them the reason, it turned out to be the exact same reason a feature we’d already listed was already addressing. So we combined those two features into one, and just like that, my complaints stopped.

Asking why saves time, money, headaches, and arguments. It lets us avoid the whole back and forth of “no, I know that’s what I said, but that’s not what I wanted.” And that’s a win for everyone.

Agree on a Label

The more I’ve worked with people across different fields, the more I’ve realized people tend to run into similar sorts of problems. But because they call it different words and they use different terminology, it’s hard for them to communicate with each other. Half the time they’re not even aware they’re working toward similar solutions.

The truth is multiple words often work for the same thing. Pick one. Just one. And use that. When one person is calling it a “Splash banner”, one person is calling it “the header section”, and another is calling it a “hero banner”, it can become very difficult to know what you’re referencing. So much time is lost just because we each have different words for the same thing. Sure, they all work. Most of them are probably even accurate. But it doesn’t help anyone if no one knows what anyone is talking about.

A part of our development process used to involve me reviewing a set of designs, finding everything that looked like it could work as a duplicatable component, then working with the dev team to figure out what to call that component. On every project. Then we’d build the product and use whatever (somewhat arbitrary) label we’d picked for that component in our instructions for how to use what we built. Every time our QA team would work on the site, they’d always come to us with questions, and usually, they’d include a request to change that label we’d (somewhat arbitrarily) picked. I’d like to say these questions and requests were met with understanding and empathy on the part of the developers, but then no one in the company would let me post this article because it would be a flat-out lie.

In my head, we’d spent a lot of time trying to figure out what to call that stinking label (no thanks to them!), arbitrary or not. Didn’t matter that their suggestions might have made more sense, it was the “principle of the thing” (read: it was my pride). I grumbled to myself and to my fellow devs, “If they’d told us what to call it going into development, we could have avoided the time we spent coming up with the name and the time we’re gonna spend changing it.”  And then it hit me: why don’t we ask them before going into development? So we did. Not only did it help us avoid the (or my) grumblings, it also cut back immensely on the questions and change requests later on in the process.

In short, pick a label. And stick to it.

Document It

Turns out languages change over time. Like, a lot. Writing it down is vital to preservation.

You could come up with the best library of names and rules and definitions on the planet, but it doesn’t matter if it’s not written down somewhere everyone can see it. And easily use it. Easy to use is key. I can’t tell you the number of times I’ve had the “super productive meeting” where we’d finally agree on a name, or an approach, or a process. Everyone would walk away from it feeling great and confident, and we even took notes and saved it somewhere in the team’s shared documentation space. Yet, fast forward two or three months and nothing’s changed. We’re still in some sort of chaotic limbo of not knowing what our “official” names and processes are. Why? Because we took notes and saved it “somewhere” in the shared space.

If you want your documentation to do its job of preserving information and making our lives at least slightly less confusing, it can’t be confusing. Make sure it’s easy to read and easy to find.

Be Patient

Perhaps the hardest lesson for me personally to learn, effectively communicating with other people can take time. Sometimes getting to the root of a problem takes longer than we’d like. Sometimes getting other people to understand the root of a problem takes longer than we’d like. But it’s always worth it. We just gotta power through some frustration to get to the other side of positive collaboration.

 

Bottom line is it doesn’t matter how much you know if no one is able to understand you. And I’ve found the most effective way to gain understanding from other is, as Stephen Covey puts it, to “seek first to understand”.

Catherine Crichlow

Author: Catherine Crichlow

Wannabe skateboarder, hip-hop dancer, karate-chopper, and drummer, Catherine Crichlow is always making the impossible, possible. As our VP, Catherine builds innovative, robust and user-friendly websites for all of our clients and heads up our web development team. Did we mention she's kind of the glue that holds everything together?

View More Posts from Catherine Crichlow