Bug Tracking

How to improve communication between developers and designers on web projects

Developers and designers have very different job profiles. In fact, they also have very different perspectives, i.e. different ways in which they look at the same thing.

One example: While a website designer looks at the whole external feel of a design, sets the scope for it and decides on how people connect with it, the job of a developer is very different. He or she is the one who has to make that idea work seamlessly on the inside, using code to its best advantage.

With job descriptions that are so different, there is one thing that is of extreme importance: how the idea of the “external” web design connects with the internal workings of the project in order to make it a seamless experience.

Only when developers and designers work as a team, will the end user be able to truly benefit from the application. It’s only then that they will get a product that looks great, is easy to use and is relatively error-free.

So, today we’re going to look at the communication between developers and designers. And how we can improve it.

The magic of communication

So how would you go about improving the working relationship between developers and designers?

A good place to start is by improving the communication between the two. Here are some tips and tricks for you to do just that.

#1 Remove the physical barriers

Organizations today often provide separate work spaces for separate teams. While cubicles and partitions, or even separate floors, can make the entire office look great, physical barriers can pose a problem for communication as well.

As the designer and developer would probably not see each other all that often, the chances are that they’ll only interact when they really have to.

Sure, it’s good for productivity, but this would also mean that a team working on the same project isn’t communicating as well as they probably should. They would only be able to discuss ideas casually within their respective groups, not knowing what the other’s perspective is.

That’s why a great starting point is to remove physical barriers. This means that the two teams must be put together, either on the same floor or office, or perhaps just near each other.

#2 Bring them together as one big team

Once the physical barriers are gone, it’s time to bring your team together in other aspects as well.

In fact, this doesn’t just hold true for developers and designers but it’s true for any team. The two teams should regularly interact with each other. This is key for both developers and designers, who usually approach a problem from very different angles.

Team building exercises help build camaraderie. In order to improve this, encourage team building games and activities from time to time to help break the ice between developers and designers.

Don’t separate departments. You’ll be amazed to see how this will be reflected in the work they do.

For teams that are spread across different locations, travel management companies can simplify the logistics of gathering everyone for in-person team-building activities, making the process more efficient.

#3 Encourage clarity of expression

Often developers get very vague descriptions from designers which sound like, “This button should look like Twitter’s, but function like LinkedIn’s”.

Directions like this make it tough for developers to follow a designer’s idea and easily lead to misunderstanding. That is due to the fact that everyone has their own perception of what the end product should look like.

Putting down a clear design plan is the responsibility of the designer, who should define as many specifics and as many examples as possible.

Preferably, not just a mockup design as this often doesn’t cover all the possibilities a designer has.

Communication is never a one-way street and so the developer should feel free to pose questions about the design to gain clarity.

#4 Ask developers for visual feedback

I’ve seen project meetings about design feedback with no developer present. Apparently, it was just a design feedback meeting and developers are busy people, right?

Wow. That’s a big mistake. Developers are a great source for design feedback too. They have a ton of knowledge about the product or website and they know what can and can’t be done from a technical point of view.

So better make sure to bring in a developer for your next UX and design meetings. Or if you’re just brainstorming some design ideas, invite a few developers too.

#5 Designer – developer ratio

Because of its nature, most tech companies are engineering and development-focused. Therefore, you’ll find more developers in most of those companies than designers.

If you are working in a development-orientated company you’ll see a designer – developer ratio of 1:8. In some cases it might be 1:4, and if your company is UX orientated you’ll find a 1:2 designer-developer ratio.

There’s no right answer to the perfect designer-developer ratio, however, I recommend making sure you’ll pay enough attention to your UX as well. Otherwise, you’ll end up with a system looking like this:

#6 Work towards proper information flow

While smaller projects require interaction between just one developer and designer, things tend to get complicated when the scale of the project is larger and teams of developers and designers are involved.

It then becomes crucial that the right information reaches the team at the right time. To make sure this is the case, create a list of deliverables each team would need from the other, and design a proper information flow channel to make things work seamlessly.

Or as Nick Schaden stated:

Collaboration matters

With an information channel flow in place, both designers and developers know exactly what is expected from them and can participate in the project in a far better way.

Custom Slack channels for developers and designers enable them to collaborate on web projects.

#7 Pair designing & programming

While some designers know little about writing code, there are developers who know little about the process of designing.

The best way to ensure that the two teams function well together is through teaming them up, so everyone understands one another better.

The concept of pair programming originated from the agile software development world where two developers work on the same workstation at the same time.

So why not pair one developer with one designer for new web projects. This can help to sort out UX issues right away.

#8 One + one = three

Designers will always need developers, and developers will always need designers. Only if both areas are filled with ego-less people, we can create astonishing applications or websites.
I really like this statement of Andrew Chalkley in his article Mindset: Developer vs Designer:

Design should lead the development and development should inform design. Separating out these two roles or facets of your application can cause bad experiences for users.

Just because you have a great development team there’s no reason to think that you can put your design ideas live in a shorter amount of time. The same goes for a team of talented designers. Developers shouldn’t always expect an immediate answer to their questions if it means a design change.

Set realistic deadlines, and ensure that the developers have extra time, in case any issues crop up.

Also, set the scope at the start of the project and do not change it, unless it is absolutely essential. These seemingly minor things can cause discord among teams of developers and designers, leading to a shoddily generated end product.

Wrapping it up.

In today’s workplace, where technology has become an inherent part of each and every business, the need for better software design and functionality have become the cornerstone of any organization.

With increasing amount of competition on how businesses work, it is important that teams within the organization function seamlessly to be able to give their clients the best possible results.

An integral part of teams today are the designers and developers: two different specialties, working to create a common product. Don’t be mistaken, these two teams are sometimes very hard to reconcile, but it’s very rewarding and can mean the difference between a good product and a great product.

Thomas Peham

Recent Posts

10 Best Changelog Management Tool Options (Paid & Free)

Ever wonder how some companies make product updates feel like the highlight of your day? …

3 days ago

10 Best Product Management tools: Deep Comparison

Picture this: You’re in the middle of a hectic workday, balancing strategic decisions with daily…

2 weeks ago

Best 11 Feedback Analytics Software in 2024

Ever wish customer feedback came with subtitles? With the right feedback analytics tools, you can…

1 month ago

Survey Design: 11 Best Practices

Survey design is the backbone of effective data collection, enabling businesses, product managers and researchers…

2 months ago

How to Create Epics in Jira

Wondering how to master Jira’s vast capabilities for strategic project/product success? Epics are the key…

2 months ago

How to Collect In-App Feedback: Top 5 Ways For SaaS

In this article, we walk you through the ultimate in-app feedback how to strategy, including…

3 months ago