We’ve all had it happen - you’re on a project and you think you’re nailing your communication and totally on the same page as your team. Then something goes wrong, a certain question is asked or another team member says something on a meeting and suddenly you realize you’re all not only on different pages, but different books altogether. One person’s book is an ebook, another’s is actually a magazine, and then someone else’s is a beat up paperback with missing pages. It’s no surprise that a lot of miscommunication can happen when working on a project with people with diverse skill sets and backgrounds, some technical and some non-technical.
We recently wrapped up a project where a technical team member and non-technical member worked closely with each other. The project was a huge success and we thought some of the things we learned along the way might be of help to you. But before we get into that, who is this “we” we keep talking as?
Linzi is a Designer in the Creative Services department here at Phase2. Before joining Phase2, she worked for 10 years in tech support, and her BFA Thesis was a working arduino prototype of a sensory augmentation wearable she designed, coded, and built. In Creative Services, the projects she enjoys most are complicated infographics, file organization, and pages and pages of tedious typography layout. She is, without a doubt, a technically minded creative.
Joanna is a full-stack Developer and has worked on numerous Phase2 client engagements. However, she's not your average developer. Joanna doesn't have a Computer Science degree. Coming from the nonprofit world, Joanna's past jobs were non-technical in nature. But despite Linzi's knowledge of the tech world as a designer and Joanna's experience working with and managing people, we still ran into a few communication bumps throughout the project. Fortunately, by being a little more conscientious and by following some of the tips below, we were able to come out of this project much stronger as a team.
Before we jump in, we want to clarify something. We’re using the terms “technical” and “non-technical” intentionally, and for a specific reason. Conversations about this topic usually center around Designers and Developers, and although we both fall squarely into those categories, the conversation can be (and should be) much wider. People in all kinds of roles can be technical or non-technical - both in their responsibilities as well as brainspaces. Typically projects involve numerous roles that are both technical and non-technical in nature and everyone can benefit from these.
Here are the best practices we’ve developed based on working with each other here at Phase2:
A little bit of preparation for your communication can go a long way, and this is a habit Linzi has started implementing in her design process. Whenever she finds out she’s starting a new project, she reaches out individually to the people involved to touch base before any of the actual work begins. It’s just a friendly, personal message that essentially says “hey, I just found out we’re going to be working together on (name) project, and I just wanted to reach out and touch base, see if you had any questions right off the bat.” This opens up the lines of communication before any stress or tension from the project is involved, and creates a space of open communication moving forward.
Sometimes a bit of explanation goes a long way. When making changes to a design comp, Linzi would explain why the changes were necessary. For example, when adjusting the spacing for Phase2’s leadership headshots, Linzi explained that by reducing the spacing between the name and title tells the users those two things go together and prevents the title from looking like the caption of the photo. By providing this explanation, it showed that these changes were meaningful and not just arbitrary changes.
Being honest about what is realistic and what is not for a digital project is incredibly important to the communication process. It comes up a lot between technical and non-technical teams, and we were no different.
In an initial page design, Linzi mocked up a large, semi-transparent Drupal 8 logo behind a quote. She had intended it as a static background element, to be used kind of as a backdrop. Joanna explained the issues and complications with this element of the design, and together we reworked the mock up to something that fit our scope and timeline.
Documentation is always a good idea. It gives you something to reference back to if there is any misalignment on the parameters and expectations about the project. It also prevents scope creep!
This mantra is quickly becoming a staple in creative spaces, and for good reason. Sometimes words just simply cannot convey what you’re trying to say, and visual aids are needed. This can be a wide range of things, varying from full fidelity website mockups, to sketches on post-its. The purpose is to expand the communication method past just words, and try communicating visually to better understand each other.
Throughout our project we did this often, Joanna provided screenshots whenever she was working on things to make sure it was what Linzi expected, and any revisions or changes that needed to be made, Linzi would make quick mockups with descriptions to explain changes.
It's tempting to use industry specific jargon when talking about a particular element of a project, especially when we’re all in the habit of doing so in our daily conversations within our teams. But when talking with people who are not involved in those daily conversations and might not be familiar, using that type of language not only prevents you from understanding each other, but can also make the other person feel inferior, put down, and embarrassed. This then creates problematic barriers in your communications, and no one wins.
Besides being more empathetic about when you use jargon, both sides of a discussion can make the effort to learn some basic industry specific terms outside of their industry, and if both sides put this effort in, you’ll be in a much better place to communicate in a way you both understand.
We all have played them, and they are super effective at closing off and shutting down open communication. The blame game, the I’m offended game, the my job is more important than yours game, etc. Just don’t play the games.
Reaching outside our usual bubble of people and either offering or asking for help can help develop connections, get a variety of feedback, and foster open and honest communication between technical and non-technical team members. This also can be an excellent way to learn what certain terms mean, and develop a go-to person for terminology help.
You don’t always have to talk about the project. Taking a little time to ask how someone is or talking about non-work topics makes communication on the project more natural, and goes a long way when conflicts arise. Both parties tend to be more empathetic in conflict when they have a relationship outside the project context (side note: we’re not saying you have to be best friends, but work is more fun when you enjoy the people you work with!).
When you’re open during miscommunications, it creates an opportunity to learn and improve. When asking a question, Joanna used technical jargon that Linzi wasn’t familiar with. By Linzi being honest and open about not knowing the term, it provided a safe space for Linzi to expand her technical vocabulary, which helps her on future projects and Joanna learned to be more conscientious of her word choice around non-developers.