Collaboration across product disciplines is fundamental for success. Efficient collaboration, where individuals feel part of a whole and, at the same time, recognised by their own individual strengths, is essential for sustained success, long-lasting teams, satisfaction and, ultimately, better product outcomes.
I will lay out some of my thoughts on the collaboration between digital product design and engineering, highlighting strategies that made a change (for the better). These are based on my own experiences and written from the perspective of a practitioner and leader.
I hold this particular collaboration close to heart, as I’ve been an engineer for a significant part of my career, and have seen — first-hand — the benefits of working closely with engineering from the start.
When you think of a multidisciplinary team, it’s likely that you see the role of engineering as building the stuff (when focused on delivery) and assessing the feasibility of the stuff (when shaping or defining what solutions you’re focusing on). Both of these roles are fundamental and, I think, fairly uncontroversial. Therefore, I’d like to focus on the other aspects where collaboration between design and engineering might be less familiar.
User research
I will start with user research. Your team might be conducting interviews, designing and deploying a survey, planning a diary study, or relying on desk research. While these are probably not activities that you’d associate with engineering, I’d advocate for some (optional) involvement. Positive outcomes I’ve seen in the past:
- Having an engineer sit in on an interview with a user is a great way for them to build empathy towards the end-user — it’s incredibly motivating to know who you’re designing and building a product for.
- Sooner or later, engineers will have to make product or design decisions. Maybe someone with executive power will come and request something ASAP. Perhaps someone will overestimate or underestimate the level of design involvement required for a specific ticket. Maybe a security incident has just occurred, and a fix needs to be rolled out faster than you can write a ticket. That’s something that I’ve learned to accept — it’s just going to happen. Design systems help with this, by systematising UI design decisions and providing a clear answer to questions like “which building block should I use?”. I’d propose that, similarly, having exposure to user research and being aware of the main user research insights will empower engineers to make better design and product decisions.
- The best research employs a mixed-methods approach, where both qualitative and quantitative data are harnessed to produce more insightful findings. Have you thought of measuring how snappy your app or website is? Something like the Core Web Vitals might help. And who would be best positioned to help you implement, measure and track these metrics over time?
User interface design
This one can be summarised as “don’t throw it over the wall”. “It“ being a design, a solution, a specification, or any artefact that guides implementation.
I’d say that, as a concept, most would agree that this is a good idea: throwing something over the wall is a known anti-pattern, well beyond the realm of digital product development. However, we still often fall prey to this, and don’t involve engineers as frequently and as early as we should. And then we suffer the well-known consequences: miscommunication, misunderstandings, designs that are out of touch with the reality of implementation, disruptive last-minute changes, costly development cycles, etc.
As cliché and as fluffy as this might sound, I’m a strong advocate for a mindset of collaborating with engineers on a design, rather than preparing a design to be implemented by engineers. It’s hardly revolutionary thinking, but — again — I’ve seen it being forgotten (mostly because we’re rushing, people are busy, etc). Collaborating with engineers to produce a design solution will yield better outcomes and prevent common pitfalls. Here’s an incomplete list:
- Increased consistency. Some designers have a great talent for spotting inconsistencies. Engineers, on the other hand, don’t need to rely on a special talent for this: the nature of their job means that deviating from the standard is inherently costlier; it requires more effort to implement a deviation from a component than to use the component itself. Anecdotally, I have also found (and please excuse the generalisation) that engineers usually have a high sensitivity to consistency — perhaps a combination of traits like attention to detail and deconstructing solutions into their individual components is common among engineers. Anecdotes and generalisations aside, I do think that collaborating with engineers early in the design process will result in increased consistency.
- Better cost-benefit decisions. Design solutions require a certain effort to be implemented and maintained. It’s not uncommon for alternative solutions to provide 80% of the benefit for a much lower fraction of the effort. Suggesting these solutions requires awareness of the alternatives, alongside a good grasp of the necessary effort — guess who’s uniquely positioned to assess this? Exactly: engineers.
- Streamlined communications. Perhaps designers refer to it as a “dialog” and engineers call it a “modal”. Is it a “text field” or an input? Inconsistent language is fertile ground for misunderstandings and inefficient communications. Having engineers and designers collaborate often has the potential to normalise language over time (alongside the potential for stronger bonds to form!), streamlining communications and reducing ambiguity.
- Increased design coverage. From the happy-path funnel vision that often ails designers (i.e. focusing only on the default, error-free flow) to complex combinations of variables leading to edge cases, it is common and natural for designs to be incomplete. While I think that 100% completeness, with full coverage of edge cases, isn’t the best goal to have in mind, I have seen that collaborating with technical folks will naturally bring some non happy-path scenarios to the forefront of our attention early on.
All of the examples above (which, again, are not meant to be a comprehensive list) will ultimately lead to better designs. And better designs lead to increased efficiency: a missed edge case that needs to be addressed, a solution that needs to be redesigned because it’s too costly to implement, an inconsistent pattern or component, all of these are costlier to address while the implementation is inflight.
Finally, I’d also argue that genuine collaboration leads to a sense of co-ownership and co-authoring of the solution. It’s just nicer for engineers to implement something they contributed to rather than a finished spec, thrown over a virtual wall.
