PRODUCT/UX DESIGN
How can designers build better relationships with engineers?
3 approaches to strengthen design-developer collaboration.
--
Collaboration is a major part of a product designer’s project lifecycle. We often overlook how important it is to build beneficial habits that improve our approach to collaboration. It would be wrong to call it a soft skill, since it influences close to every aspect of a designer’s job, though many soft skills can be practiced to make collaboration more efficient and transparent.
Collaboration can take on many different forms:
Working with leadership in an early-stage startup to help drive the company product towards their initial vision.
Discussing business goals with a project manager to ensure alignment with product goals.
Analyzing metrics and user feedback with the research team to validate design decisions.
And any number of stakeholders that help drive the project to its best version.
The collaboration I’d like to focus on is between designers and engineers. This relationship is perhaps the most common and most discussed in the design community.
I will be using the word depends a lot here, because all of these ideas will depend on many different factors that make up a company’s workforce. It depends on the organization’s team structure, the design and engineering maturity of a company, and the level of communication that occurs between departments.
So it depends.
But even then, there are similarities across all companies that allow for these ideas to be shaped to fit all needs. Without question, the two most important foundations for good collaboration are communication and respect.
Without communication, you’re not collaborating at all. You’re making loose assumptions on what works best for everyone.
And without respect, you won’t build trust and compromise. Design is not the driving force behind a product’s success, it’s one part of it. The sooner that idea becomes part of your design philosophy, the sooner good design becomes the norm.
1. Frequency of Communication
When there is a higher frequency of communication between designers and developers, project clarity will naturally improve.
This statement should come as no surprise. If collaboration takes place from the start, then ideas and explorations can be discussed for viability, and you’ll spend less time pursuing solutions that might be unnecessarily time-consuming.
How can you implement this?
Try to introduce engineers into your design process as early on as possible. There is nothing worse (for both parties) than tackling weeks/months of design work only to be hit with a variety of reasons why that solution can’t be developed.
You want engineers with you from the very start when the problem space is still being understood and you are asking the whys. Developers should be there to give their insights, similar to other stakeholders, which allows them to gain an intuition on where a potential solution might be heading. If it’s clear that the potential product solution has implementation limitations, then those concerns can be voiced early on so that a subset of that solution can be focused on first.
2. Is it done done?
I had a great boss that would always ask this question whenever the design team completed a stage of the project lifecycle, he would say, “okay it’s done, but is it done done?” At early-stage startups, it’s always difficult to define what done really means. Processes are still being fleshed out, so it becomes even more vital to have constant conversations with other departments to understand when something is truly done.
How can you implement this?
What that might look like for design is the introduction of a checklist that hits the main points of your ongoing process. Not all of these need to be hit for every task or project, but it provides a good reference point for what a project needs to be done done. You have the high-fidelity screens for desktop but have you finished them for mobile as well? All device types are accounted for but have you prototyped at a high level to communicate the flow? You’ve completed your prototype, is it worth exploring micro-interactions to further the communication of the flow? Have you documented your design decisions clearly? Are the required assets accessible to push the development of your design forward? And so on…
So the primary question is,
Before handing this off, am I accounting for all blockers on my end?
3. A proper hand-off process
A hand-off process can be a great tool to standardize the design-to-developer-transition of a project lifecycle. Similar to a checklist, a hand-off should accomplish predetermined goals, with room to account for variability in projects.
An example hand-off process
I’ll step through the hand-off process we developed in my previous role. This went through a few iterations before reaching a place that worked for design and engineering. I’ll emphasize that this worked for us and at another company, another team size, or another workflow, things may look different.
a. Workspace
One of the three Figma files we worked on was called Workspace. As the name suggests, it housed all the parts of the design process revolving around ideation and exploration. This was essentially a playground to evolve ideas into working high-fidelity screens.
b. Prototype
The second Figma file contained the Prototypes. This is where finalized workspace screens were linked and displayed a proper flow or user journey.
c. Hand-off
The Hand-off file type was the last part. Hand-off would pull the finalized workspace screens as instances and would be shared as a “source of truth” to engineers and other stakeholders. The purpose of this file was to provide a space where engineers could inspect designs without needing to worry about accidental changes, or questioning if they were the finalized version of the countless iterations found in workspace. We also made use of Figma’s documentation feature and gave component and screen explanations on the hand-off file.
d. Design Wiki
All of this was tied into our Design Wiki. The wiki was a hub for all things design, providing resources and assets, component library documentation, and a project status view that showed the state of “doneness” for all ongoing or completed projects.
Don’t forget, it all depends
To emphasize an already stressed point, the ideas shared above are all dependent on the buildup of a particular company. The only real approach to strengthening the design-developer relationship is to remember the two most important foundations for good collaboration: communication and respect.
These beautiful illustrations were done by my very talented friend, Daniela Valdes.
