Better Collaboration: 5 Steps to Being Friends with Designers
Written by Oliver Schellner
In my earlier days, it used to be very stressful for me when it came time to hand off my web designs to the developer.
When I received the drafts and first builds, there was plenty of stuff I had to specify again in detail, and I always felt like, why the hell can’t devs just see what I see and code everything the way I gave it to them?
I guess a lot of designers feel that way, but it’s not just the designers. Developers face similar issues. That’s why I’ll focus on a couple of points that will greatly simplify collaboration with designers.
1. Align the language
A very important point I quickly realized when working at Runtastic was that it’s essential to take a closer look at all the terminology that emerged during the collaboration and to clearly define it in your team.
It seems crazy when debating important content, but everyone wants to describe the same things in different words. This only wastes time, and things are still unclear after meetings.
“You want to agree on terminology that doesn’t require additional brain cycles to interpret down the road.” – Eugene Siew @Apple WWDC 2017
And since different designations for similar components are used on various platforms, additional caution is necessary.
For example, the top navigation bar of a mobile app is called Navigation Bar on iOS, but it is a Toolbar on Android, which leads me to the next topic …
2. Educate designers to help them design better
Believe it or not, designers are very curious creatures and love to be shown things, especially if it makes working together easier. So, my advice to developers is just go to your designers and tell them a little more about the platform-specific peculiarities.
How do certain components behave and why? What exactly is meant by a “view”? When are alerts used or can they be swapped by another popup, and what is this called on iOS and Android?
A design problem can’t always be solved the same way on every operating system. A designer is always happy when he or she gets support and is more involved in the entire team. Otherwise there is a risk of becoming lonely, since usually far fewer designers are needed to work on a project compared to engineers. Having covered that, you should definitely address the next aspect.
3. Know the difference between UI and UX design
UI designers and UX designers seem pretty similar for a lot of people, and in many companies one person covers both fields of knowledge. But actually, there is a difference you should know about.
Just like iOS developers don’t like to only get android designs at a handoff, a UX designer doesn’t want to talk just about the UI. Make sure to address the right person with your issues to save time and avoid misunderstandings.
Basically, for the sake of clarity, it is very helpful to spell out the short forms in full at the start. On the one hand, we have the user experience designers (UX), and on the other, the user interface designers (UI). As the word suggests, the user experience designer deals with how users are going to experience the product, how they behave, and what they expect, while the user interface designer deals with the visual design of the actual interface itself, the layout, colors, and typography.
The following image gives you a quick overview and you might remember it better.
Once you understand this, communication between your teammates will be a lot easier and you can work together on new approaches to correspond with the users’ habits.
4. Take care of the style guide
We like developers even more if they get used to the style guide. It is created to ensure a consistent appearance of the product(s) and must be followed by everybody who’s working with it. If all designers strictly adhere to the guidelines and then find in the reviews that the components in the builds contain a number of incorrect colors or fonts, incorrect drop shadows, or other subtleties that have been ignored, there will probably be some discussions in the team about paying closer attention to the definitions in the guide.
A style guide is incredibly important for all developers out there, especially in larger companies with multiple products. It is also an opportunity for you to write down all the technical details of a component.
Plus, it would save tons of time, as defined components can be implemented much faster. Look at the style guide as a possibility to collaborate with the designers and the other developers on a working overall appearance. So, not only will the designers thank you, but you will benefit from this as well.
Finding the right tools for this is not always easy, and you usually have to try a few times until you’re able to say what works best in a team.
5. Trust their expertise
Coming to the final aspect of this post, I have to say that basically everyone in a working team should take each other into consideration, accept their achievements, and trust them. But that doesn’t mean that no criticism should be made. Quite the opposite, designers also love to receive criticism and explain their designs in greater detail.
It is not uncommon that a design is not liked, or someone has a great complementary idea for it. Conversations are very important, and listening to what everybody has to say can save a lot of back and forth; there are often some drawbacks to considering rules a higher priority. Good designers won’t make decisions without a justification and are always at your disposal for a talk.
“The best engineers I know are artists at heart. The best designers I know are secretly technicians as well.” – Andrei Herasimchuk
Always remember that you’re a team and you’re all working together on something. So everyone is interested in improving the product and making progress instead of working against each other. If this is not the case, you should definitely address the person directly with your concern.
I hope this guide will help you to understand the work of a UI/UX designer and improve collaboration within your teams.
At Runtastic it works great, and we are always open to improvements.
Feel free to comment on this post and tell us a little bit about how this is handled in your company, where the sticking points are, what works well or doesn’t. I’m curious to explore other sites.