Many developers tend to be ironic about HTML and CSS. Like, it is very easy and anyone can handle it. I agree, these languages are pretty simple to learn and understand, but I can tell from my experience, that 90% of developers would do a poor job on building a responsive website layout. There is a reason for that: they usually don’t care about visual stuff much. The primary goal of most developers is to make things work. Most often, it doesn’t really matter to them if the color of icon is slightly different, or margins are not pixel-perfect.
There’s no one to blame for that, cause everyone is trying to do their job. It’s natural for designer to defend every pixel, and it’s also normal and understandable if the developer did not notice that the background was actually not pure white, but a little #FEFEFE.
So, how can you solve that? How to achieve the most accurate implementation of your design? Just code it yourself, they say HTML and CSS are super easy! Just kidding, let’s look at some other options:
If the project is new, and you are presenting your design to developer for the first time, it would be nice to talk about it, explain the behaviour of some elements (if you had something special in mind). Developer will ask questions and clarify all the controversial parts. If you are working on existing project you should still have a conversation every time you give a developer new bunch of screens. Maybe you added a new component with unusual behaviour and it needs explanation. All team members should be open to communication: if developer is not sure what certain element is doing, it is always better to ask, rather than take a guess and be possibly wrong.
Many people don’t like showing their work results until it’s more or less finished — both designers and developers do that. In fact, I tend to do that as well, whatever role I take. I am working on changing that pattern, since a bunch of fixes can easily be avoided if a job was presented earlier and bugs were caught in two screens instead of twenty. There were situations where developers gave me a build to do design QA and my only inner reaction was “What the F is that”, cause everything looked wrong and broken. I sat down and wrote huge sheets of feedback, with app screenshots and actual design for comparison, with a detailed explanation of what needs to be fixed. Almost every screen in the app got into these feedbacks. Those situations were not only developer’s fault, because I, as a designer, should have asked to look at build earlier to prevent bugs from spreading.
Original Photo: Marsel van Oosten
Everyone needs to be a little more gentle with each other. Each time I am writing feedback, as described in the previous paragraph, I read it several times to make sure that my tone is neutral and I did not offend anyone (because I never mean to). Yes, maybe app looked a little crooked (from design perspective), but it was functional, which means that people worked really hard. And they will not be happy to hear “Wow, that looks shitty” instead of “Great job, but let’s adjust it a little bit” Always remember that the primary goal of most developers is to make things work. So please tell people that they did a good job first, and then delicately point out the flaws. By the way, everything is usually not as scary as designer might assume: dev guys don’t necessarily have to go and change crooked component on every screen, at most cases they just need to edit a couple of variables.
Your job will be constantly commented and sometimes criticised by your coworkers. A developer may notice some inconsitancies in your design. You might have uneven margins in similar screens, or use different shades of grey for similar elements or backgrounds. We are all humans and can make mistakes, because we might get distracted or work at a pace that is too fast to notice some small but important things. Developer might and should ask you questions about those inconsistanceses, and you have to remember that they are not picking on you, they just want to know which version is correct, so that you won’t point at the wrong color or smaller margins while doing design QA.
If you are working on a big, high-loaded project like a dashboard, CMS or a big App with tons of screens and functions, it’s good to create a design system which will contain all main elements that are used in different screens and cases: buttons, dropdowns, input fields, text styles, menus, icons, colors, states, etc. The design system will expand with the project, make sure you are keeping it up-to-date. Make different screen sizes guidelines for web projects. Take the most complicated and loaded screen and show how it should look on desktop, on tablets and on the phone. This kind of work can be fun, too. You can make really sleek and good looking guidelines, then print it out and hang on the wall of your office, so a person who is working on that project can always refer to it by just raising his head.
Original Photo: Barbara Jensen Vorster
Good designer should know basic development concepts and restrictions. Like grid, best sizes, units, etc. Some design features will never work in real life without exhausting and crooked “duct taping”. For example, a very cool triple shadow under a button is impossible to make on some Android versions. And it’s always better to implement native iOS time picker than reinventing a wheel in your own custom way. Keep in mind that there’s always a budget that client is ready to spend, which means that you will inevitably have to sacrifice some fancy features, unless it is your own project and you have no time or money limit. You have to compromise sometimes, but at the same time, don’t let people fool you: you can meet a lazy developer, or one that just don’t know how to implement certain features and having a hard time admitting it. If you are not ready to give up on your cool design and think that developer is not exactly honest with you, you can ask other, more experienced developers if that feature is really so hard to implement.
It is a good idea to ask the developer if he could implement your spectacular idea before you start working on high-fidelity design for it. This includes things like complex animation or unusual elements behaviour. The best approach is finding a live example on some other websites / apps and show it to developer. If you won’t discuss your plans in advance, there’s a high risk that your fancy design, which you’ve spend a lot of time at, will go to the drawer forever. Wasted time, wasted funds, lots of frustration. No one wants that.
There’s a common problem to a number of companies where people always try to cover their own backs and blame others. “Not on our side” bugs and so on. This is often happens under a bad management and abusive work atmosphere, but this is not the necessary component. If a project comes to production stage and it looks raw and unfinished, it’s a fault of each contributor. In this case, no one cares if a designer did perfect layouts, named all layers and grouped all blocks. To achieve decent result sometimes you have to be persistent and ready to bother developers multiple times to make sure they fixed everything you’ve mentioned in your feedbacks before releasing.
Original Photo: Yongqing Bao
Not all things I’ve covered in this article are obvious when you are starting your design career. Product design is all about final result and end user experience. It is not about beautiful pictures for Dribbble. Neither the good result nor a satisfied customers could be achieved without teamwork. A developer should be your best friend. You should spend as little time arguing as possible. If you need someone to put all blame at, throw it on managers!(just kidding) (I am not kidding).