DIY: Creating a Great Relationship Between Dev & Design

A successful relationship between the dev & design teams is key to achieving a good product. Unfortunately in most companies, this is not the case. Today Minute Media designers and developers work together in a collaborative and healthy atmosphere - but it took a lot of work to get to this point, and it takes constant work to maintain it.

In this post I will share our journey to a successful culture of collaboration between our development and design teams, including the challenges we had to overcome along the way.

Common Points of Friction

There are always reasons for tension between teams, but those small points of tension can soon become rifts which can then turn into complete disconnections. In order to avoid this, let’s take a closer look at the two major points of friction that can occur between the development and design teams of a tech company and how to minimize any damage.

Lack of Involvement

One of the reasons for friction between teams, is lack of dev team involvement in the design process. Imagine that you’re a front end developer and you’re sitting in a kick-off meeting for a new feature. The development starts tomorrow and this is the first time you’re hearing of the new feature and seeing its design.

As a designer, I’ve unfortunately been in this situation many times . At one point my team showed the design of a new platform feature, and it was the first time the developers had seen or heard of the project. Since they had no context, they couldn’t focus on the design at all. They were focused on time-frames and project scope, instead of the UX and flow. The kick-off meeting was unproductive to say the least. This could have been avoided if there was clearer communication between teams.

Project Scope

After that flawed meeting, there was a change in scope, the second most common cause of friction. Now please place yourself in the designer’s shoes. You’ve been working on this feature for quite some time and after presenting it to your dev team, you now have to start over. You’re probably thinking, ‘Argh.. all this hard working for nothing!’

Changes in scope can go both ways. For example, we had a big project that required code refactoring during the project. The developers had to refactor most of their code, since we found a better solution. Change of scope is always frustrating, because at the end of the day we all want to do meaningful work.

Mending the Rifts

Everyone wants to get to the point where both teams are working well together, but how do we get to this point and where should we start? Getting there is no easy task, there are no magic words to make it better. You need to work for it, and the first thing you need to do is build a foundation of trust between the two teams.

Get personal

The first step I took was building personal relationships with members of the dev team. I would sit next to the developers and start with ‘good morning’ and a smile. Then I would start talking about casual stuff, including ׳Did you see the new coffee machine in the kitchen?’ Or ‘what do you think about last night’s episode?’ And now comes the best part. After light conversation, I would dive deeper and ask questions like: ‘What do you think we should do differently?’, ‘How can we work better?’, ‘What type of experience do you have working with designers/developers?’ Through those conversations I was able to gain insights and understand how both teams were feeling.

Your peers will appreciate you for this because they will see that you actually care and want their opinion.

Transparency

If you’ve asked those questions you’ve probably heard that they want to be more involved. Developers don’t want to be just code-monkeys, and designers don’t want to just create pretty things. They both want to be more involved in the process as a whole.

So, as designers, don’t be afraid to lower the walls and show the developers what you’re working on, even if it’s still WIP. The sooner the people who are actually building the project see it, the sooner they will become familiar with it. If they see the project along the way, they won’t be surprised in the kick-off meeting and will be able to provide constructive feedback.

Feedback

Showing the design will only get you so far though, you need to also let the developers give their own feedback. Not only will you have a fresh set of eyes looking at the project, but you will also get feedback about the complexity, missing states and abnormalities.

Personally, I like to bounce ideas off developers, because they don’t live in the same world of design limitations as I do. They can come up with the simplest solutions, or be completely off track, but either way, they will appreciate you asking for feedback and will have a better understanding of your design challenges.

Switch Hats

Let the developers understand the work that you do. For example, I presented our dev team with the process of one of our recent projects, showing them everything, from gathering requirements to the final design. They were shocked to learn that it took over 30 drafts to reach the final version, and understood more of the designing process and its challenges.

It is just as important for designers to wear the developers’ hats every once in a while. It will enable them to understand the problems and limitations on the technical side early on, as well as the fundamentals of code-writing.

Find solutions together

When you send the design to the developers to work on, make sure both sides know what to expect. Go over the spec together, ask questions and ensure everyone leaves the meeting with everything they need to know.

Of course, when the coding starts, developers will have questions or encounter problems, but the teams should work on these points together, putting the product at the center and not ego or feelings. Both teams need to understand what the crucial points are and what points they can compromise on.

Visual Bugs

Once the development is done, and the project is in a QA environment, don’t forget to let the designer see it and provide feedback.. Because it is the designer’s job to explore the project and dive into the details that developers might have missed.

It is also important to prioritize visual bugsbecause sometimes teams won’t have enough time to fix all the issues. It is ok to go live with some visual bugs, as long as both sides are in agreement and whatever bugs have been missed, will be prioritized in the future.

Wrapping Up

We all need to remember that we’re in it for the same reason - to create an amazing product, and have some fun along the way. Making the effort to improve the relationship between our developers and designers truly made a difference. That said, not everything is perfect and we still have a ways to go.

Because there are different people and personalities at every organization , it can be hard to find one process that fits all. If implementing this process for yourself, don’t be after to get personal and tweak it to best fit your needs.