The behavioural changes which can lead to almost perfect design handoff
The perfect world of software development would involve a handing off of designs to developers such that there are no feedback/QA rounds for UI. The developed interface would be the final one — ready to be used by the end users. This would reduce a lot of waste of time, money, effort both physical and emotional, required in going back and forth in converting designs to useable products.
There’s a lot that the design tools have automated, making it easier for designers and developers to collaborate over the creation of desired products. A lot of the friction due to bulky design hand off processes has been reduced — whether it is to create images & icons of proper sizes, include layout measurements of spacing and sizing, providing definitive guidelines for how the interactive UI elements will work. However, there remains some areas which can be further made better to attain a smoother design implementation. This can happen by understanding why the gaps arise before jumping to solutions and setting processes or checklists around it. Although, processes and checklists help but they probably will lead to further checklists if the behavioural part is not corrected first. And once we, as designers are more aware of that we’ll know the right thing to do for an effective handoff.
And so I believe, being aware of these behavioural aspects can make the design handoff less messy[you can skip the examples if you get the points]:
1. Pressing for time
You gave a wrong commitment for your design delivery and now you’re rushing to put it together. What’s the most likely thing to be missed in this case? The things that hide in plain sight — the thought processes behind the UI design element which was crucial to engineer it.
Example case: You designed this screen and passed it on for development. Since you were rushing you missed including the thought process behind the image. You had thought that the image will be positioned in the background and the text will come over it. So that in future an image covering the entire screen could also be used without future development required. If this message is not passed then the design will break when you try to use a full width image.
Next time you feel you’re rushing, you’ll know what you’re likely to miss. Ask for or propose a more appropriate deadline for yourself that will help in finishing well. Afterall, time spent now is much more times saved later.
2. Task repetition
You may be more keen about the design parts that are engaging, exciting and new, like wire-framing a new feature request or designing it up in Sketch. This does not take off our responsibility to give less importance to the minute, repetitive tasks that are needed for each design project.
Example case: You designed a responsive layout for a subscription form. You realised later that you have to include one more input field in the form. You have to tirelessly include it in all the screens and make the required layout changes as well. If you only change it in once screen to avoid repeating the work across all the screens assuming that the the person reading the designs will understand, the design might not come out the way you expected.
3. Obviousness of things
Some of the things may look too obvious to you as a person who’s been thinking about that design for days and days, but probably it may not be obvious to another person. It’s best to not let up on the things that feel are clear just by looking at the design.
Example case: You designed a post section(as shown in the image below) which will be clicked to read further details about the story. You think it’s obvious to figure out which part of the post to make clickable. So is it the image? the text in blue? the body text written in the grey box? the grey box itself? all of it? The best possibility would be for the developer to make all of it clickable but they will need to make a decision here. That’s where the UI will not come out the way design had thought about it.
4. Shortcuts (may not be intentional)
There may be some areas which you feel are patterns in the design and that if one thing works a certain way in one place then the same thing should work the same way in another place. So you take a shortcut of letting it go for development without including the guides again. This also hinges on the assumption that the developer is always a 100% aware of all the components and how they work in all of the places. While the reality is that they are focused on building what’s in front of them and their efficiency is much higher if all the information is present there itself. Or you could be taking a shortcut in some other form.
Example case: You created the components to access Annual reports and added relevant comments for how the animation and hover effect will take place. Now you leverage the same design for a section for Financial reports which you design a few weeks later but don’t add any instructions because it follows a pattern. The chances are that the animation and hover effect for Financial reports will not become reality. This leads up to feedback and QA cycles. *probably this example is too obvious and there are less chances of happening but what do you know, it’s best to aim for the perfect handoff*
5. Assumptions
There may be times when we assume certain things such as — the other person is thinking the same way as we’re thinking, they can follow through the rest of the steps, they already have all the information, they can always come back to me if more information is needed. In design, if we don’t think things through for ourselves or even on other person’s behalf, and let assumptions slip up in design, we’re bound to have gaps in its execution that automation cannot resolve. When we’re being relied on for guidance and directions to UI, we can’t leave room for assumptions.
Example case: You’re updating a UI of a screen where it doesn’t really make sense to have the dropdown ‘View office locations’ in case there are no locations added for the practice. Why let users click once only to find out that there’s no further information. While passing on the guideline, you shared that we don’t really need it to work this way and let’s remove the drop down for such cases. Now if you assumed the developer should have guessed that after removing the dropdown, they should continue to show the message ‘No location found’ to make it very clear to users then there will be a gap between how you wanted the design and how it will turn out to be.
The consequence of assumption is that the design is only ever complete in the designers mind.
6. Right communication
The way the interfaces have to be intuitive for the users, so does the communication has to be with the design or development team. There may be times when trying to explain a complex idea that the words won’t get across as they were intended. Words may often be loaded with meaning that may not come across in the first read or even second. Or what was written in one way may get understood in another. Or punctuation may change the meaning completely. Whether the idea to be conveyed is straight forward or not, it is best to rely on the communication format that is most clear and simple. You can even go out and use more rigorous methods of explaining, with the help of sketches and pictures etc…you know saying it with a thousand words.
An extreme example case: you use a slash(/) to signify an either or scenario or to give options Apple/Banana, whichever works better. What if somehow, due to a context of the problem, other person takes it to mean that both the options have to be implemented.
7. Pressing for cost
Design has a direct implication to the cost of the construction, the more design inputs are added, or design changes are made, the cost of construction increases. Probably not just of design but the later development as well. To avoid the design cost, there may be chances that shortcuts are taken to handoff designs. Rather than saving cost this may lead to unexpected revision cycles and imperfect design handoff.
Mostly the cases discussed above may not fall in one direct category but a combination of these traits. Having a check of how we’re feeling while designing can lead to a great design implementation. And while most of the thoughts on improving design handoff are in vague terms — how designers and developers need to communicate more often and more effectively, let’s give a try to how we can individually make it better and then also think about changing the system.
While putting together this list, I went back to my past projects and extracted the feedbacks that were captured through Github, and tried to reason why that design difference came up. I could figure out the ones listed above; I will continue my analysis and share if more reasons arise in the future.
