Products that require both design and engineering find an inflection point in their lifecycle that can cause confusion, delay production, and add multiple headaches further down the road. Specifically stated, that point is when the thing that is designed must now be made.
Transition from concept to realization is tough. It’s no wonder the hand-off meeting can be a dreaded occasion for both developers and designers. Airy concepts must come crashing down to reality. Bad news is often broken in these meetings, sometimes resulting in disagreements, complicating a working relationship and immediately putting the build on the wrong foot.
How can we, as both designers and developers, mitigate these risks and foster a more inclusive workflow that ensures the final designs are not only beautiful, but functional and developmentally sound?
Tip 1: Priorities
“‘That’s hard to build’ versus ‘That’s not my design’ is immaterial when you’re focused on ‘Let’s ship this thing.’“
Our respective work can seem like the most essential work in the world, but we shouldn’t let that cloud our judgement about who we are making these products for. For the agency, it is our clients, but in a grander sense, it is the end users. Each decision we make needs to lead with the end user in mind. Our work has the potential to impact millions of people and this responsibility informs the hierarchy of importance we assign to each decision. Any type of consideration should be fundamentally subservient to this. It is the nature of our business.
Tip 2: A Cohesive Team
“As a developer, understanding what the problem is we’re trying to solve, helps answer some of the questions about why I’m building the thing I’m building, which is very motivating for me.”
Segmenting teams based on deliverables is not ideal. Even if development is not involved in the early day-to-day project activities, keeping all teams informed during the product development cycle will head off rude awakenings of technical impracticalities. Conversely, even for projects in which a client has assured the team the internal designs are “code-ready,” it’s good to let your internal design team validate the assumptions. Not only is there value in having a second team’s eyes on designs, but often the design team will have a good idea of development’s capabilities and make design arguments that support development’s stance. We’re firm believers in the enmeshed design/development team hybrid model, and it’s been successful for us specifically for this reason.
Tip 3: Specs, Specs, Specs
“There have been jobs I have been on where I’ve had to take rasterized bitmapped images to make vector assets.”
It is a great time to be making digital products. The support afforded by modern digital tools such as Zeplin and Avocode makes digital product velocity lightning fast and allows quicker and cleaner file hand off. However, that efficiency has come at a cost. As recently as five years ago, design handoffs included not only actual redlines, but spec sheets. They seem to have gone the way of design briefs, which is a shame. Cloud-based links are now the norm, but even tools that include room for detailed notes and design systems are rarely used.
In the interest of keeping everything unified and speedy, we’ve sacrificed some of the less obvious yet essential practices that ensure clearer communication. If you’re a designer who is preparing to handoff files, make sure you include not only basic redlines, but also the following:
Content Matrix
This may not be the designers responsibility, but making sure content is in usable forms (copy-and-pasteable text, usable file formats sized correctly) and has the ability to be tracked and validated by multiple parties is an essential part of a build. You’re not ready for development yet if this step is not complete.
Technical Expectations
Spec sheets should, at a minimum, contain a broad overview of the technical expectations for the product’s features. Ostensibly, the development team will have a good idea as to expected functions, but not necessarily the location of function triggers, cross-functional actions, and features that are story or case-dependent. Laying these out in clear language will be a boon to not only the developers, but the entire product team, and serve as a good reference document going forward.
Full Responsive Versioning, Including Device Expectations
I’ve been shocked to learn that some designers do not give their developers fully responsive comp sizes. At a bare minimum designers should provide complete desktop, tablet, and mobile comps, as well as error states, form states, and empty states. Bonus points for flex fulcrums, such as where the padding increases, and by how much. One Formidable developer’s request was even more on point: “Most useful is to tell the developer what you are basing these sizes on.” Knowing the make and model of each intended device the screen size being is pulled from can inform the developer about expected optimizing and scaling.
User Stories/User Flow Map
Including a (hopefully) previously generated user-flow map will align the development team with the expected architecture of the product. Even more importantly, if the naming conventions are adhered to, this helps development understand the screens design provided. Context for error states, empty states, and the like will save many headaches. The aggregate time spent figuring out where a design fits into the grand scheme of things can be hefty.
Palette and Color Story
A complete color palette, for both colors and situation colors (like error states), must be provided; don’t expect the developer to infer from existing elements what colors mean, and where they should be applied. Part of a designer’s job is to give the developer tools to solve small problems on his/her own. Explaining what colors are used why and when is a perfect toolbox for this.
Complete Typography
The typographic support provided should not only outline (and provide files for) typographic choices, it should also outline type hierarchy and use cases for any speciality formatting.
Examples of Motion and Animations
Most modern digital products have some sense of motion or animation endemic to them. Motion storyboards, gifs of the animation, or ideally, prototypes of the movement are essential for the developers’ success. Our team prefers to use AfterEffects with Lottie from Sketch files for our animations, but there are multiple excellent tools available these days.
The use of spec sheets should not be a last resort of validation and argument resolution, but a source of agreed-upon truth for the entire product team.
Tip 4: Get Yourself a Remarkable Hybrid
“Part of your role as a developer is to make adjustments along the way.”
Ok, you don’t have to call it a Remarkable Hybrid or a “Unicorn,” but this person is a unique type of digital product expert who both knows code AND truly understands the fundamentals of design.
Even in the most planned-for products there will be gaps—it’s the nature of making things from scratch. By understanding the designs, and being able to make educated guesses about designer intent, as well as understanding the technology enough to implement changes on the fly, hybrids can bring the two sides of the rope together and tie a neat knot. These individuals are a valuable component in any digital product team. If you don’t have one (or many), hire some now.
Tip 5: Use the Right Tools
“The ideal tool would be a something that creates real usable assets, but we’re not there yet.”
The most prosaic advice offered is also the most obvious, but must still be said: Use the right tools for the job. The host of lightweight, development-ready design tools is legion, and while some are better than others in generating actual usable CSS objects, they are all angled for digital development. Make sure your assets are as lightweight as possible, and scalable. There’s no reason to be scaling bitmapped images 1x, 2x, and 3x anymore, except for the occasional graphic, and if you have to, current design trends, from gradient overlays to image patterns all work towards the goal of not making a digital product overly weighty.
In Conclusion
There is no magical solution to a flawless and error-free design-to-development handoff. Errors and miscommunications will still happen resulting in pushed deadlines and compromises. However, using the above protocols will minimize your risk and you can get back to doing what you are good at.
All insights and quotes provided by Paula Lavalle, Carlos Kelly, David Earl Duncan, and Ryan Ray, members of the Formidable Design and Development teams.
