Common Mistakes That Engineers Make During The Designer-Developer Hand-Off
As an engineer at InVision, I'd love to believe that having a Prototype ensures a project's success. But, the truth is, designing a prototype is only a step in the process. There's no doubt that it's an invaluable step; but, it's just one of many. And, even with a prototype, there's ample opportunity for things to go south, especially during the hand-off and delivery of design assets to the engineers. In my tenure here, I've implemented a lot of designs; and, I've made a lot of mistakes along the way. Hopefully, by shedding light on some of these mistakes, I'll be a little less likely to make them again in the future.
Mistake: Not Asking the Designer to Present the Prototype
Prototypes tell a story; but, they don't tell the whole story. They don't speak to the reasons that a feature was designed; or to the trade-offs that were considered along the way; or, to the very real pain that your customers are currently experiencing. They don't speak to the product road-map; or to how this feature fits into the larger and longer-term strategy of the company.
This type of information is important to know because it will color how you feel about the design; and, it will almost certainly color how you think about the implementation. As an engineer, you're going to have to make a lot of educated decisions along the way; and, you can't make an educated decision without all of the facts.
And, let's face it, sometimes as an engineer, you don't always agree that building something is a good use of your time. Your priorities don't always have perfect alignment with the priorities of your Product team. And, there's nothing more painful than building something that you believe is a waste of time.
By having the designer present their work, you give them an opportunity to sell you on why the work is worthwhile. And believe you me, this can make a night-and-day difference. A good presentation of a prototype can turn you from a begrudging worker-bee into an enthusiastic co-owner of the feature's success. And, when your heart is truly in the work, the end-result will absolutely be better - guaranteed!
Mistake: Treating the Hand-Off as a Moment In Time, Not A Process
In the engineering world, we often talk about the design assets as being "passed over the wall". This metaphor positions the hand-off as a singular event that delineates the end of the "design process" from the beginning of the "engineering process". The problem with this mindset is that you are not a worker on an assembly line; you are a collaborator on a product. And if you're not collaborating with the designers, then the success and feasibility of the product is put into jeopardy.
Engineers should be involved early in the design process in order to provide sanity checks and additional perspectives. Unfortunately, as engineers, you often don't have control over early involvement (if you even know that ideation is taking place). As such, you have to be diligent about promoting collaboration on your end of the product life-cycle.
After engineers receive the design assets (hopefully in prototype format), you must feel free to go back to the designers for more information and clarifying details. If there's something you don't understand, ask. If there's something you think may be a mistake, ask. There's no such thing as having "too much clarity".
Mistake: Treating the Prototype as an Absolute Truth
Product ideation and development is a multi-step process. It starts with a thought - a moment of inspiration. Then it becomes a hand-drawn sketch or a Freehand document. Lots of experimentation and iteration takes place. And then, finally, it evolves into a design file or an interactive prototype.
Given the metaphor of an "architectural blueprint", it's easy to fall into the trap of believing that this interactive prototype represents an Absolute Truth about the final product. What you have to remember, however, is that the prototype is nothing more than the designer's "best guess" as to how the product should look, feel, and operate.
The interactive prototype is just a step in a larger evolutionary process of the product - it isn't the end-result. Once the prototype begins to materialize as application code, new information will emerge - new constraints will become apparent. These revelations will either need to be piped back into the ongoing design conversation (see Mistake above); or, they will need to be used by the engineers to change the way in which the feature is implemented (see Mistakes below).
Mistake: Assuming the Designer Considered All of the Edge-Cases
Designers, like engineers, tend to focus on the "happy path" of design. The more experience a designer has, the more robust their thought-process will become. However, at the end of the day, we're all just human. And, there's only so much information that humans can hold in their head. As such, when you come across a User Interface (UI) that will degrade in certain circumstances, do not assume that the designer considered this use-case. This was almost certainly an oversight and should be brought to the designer's attention (see Mistakes above).
It's also easy to believe that a designer is familiar with all aspects of the product on which they are working. But as the complexity of the product increases, there's a good chance that the designer only knows about a subset of features. So, if you see a design that conflicts with or has not incorporated a relevant part of the existing application, bring it to the designer's attention.
The worst mistake that you can commit during the development process is forgetting that you are all a team; and that you all have to have each other's back if you want to the product to be successful and the users to feel empowered.
Mistake: Not Asking the Designer for Empty States
Much like the "happy path" of design, new user interfaces (UI) are typically designed with an eye towards the effective presentation of data. And, the longer a designer works on a single product, the more they think about how to cope with the increasing amount of data that the product amasses.
Over time, both designers and developers tend to forget that a new user is going to have an experience that is radically different from their own. As such, when you receive a new design, make sure that you consider the possibility of an empty state - what it looks like when a user has no data. And if that's not present in the design, ask the designer to go back and add an empty state to the prototype.
An effective empty state is massively important to the success of a product. In many cases, it's the very first thing that a new user will experience. This gives the empty state the power to either make or break the user's emotional bond to the product. If the empty state doesn't entice the user to engage with the product, it may leave the user wondering why they signed-up in the first place.
To be clear, a thoughtfully designed empty state is at least as important as the design of the populated state. Make sure that the designer has considered this - the implementation of an empty state should not be guess-work on your part.
Mistake: Not Asking the Designer for Error States
Going back to the concept of a "happy path", designers tend to focus on how a product should behave when everything goes smoothly. But, in many cases, a user interaction can go wrong. And when this happens, the user will need to be presented with an error message. Error messages are part of the product experience. If a prototype contains an interface that can enter an error-state, make sure that the designer has included that error state in the design.
Remember, when something goes wrong in an application, users are in their most volatile state and can easily question why they are even using your product in the first place. A properly designed error state is an opportunity to calm the user down and reinforce the emotional bond that the user has developed with the product. A thoughtfully considered error state can turn a negative experience into a positive outcome.
If your team has a design system, such as DSM (Design System Manager), that contains an "error message" widget, it is still worth discussing error states with the designer. There's a subtle but powerful distinction been an error "message" and error "messaging". Proper messaging can make a big difference in terms of things like Support Ticket volume.
Mistake: Forgetting That You, as an Engineer, are Also a Designer
The roles of "Product Designer" and "Product Engineer" are not mutually exclusive. They are specialized skills, to be sure; but, they also overlap. Both designers and engineers are responsible for the "user experience" (UX) of an application. Which means, as an engineer, you need to be wearing your "design hat" during the development process.
As you being to implement a design, you need to remember that performance is just as much of a feature as anything that you see in the prototype. As such, if you need to deviate from the design in order to maintain the performance of the product, you should feel empowered to do this.
Do not ask for permission! Do what you think is right; and, then ask for forgiveness. You are not beholden to the designer - you are beholden to the user and the user experience. As an engineer, you have an opportunity to design the implementation using information that was not available to the product designer during the ideation phase. As such, it is completely reasonable for you to override decisions that were, by definition, less informed than the ones you are able to make.
That said, you should always handle these situations with respect. When you need to deviate from the design, you should honor the designer with an explanation after the fact. Don't just present them with work that appears to be incomplete - let them know why you needed to do what you did. Designers are completely reasonable people; and will, in the majority of cases, defer to your technical expertise and design-eye.
Mistake: Not Discussing a Phased Development and Deployment Plan
In a single hour, a designer can put together a prototype that would take months for a team of engineers to implement. But, in most cases, the Product team doesn't want to wait months for a feature to be delivered. When given a complex prototype, you need to consider a phased development process with your designer. Look at the features - together as a team - and figure out where the 80/20 boundary exists: the 80% of the value that can be delivered to the user in only 20% of the time and effort.
Remember, a product designer isn't privy to all of the technical factors that determine how long a feature will take to implement. As such, it is your job to inform the designer as part of the hand-off process.
It is also important to understand the designer's "appetite" for the work: how much time they want to invest in bringing the feature to market. If the designer's appetite is smaller than the estimated time of development, then you need to work with the designer to figure out how to reduce the scope-of-work in order to align with the desired appetite.
Mistake: Taking Animations and Transition-Timing at Face-Value
Designers love animations and transitions. Some designers want everything on the screen to move, and wiggle, and sashay into place. Do not implement this. At least, not all of it.
The user does not want this. The user just wants to get their work done - that's why they use your product. And, needless animations do nothing but delay the user's ability to do work. This delay, when aggregated over days and weeks and months of interactions, can lead to a significant residue of resentment.
Now, that's not to say that all animations are bad. Animations can create an organic and intuitive experience that makes the product easier to understand. These animations should be kept in place. But, they should be fast - really fast. Your designer is almost certainly making them too long.
As a rule-of-thumb, an animation should be slow enough to be perceived, but fast enough to go unnoticed. Which means, if you see an animation and stop to consider it, the animation was too slow. Continue reducing animation and transition times until you find that your mind glosses over them when using the product.
Also, no drop-down menu should ever be animated into place.
Also, staggered animations should be avoided.
Mistake: Editing or Creating Images for the Implementation
As part of the hand-off process, the designer should supply you with all of the visual assets. This includes fonts, images, and SVG files. This can be an explicit hand-off; or, an implicit one through the use of products like InVision Inspect.
Do not start trying to create design assets on your own. Even if you have the skills to do so, it would serve you better to push those responsibilities back to the designer. This approach plays to everyone's strength. And, it gives the designer the opportunity to maintain a proper "source of truth" for all design material. It allows them to exercise their "design eye" when it comes to things like the lossy compression of JPEG images or the reduction of SVG points.
Mistake: Not Asking for an Official Prototype
We've already discussed the idea that the hand-off process is not a singular moment in time: it's an on-going process that is driven by collaboration. And, in fact, this collaboration often results in changes to the original design. In order to makes this process efficient and enjoyable, the design should be kept in an official prototype. This way, there is always a single source of truth that acts as the specification for the project.
This is especially important in a team setting where different engineers may have to swap responsibilities (think vacation, think maternity/paternity leave, think family emergencies, think shifting company priorities). If one of your fellow engineers has to drop into the middle of your ongoing development effort, you don't want them to have to start reconciling a prototype with screen-shots and Slack messages and old emails.
NOTE: I am not necessarily saying that a prototype has to be kept up-to-date as the development diverges from the original design (see Mistakes above) - I don't believe that is feasible. I am only saying that if the designs are presented in an official prototype, it gives the Designer a way to centralize the evolution of that design in a way that is most easily consumed.
Mistake: Giving Estimates of Work for Anything More Than a Month
Let's face it, you - the engineer - are horrible at estimating how long a design will take to implement. But this isn't completely your fault. You are always asked to give an estimate when you don't have all of the facts.
Asking an engineer for an estimate before they've begun to write code is like asking a designer for an estimate before they've begun to ideate on a feature. An estimate is always given at the point in the project in which you have the least amount of insight.
If you assume - and you should - that your estimates are going to be wrong, never estimate out more than a month of work. And, to be honest, even a month is a long time. Try shooting for two-weeks. When you keep your estimates small, and for only a subset of the project, it gives you an opportunity to demonstrate accuracy along the way. If a project is going to take longer than anyone expected, it's better to see the time-line slip sooner than later.
This is why it is so important to come up with a phased development and deployment plan (see Mistake above). The sooner you can start to deliver value to the user, the less important the accuracy of estimates becomes.
Mistake: Believing That Browser Support Means Pixel-Perfection
Every product comes with a set of browsers that your team is committed to support. But, "support" does not mean that every browser experience has to be exactly the same. Enforcing extreme consistency increases the cost of development and needlessly limits the value that you can offer to your users.
As an engineer, it's your job to figure out what "support" means for a given browser. This often means that you have to "design" a degraded experience for some browsers; which is fine if that degradation happens gracefully.
Closing Thoughts
We may all have different titles; and, we may all work in different parts of a company. But, at the end of the day, we are all designers in our own right; and, we all work for and must advocate for the user. In that respect, we are all the same. But, we do bring different skills and perspective to the process of product development. And one of the greatest values that you - as an engineer - can give to the user is to remember that your design insights are important.
At some point in my career, I've committed all of the mistakes above. I've gotten really good about fixing some of them; and, continue to fall prey to others. I hope that by codifying these mistakes to paper, I will remember to take action next time.
I doubt this list of designer-developer hand-off mistakes is exhaustive. If you've run into any that I've missed, I'd love to hear your thoughts in the comments.
Reader Comments
This may not fit in exactly with your article, but as a smaller company, a mistake we have made repeatedly (and still do) is assuming a feature or change is small enough it doesn't need a full design phase.
When a single person is responsible for the entire feature (including the design), it's easy to feel that since they are acting as the designer, they can just jump off an build it, and feedback provided after the code is done.
In reality, it almost always takes more time to build it first, then make lots of changes based on rounds of feedback. It's much better to take the extra hour or so to mock it up quickly, get feedback, and then hit the code. Even for something that seems easy on the surface.
There's still a line where something doesn't require separate design and code phases, but I've found it's a lot lower than one would expect. These changes need to be something you can knock out in minutes-to-a couple hours of work at most, so quick they act as the design phase.
Of course now we tend to make this mistake because we think something will be tiny, and it grows into something bigger (and better for the product).
@Phil,
That's super on point. I know for sure that we've experienced that as well. To some degree, this is the risk we opt into when we try to make the development very iterative (ie, build a little, deploy a little, build a little, deploy a little). While it can deliver value to the end-user faster, the true scope of the project is not always obvious from the onset.
This actually just happened to me a few months ago. I was building a feature for an internal team that was, at least at first, a super simple - essentially glorified - ToDo list. And, in a few days I built out the database scheme, put together some simple CSS style, a few CRUD-style pages, and kablamo it was live!
Then, the team came back and started to ask for additional functionality like automated notifications and historical records and special security requirements. This lead to database schema changes, scheduled tasks, HTML email design (OH MY!), and a host of other things.
And suddenly, the work that felt like it would take about a week ended up taking like 2-months. Of course, no one on else on my team had planned for his level of "appetite", which means that there was lots of unrelated work that was scheduled and needed to be side-lined while this scope-creep was dealt with.
So, all to say, I 100% agree! Doing a little more design up front, a little more sanity-checking, can go a long way to get everyone on the same page.
In my experience, perhaps the most fundamental problem is that there is a "handover" in the first place. Phil already alluded to that, but thinking that the design phase "ends" and the development phase "starts" seems in my experience to be the most dangerous assumption.
In the worst case, this ends up in situations when eg. alpha and beta testing results in error tickets that are essentially design flaws disguised a sw errors. Without the involvement of the design(ers/team), these will all be fixed as "sw bugs", often resulting in even worse design problems.
So in my experience, the best way to handle this is to ensure that the development team has access to and active involvement from the deisgn(ers/team) throughout the development process.
@Håkan,
I completely agree. Dove-tailing with your point, I think that building a feature with iteration helps with this as well. Work with the designers to figure out what "phase 1" should be. Then build it, deploy it, get some test users on it, and review with the Designers. Then, figure out what "phase 2" should be based on the prior experience. Not only does this generate solutions based on the most education, it also keeps the teams working collaboratively.
I have been trying hard to champion this idea of iteration at work. People are slowly coming around. It's very hard for people to see their vision evolve rather than seeing it in one big-bang release, even tough the end result - from my perspective - is almost guaranteed to be better.
@Ben,
I agree with your view on iterations. They will happen regardless, so why not plan for them?
One of my "definitions" of a iterative process is one that invites and encourages change. If the process makes change difficult (red tape, no access to design skills, negative attitude and "shoot the messenger", etc), then the process will in my view encourage sub-optimal outcomes.
This is not to say that change should be nilly-willy, just that the person asking for a change should never be shot. Perhaps the suggestion is not approved or passed, but everyone should say "Thanks for bringing this up" afterwards :-)!
@Ben
Got a lot of insights. As a developer, I could relate myself to many of them. Thanks for the insights. Will keep these in mind & try to make the designer-developer hand-off better in our project as well.
Once again, thanks for the blog post! :)
@Håkan,
Absolutely. One that I tend to see is that a project will go on for so long that most of the people who were there at the start aren't even there anymore; and people don't stop and ask Why we're even doing things the way they are. Projects just have a momentum that no one questions.
Change should happen and time passes because we have more and more info with which to make decisions.
@Vineeth,
My absolute pleasure :D I'm glad that some of this was able to strike a chord in you.
You points are very insightful and I will share them with my team.
As a Designer, I cringed a bit at the "Do not ask for permission! Do what you think is right; and, then ask for forgiveness." But then, you go on to say that it's important to explain why you did what you did.
I have been in countless situations when the Engineer doesn't do anything. Designers can't illustrate every possible thing in every design. It just wouldn't be a good use of time. We should also be able to trust that the Engineer knows what she's doing.
Any project that creates innovation suffers from the fact that humans cannot tell the future. If you see something, DO something. If we DON'T DO anything and there is a bad outcome, we missed an opportunity to change things for the better; loss. If we DO something and things get worse, we know what made it worse and can correct for the mistake; win. If we DO something and it rocks the house; win! Product Managers, you can chalk up that first win to research.
DON'T DO = loss
DO = win, win