One of the most vital parts of delivering a successful project as a designer is collaboration. The relationship you have with the other members of the team can make the difference between a mediocre and a stand-out product.
Designers and developers have many similarities in their approach to work and once you can recognise their needs it will enable you to work better together.
I have spoken to a few developers in my team and put together some pointers for building a better relationship with them and creating a more efficient and less painful working environment.
Set expectations early
When starting to work with a developer it helps to lock down the structure of your design early on, allowing them to start work on the parts which have a lower risk of change. This means that by the time they get around to implementing the visual layer you would have already explored many of your options and hopefully have a near finished design.
“Designers are very picky”
When kicking off the project it’s also important to communicate which parts of your design are likely to change, this will help them prioritise and reduce the amount of rework.
Give them what they need
One of the biggest helps for the developers is for the designer to have as much ready for them at the start of the project as possible. This means setting up a style guide to communicate the layout you desire.
Explain the guide at the start of the project, which should cover things like fonts, sizings and colours, for example:
Display 1 = Helvetica Regular 24pt
Body Colour = #CCCCCC
Heading Margin = 20pt
Supply markups of your designs showing the font styles and colours you’ve used in your designs. The level of detail you go into will depend on the project, time, and the dev involved - some may require every part of the layout documented whereas others may only want the basic elements.
If we’re able to speed up the development process as much as possible it will be a massive help to them and also increase the available time to craft the work further down the track.
Know your developer
Developers can come from a wide range of backgrounds and have different skills and interests, it pays to recognise this and factor it into the way you communicate and work together.
“Pretend you’re dealing with Moss from The IT Crowd because we’re all a bit like that!”
Someone with a stronger visual interest will be able to work with little direction. If you allow them to have more freedom on the design they can explore solutions which may have been overlooked and will put the extra effort in to make it look polished.
A developer who comes from a technical background may approach your design from a totally different perspective, requiring detailed specs and direction on a micro level. Things that come naturally to designers like layout and hierarchy may seem foreign and unimportant to some. Hence, it is valuable to recognising the approach your particular dev is likely to take.
Work with their strengths and weaknesses and understand their point of view. Learn and respect what excites AND annoys them, this will help you build a better relationship.
Working closely with your developer will not only make for a better working environment, but will also improve the product and process as you get valuable input from them.
Who knows the platform better than the people who spend all day building for it?
Validating your design decisions early in the process will drastically reduce the wasted effort involved when you start to veer out of the development constraints.
I’ve found that mini-reviews give great feedback, keeps everyone on the same page and reduces the shock of inevitable changes.
Don’t break their focus
Developers are similar to designers in that they require focus to complete their job. Interruptions are costly, slowing them down from the flow of work they are currently looking at.
Keep collaboration going but be mindful of the fact that developers need time to focus. I would suggest setting up daily reviews/catch ups in specified time slots, allowing them blocks of time to complete their work free of distraction.
Respect their time and they will respect you.
Pick your battles
Being able to gauge the amount of development effort required to make specific changes will help determine which ones are worth the altering. A simple visual tweak may end up taking days to complete.
Speak to your dev and find out how much effort is actually involved with your changes, asses the priority of what you want done and make an informed decision.
You need to ask yourself: is this change worth the risk of not getting the feature delivered on time?
If you work with the developer to lock down the ‘bones’ of the layout before they start implementing, it’s quicker to make subtle changes later rather than ripping the code apart for a big change.
Explain your changes
No one wants to simply be told what to do, you need to give context of why you want something changed which will create empathy for your decisions.
Ask them for their input and give an understanding of WHY you want something bigger, smaller, brighter or darker will help educate them as to how you arrived at a decision and may even impact how they approach your designs moving forward.
Stop being that picky designer and instead gain a level of understanding.
<Speak their language>
Get to know the tools that developers use, have a basic understanding of how they do what they do, what is native, what is custom, etc. Knowledge is power and the more you know about how things are built the more trust you will build with a developer.
Knowing this will let you speak in terms that they understand and will reduce the risk of mis-interpretation. Do you know the difference between a switch and a segmented control? Terms like this could save development effort and make you at least look like you know what you are talking about.
There are plenty of online resources out there to get a basic understanding of their tools, or better yet, get a developer to teach you. I’m lucky enough to work with some of the most talented people in Australia and have been getting Xcode storyboard lessons from the guru Tom Brodhurst-Hill, and Swift programming lessons from one of the most visual developer’s I’ve worked with, Chris Hulbert.
“The biggest key is to find a dev who cares about making things look pretty — many don’t, and it’s like flogging a dead horse trying to get them to do what you want.”
So when you start your next project remember the above points and try your best to build that relationship with your developer. It will help make the journey more enjoyable for everyone involved and improve the quality of your product — and if all else fails slip them a few of their favourite snacks or a bev at the end of a long week. Don’t forget to celebrate your work together.