UI/UX designers and software developers work together a lot. And a big part of good software development is making sure they do it right. To new designers, it might not be easy to do this: how can they know what the developers need from them? Can they only find out the hard way? Well, we’re here to give you some tips from our experience.
So where does it go wrong? A lot of times, potential issues start at the beginning of the designing process. Designers make certain style choices that no framework or plugin can recreate, or which look good in concept but might be difficult to code and/or use.
Or, let’s say they make all the right choices in terms of design that can be coded: but when doing handover, designers might unintentionally leave out important information which will later lead to many messages from the development team.
So how can we fix this?
Set the record straight. From the beginning.
Showing developers what you’re working on from the beginning can be of great help. Let’s say you’ve made one screen that shows the main layout and some key features. Send a screenshot or link to the development team (or just the team lead, as you see fit) and ask them if it’s all do-able. This way, you won’t have to re-do multiple screens if you continue on with the same base design and structure.
And another advantage of doing this is that developers can prepare ahead of time, they can figure out which technologies and plugins they’ll need to use, and which team members are the best fit for the job. And most of all, they can point out what can’t be done and what needs to be changed.
Another thing you can do here is, when you’re designing a more abstract element that you came up with, show them to your development team to make sure they can code it. If they can’t, ask them to tell you how you can improve the design so it’s not painful for them to code. The key, in the end, is communication. And doing it properly (i.e. don’t hide things from them and give them all the info you can give).
Make your design files less of a maze.
Your design file will be the blueprint for the development team’s work. And blueprints have lots of data on them - after all, they’re used in architecture. You should treat your design files the same as an architect treats a blueprint: don’t make developers try to guess what the author meant.
How do you do this? Use headlines, subtitles, arrows, whatever seems fit, and give info about the user flows in your design. Anything that isn’t entirely obvious can come with a little note. For instance, say you have a Delete button somewhere. Ideally, users should be asked if they’re sure they want to delete the selected item. If you didn’t make a separate screen for that, it won’t be obvious for the developer. So make note of it next to said screen. Similarly, when designing in-line edit features, either show each instance of said feature or tell the developers, through a text next to the screen, how it works.
So far, we’ve written two entire articles about having organized design files (check them out here and here). This is another thing that can help you work more efficiently with developers. If they can’t manage to go through your design file, how can they properly understand what they need to code? So here are the main things you should keep in mind:
Name your design file pages accordingly: if you have an extra page containing screens that won’t go into the final app (either trial runs or older versions), signal that in the page’s title. As little as a red dot or X emoji should be enough.
Order things properly. A good way to divide app screens into design file pages is going by the app’s big menu items. But what you shouldn’t do is reverse that order: you might start with certain screens and end with the middle of the app. But when the design is done and ready for developer handover, put everything in a logical order. Begin with the authentication pages and continue with stuff like account management, user management, and then each menu item. Alternatively, you can ask the development team what kind of order is ideal for them.
Arrange your screens in a tidy way. Don’t put things all over the place. Arrange your screens one below the other, in one column or more, depending on how many you have. Making the document messy will make things difficult for the development team.
Sort the screens using big headlines. Think about the look of your design file pages when you’re fully zoomed out. Can you find a specific screen in less than 2 minutes? If not, use big headlines to sort the screens. Let’s say you have a series of user management screens and some user profile screens. Arrange them in separate horizontal rows, next to each other, and put big headlines above them to show what the screens contain. This way, when you’re zoomed out, you can see which screens are the user management ones and which are the user profile ones.
Help them navigate design software.
Picture this: you spend extra time making a shadow for a certain design element. Weeks later, said page gets implemented and you get to see it. But the shadow looks completely different. So where did it go wrong? It’s simple. If you’re using Figma (though this probably applies to other programs too) you sometimes have several nested elements. To you it makes sense, and you know you have to click on something multiple times to get to the base layer or background, a.k.a the element with the custom shadow. But developers who don’t know much about Figma probably don’t know that. And they’ll try to eyeball it - but they’re not designers, and it won’t look the same.
Here are 2 different ways you can approach this:
Setup color, typography and shadow styles (or presets) throughout the design process. Once you’ve done that, when someone selects a design element, even if it’s a group with several nested elements (let’s say, a pop-up with a headline, inputs and buttons), they’ll be able to see all the styles used.
Show the developers, in a meeting (so it’s all clear), how they can see all of these style elements. Most of all, show them how they can view their CSS version too (in Figma, it’s the Inspect tab on the right side panel).
But these are very specific elements. It would be useful, especially for new team members, to give them a walkthrough of the design software you use, so they know their way around. While you’re at it, you can also show them how you sorted screens so they won’t have troubles figuring that out.
It’s all talk - and action.
This is less of a tip you can apply right away, but it’s always good to keep this in mind. Being transparent and open with your development team can help make sure your designs come to life the way you envisioned them. Even if you follow everything we’ve just said in this article, questions might still come up, and it’s essential that you’re available to answer them.
Make group chats with the whole team, make sure no details get left out or can be accessed only by some team members, and participate as much as possible in any team meetings. And most of all, make sure that if you decide something with one or two team members that affects the entire project, don’t keep it amongst yourselves only - share it to the group chat so everyone knows.
If you also happen to test the app that is being built (and which you designed), be careful with the way you give the development team feedback. Don’t berate them, insult them, or tell them they’re not good enough. Sometimes they make honest mistakes. And if anything doesn’t look the way it should, simply point it out and tell them how it should actually look. Make sure to understand the limitations of code, and that not anything will look 100% the way you want it to. Maybe 99%.
And there you have it, now you know a few more things about how to work efficiently with developers, as a UI/UX designer. Overall, we’re all people, and aside from a few technical things you can improve, the most important thing is interacting like peers, being nice to each other and not being afraid to communicate.
Top comments (0)