8 Ways To Improve the Handover with Engineers
--
This article originally appeared on onepixelout.com.
I wasn’t always a designer. I started out as a front-end developer.
Or “web designer” as we used to say in them days.
*lifts newspaper and gives it a shake*
Anyway, there were parts of the job that were definitely annoying. Those annoying things usually came from (amongst other people) designers. Designers would come along with last minute changes and impossible requests.
After a while, I got fed up with being annoyed. If you can’t beat them, join them. I became a designer, and I’m using my insight to hopefully make designers everywhere less annoying.
What Was Annoying?
As the developer, I would receive a Photoshop file containing all of the assets that were part of the approved design. At this point, the client had already signed off on this, so the expectation had been set. There was no more room for negotiation, I had to figure out how to make these designs pixel perfect on the screen for the client. Because these designs had been created by a graphic designer, they contained:
- lots of custom elements — custom fonts before Google fonts were a thing
- cloudy backgrounds at a time when transparency was not supported by browsers such as IE7
- rounded corners when that was a trend and was difficult to do. Now that it’s not a trend anymore, you don’t see as many rounded corners.
The handover between designers and engineers have always been tricky. It is a road fraught with pushback, technical restrictions and disappointment. As someone who has been on both sides of the fence, I feel I am in a unique position to make things better for designers and engineers by listing some of the techniques I’ve used in the past few years to better facilitate handovers with engineers.
Why Improve the Handover with Engineers
Developers are the last people to handle your designs before they reach the user. When the handover between engineers and designer goes smoothly, the experience is usually delightful. Often, these two forces can combine and sparks can fly. Engineers can offer insights into possible animations and transitions that maybe we as designers might not have thought of. Designers can be pointed to micro-interactions that will make the user experience extraordinary.
When these two worlds come together, the results can be beautiful.
We should not think of designers and developers being opposites — but we are all part of the same team. But forging a wonderful working relationship isn’t easy. No one is going to hand this to you, this is something that takes work and understanding from both sides.
With that in mind, here are a few key factors that go a long way to creating a powerful, symbiotic and productive working relationship.
1. Get Developer Feedback Early
One of the best ways to get buy-in from engineering is to pull them in at the early prototyping stages.
Ask for their feedback. Ask for their insights, show them a problem you have been having… Maybe they know of a cool feature they saw on a different app that might inspire you.
As designers we spend a lot of time exploring and gathering insights, and gradually distilling this down to the final design. They will be glad that they were consulted at an early stage, and will also save time and energy by telling you at that early point whether or not something is possible or not. Just be clear when something is an exploration, or a final design.
2. Stick to the System
This one used to get me really upset back in my developer days.
Creating custom styles all over a new feature is the fastest and surest way to get on the engineers nerves. Developers have already created a system of fonts, colours and the basic components such as form fields and buttons. Spacing, padding and margin have been locked down.
When you create a design that changes the spacing between elements, or introduces a new style for text, you have messed with the system. I don’t mean to stifle your creativity. You’re the designer, and if you feel the spacing should change, then that’s up to you, but how you do that will make a huge difference.
How to Get Around the System: If you are proposing changes to a registration form, but you also need to change the spacing between the form elements — by all means propose changes to the spacing, but treat this as it’s own story or project. Even if they are rolled into the same release, the engineers will see this as separate item, and they should be treated as such. When a change is made to the spacing, it is not local to a single feature, but will impact other pages and other features, and will need it’s own testing phase.
3. Use Inspectable Design Tools
Designers used to hand over design assets as a flat graphic file that showed information on the spacing and margins. These documents were called redlines. There are 4 reasons why redlines don’t do the job:
- Designers hate making them
- Developers hate reading them
- They’re tiresome, boring and often incorrect
- They take a lot of time
Don’t waste their time and yours.
Don’t put yourself through the tedious job of creating a document that will not make any difference.
Get smart and be effective.
Use an inspectable design tool — Zeplin is a great option, along with Invision or Google Gallery. From the designers side, all they need to do is upload artboards using the Sketch plugin.
The engineers will be able to able to inspect the button, form field, or paragraph. If they highlight a paragraph, they will simply be able to copy and paste the plain text directly. If you are the person who introduces these tools into your process, you will be regarded as the hero that you always were, it was only a matter of time before other people started recognizing it.
Level Up and Become a Better Designer
This post was originally published on onepixelout.com
medium.com
4. Condense Your Work
This is something that took me an embarrassing amount of time to figure out — but the handover meetings are not the place to talk about future plans, explorations or ideas that you are working on (unless they directly impact the current project). Don’t confuse people with your ramblings. Focus on the task at hand, and nothing else. Set the expectation of what needs to be delivered for the next sprint or in the next release, and no further.
Condense your design files into what is signed off and expected from your manager. It might be a single artboard, or even a single slide of a deck. When you’re presenting, only present what you are absolutely sure you have signed off and will be the final design.
5. Don’t Break the Flow
This is another one I have learned from my developer days — that the project manager who would ask me to do something just as I was getting into a different task. This breaks concentration that takes a while to set up.
Engineers go into ‘flow state’ which is something I had written about before. Don’t break their concentration by adding small bugs at random times during the day. Stop pinging them with changes.
Batch the changes together and put them in a document, and call them out during a planned meeting.
6. Explain the Journey
When communicating the new feature or designs, it’s best if you can explain why exactly this feature will improve the user experience. Show the screens before and after the new feature to provide context and enhance the user journey.
Why We Should Explain The Journey: If there is something that engineers can’t support, understanding the ‘why’ will help them come up with a compromise or a suitable alternative.
7. Respect Their Scope
This is something I briefly mentioned in step 2, but I felt this particular point deserves it’s own mention.
When you’re going through designs with the engineer, be respectful that some parts of the design will be one change, and others will be something else.
If you need to create a separate style for text, this should really be a separate project. If you want to update forms and buttons, then treat this as a separate project too. If your goal is to create a new feature — like adding “top menu items” on a food ordering website — then do only just that.
8. Learn To Code
It might be the thing that helped me the most in my design career — when I knew what I was talking about, I was able to push back on certain things that I knew were possible (if the engineers told me otherwise)
There is a lot of debate over whether or not designers should code. I don’t think you need to learn how to code in order to be a designer, but knowing how to code will make you a better designer. It will give you a better understanding of the constraints the engineers are working with, and you will have a more rounded view of the impact the changes you are requested will have from their perspective.
At the most basic level, take a Sunday evening and try out some HTML and CSS tutorials. See if you can get something working from Codepen or JSFiddle.
So those are my tips on how to improve the working relationship with developers, and facilitate a productive handover. We have so much to gain from bridging the two worlds of design and development. I hope that in the future, more designers will know code, and more engineers will learn about psychology and behaviours. Our outputs can be much more than the sum of our parts if we remove the silos that have been built and start working together in a world of mutual respect and understanding.
If you have any other ideas — I’d love to hear from you. Especially if you are a programmer or engineer! Please let me know in the comments or over on Twitter.
