Whether you are starting out a new project or simply adding features to an existing one, there is a critical step in the process which usually causes some friction: the “Handoff”. It is considered the action of passing over the current state of the project’s design to the engineering team so the development process can start.
And that couldn’t be any more wrong.
What is commonly seen as a baton pass in a relay race should actually be compared more to a rugby match, where the team runs at the same time, backing up whoever is leading the charge. In this blog post we are considering the term design not only as UI or UX but as an architectural concept where the team designs collaboratively instead of only waiting for the designer’s input. Getting used to this idea of design as a team is not an easy task, here are some tips that can help you implement this format:
Handoffs? More like Hands-on
Design doesn’t end when development starts, and development shouldn’t start when design is delivered. The Handoff is not the finish line, it is the road. Start collaborating with your team as early as possible, let them know what is on your mind. You can ask your team some of these questions to begin the designer-to-developer flow:
- Are there any back-end or front-end constraints that I should know of?
- What are the main points the development team is going to work on first?
- Is there anything I can share from the start that the team can use as a base?
Speak the same language
Agree on the terms used for the key concepts of the design, by getting team members to acknowledge the established terminology: Components or Widgets, Sliders or Carrousels, Toggles or Switches, etc. This way you’re making sure everyone’s using the same language. Optional: capture this in a document and share it with all the members of the team, this way it will be easier to remember these key concepts using the proper terms.
Check your team’s work – and yours
Most designers will usually agree that their role is to assure the frontend honors the constraints established by the design. You are more than just a supervisor, you should be also willing to constructively critique your own work. Be the first one to notice if what you delivered meets the expectations, even if your client has already approved it. What truly makes a product shine is not how fast and easy the design can be built, but the ability to evolve and adapt to the feedback given by all parties involved. Your first reviewers will be the developers, they are going to share their opinions and most likely will point out flaws that need to be fixed in order to make the design more scalable and re-usable. Take advantage of these opportunities to get closer to the best version of your design.
Prototypes are not almighty
Even if you create a functional prototype, it is hard to visualize the flow between all the parts of a completed design. Only when implementation starts, we can appreciate how things behave when they are connected and sharing data among them. These transactions are part of the design process too and because they are not logical until the components are alive, it is hard to detect those edge-cases that will mostly appear during a QA session. You’ll most likely have to redesign and adapt to these changes – and that’s perfectly fine. Regardless of your experience designing, you’re still human, and you can’t possibly know everything from the go.
Get familiar with your team’s work
You certainly do not need to know what is the difference between Angular and React to create a great UI design, but it will indeed help you and the project to have a better understanding of how much that 3D parallax video slider you’re designing is going to slow development down. Also, you don’t need to ask developers about everything, there is a trick to this: when you are designing something, think of how a user is going to interact with it. Is it easy to explain without moving your hands? If you didn’t immediately think “yes”, ask your nearest front-end buddy about it.
Think easy design
Your development team will be thankful not only for not adding shadows, bezels and opacities to everything, but in the long run, a simple, easy to develop design is going to be easier to polish as well. This reflects in a nicely built interface and a better user experience. Short reminder, if your design can’t be built, it won’t meet any user needs.
While this is not a design guidebook, there are a few last words on the topic that deserve being written: working in a comprehensive environment is not only good for the product you are building, but also healthy for the human beings working on it. We get stressed and tired when things are not clear, so even if it takes longer, even if you’d rather not be bothersome, always take some time to make sure everyone is on the same track regarding your design. Think of your team as part of the great user experience you want to achieve because, as a matter of fact, they are.