A Front-End Developer's Guide to Communicating Thoughtfully

August 17, 2016 | Matt Diehl

man surrounded by thought bubbles and iconsI picked up some fantastic tips on communication at this year’s An Event Apart in Washington, D.C. As a sucker for practical tips, Jamie Newberry’s talk, “The Art of the Sell,” was one of my favorites. This post is my take on how these tips can be especially helpful to front-end developers.

I also recently read a useful blog post published on css-tricks.com called “A Front End Developer is Aware.” It provides a solid overview of all the disciplines a front-end developer has to be knowledgeable of or capable in. This has long been something I’ve considered but haven’t quite been able to put into words. Our output is limited to the production of HTML, CSS, and JavaScript, but we have to know how all decisions impact every other domain. We create the final assets delivered to a user’s browser, so we’re concerned with aspects including how design and UX decisions impact performance, SEO, and accessibility. And because every decision we make about how those assets will be constructed impacts the technical implementation, we have to walk the line between what we can do, what we should do, and what others want—clients and coworkers alike. This means that, for front-end developers, communication is especially important.

In her talk, Jamie Newberry outlines 12 “Check-Yourself Checkpoints,” tips to make communicating with others easier and more understanding. What follows is my breakdown of each tip and how it can be useful to the front-end developer navigating the egos and emotions of a dozen disciplines.

1. Communication Design

A broader description of the points follows, but it’s beneficial to ask yourself, am I designing this communication in a logical way based on how I want it to be read and how I want feedback? Front-end concerns are not always easy to understand or reason with. Wireframes or Photoshop documents aren’t experienced in a mobile browser over a 3G connection, so performance concerns are immediately evident. Here are some tips  to improve communication design:

  • Create a checklist of items that you can use for reviewing wireframes/designs/prototypes and provide the same checklist to your other team members so they will know what you’re expecting.
  • When discussing key topics like performance with the client and other team members, frame the goals by using competitor comparisons so everyone can have a quantifiable metric to judge success.

2. Be Specific Immediately

When we get an email and our answer isn’t “yes,” we have a tendency to make the following exchange as long and tedious as possible. For example, someone ask you if you’re available to meet tomorrow at 11. If you’re unavailable then, don’t just say “no.” Say “I can’t meet at 11, but I’m available to meet at 1 or 3. Will either of those times work for you? If not, can you provide some other times you’re available this week?” For front-end development-specific problems, try to give specific, quantifiable information to others about how they can aid your concerns—reduce image sizes by blurring areas of less importance, use no more than two Web fonts, etc.

3. Word Choices

We all have a tendency to sneak certain words into our vocabulary that have no place being there. Remove those words and phrases with negative connotations entirely—"just,” “try,” “find time,” “make them feel a part of it,” etc. all imply some level of hesitance, negativity, or exclusion. As a front-end developer, or anyone with a particularly technical focus, it can feel natural to create a boundary between yourself and others with a less technical role. In addition to being humble and positive with our word choices, talk to and about others as the important team members that they are.

4. Speak with Confidence

Front-end developers should communicate to others as experts in their domain. By doing so, we can get buy-in for the aspects of site development that we know are important. Instead of "I think it could definitely help make the site feel faster" use "this will improve site performance by reducing the number of http requests that the browser has to make."

5. Don’t Be a Jerk

Speak confidently, but respectfully, to others. Never be accusatory. Over the course of a large Web project, a million carefully thought out elements and components need to happen and come together, and sometimes items slip through the cracks. If images weren’t optimized by the designer, or gzip wasn’t enabled by the admin, don’t point fingers. Send a gentle reminder. When you’re expecting something to be done, put it in a “waiting for” folder that you periodically check. Doing so will reduce the chance of last minute surprises.

6. Don’t be “Judgey”

Don’t assume that your clients or coworkers can’t provide valuable input because they don’t have as much background or experience in your area of expertise. Everyone on the project team has an important role and is able to contribute based on their domain and area of expertise. Similarly, when working with another firm, be careful in assuming that the way you do something is best. Be open to working with others and receptive to the way they work. You might just learn something!

7. Accept Responsibility

Some people assume all the blame, others assume none. In reality, the blame probably falls somewhere in between. Blame is nasty when it gets thrown around. It results in lost time and frustration. As a developer working as part of a team, rather than looking for someone to blame, ask “what could I do better?” If something isn’t implemented as you requested or expected, consider how you could communicate those concerns better. Use it as an opportunity to help others, and yourself, improve, learn, and grow.

8. Silence Will Hurt You

One of the seemingly most obvious and simple rules is to be proactive in your communications with colleagues and clients, yet it can somehow be very difficult to do. Falling behind on a task because of unforeseen circumstances is common. Rather than notifying people so something can be done about it, we often say nothing, possibly with the hope that we’ll find extra time. Even if you’re not falling behind, regularly checking in with people who are counting on you will reduce stress all around, better help with project planning and reinforce your reliability to the team.

9. Follow Up

Similar to the last point, don’t let emails sit in your inbox. Front-end developers get plenty of emails about little tasks, estimates to review, etc. When you get a request, determine if it will take less than two minutes to do or provide a helpful response to. If so, send the response right away. If you need more time to research or put together a document before you respond, send a quick email to say you’ll respond by a certain time, and put the email in an “action” folder that you check regularly. This approach not only helps you better plan and manage your own tasks and time, it’s helpful to the person on the other end, so that team member can plan as well. This also reduces the need for unnecessary email follow up all around.

10. Meet Them Where They’re At

Take the time to understand where the people you’re communicating with are in their understanding of your world. Front-end development is full of nitty-gritty details and “gotchas” that only we need to know. When you’re creating something with a new team, frame your concerns in a context that makes sense to them. Frame performance metrics in the context of competitors’ websites. Show the experience of using a screen reader to demonstrate the importance of alt tags.

11. Love What You Do

Hopefully, this one is easy. If you love what you do and show it, it will be infectious and people will want to work with you. Front-end development is one of the most exciting professions because of the rate of change and innovation. It can be hard to keep on top of but extremely fun if you’re willing to dedicate a lot of time to learning.

12. Be You

A big selling point of you is how personal and unique you are. Show that side of you and people will want to work with you. A lot of people can do front-end development, but none of them are as interesting and awesome as you!

About the Author

Matt
Matt Diehl

When I'm not making websites at TBG as a Senior Front-end Developer, I'm often making sites at home, learning more about building them, or playing guitar in a dingy basement in Paul Newman and the Ride Home.

Leave A Reply

comments powered by Disqus