Creating fantastic websites and applications is truly a delight. And when such products come together, it is a humbling experience. Especially when you know you didn't do it alone. Teamwork is at its best when the members augment each other and move toward a shared outcome. It's no secret that web designers and web developers don't always see eye to eye and tend to have different goals that impact the product differently. Something that Design Engineers call the gap.
Being a good designer or a good developer is excellent but doesn't really close the gap. Designers learning to code or developers adding design skills to their CV doesn't help either. So what is this Gap?
Let's paint a little picture
A designer asks to have the header set to a specific size. Points at the screen. ... The developer swivels back to their monitor and sets the header to its new size. Easy peasy. Let's get some coffee!
The designer shrieks.
Not all the headers!
And why has the font changed?
The developer informs the designer that there is only one header to set the value on and that sets it for all of them, and if they want an exception, they should have asked for one. Adding that, they see no change in the font: "Looks the same as it ever did."
Designer: Then we want a header exception and a fix for the font
Developer: So you want a change to have two headers and a fix that we can't see?
Both are talking about the same thing and seem to understand what is being asked; however, they're unsure because their understanding comes from different contexts. How on earth, with their growing frustration, can they hand over the design to have it coded constructively without tech or design debt? This is, needlessly to say, very annoying, and neither reaches the other side of this invisible gap.
This scenario is the same when designers and developers are in separate teams or combined in multifunctional teams. Disciplines have their own language and, consequently, their own narrative. We need to align our stories, our understanding, our goals in a shared and structured way. Usually, we need some help with this.
Going from a product concept to delivering to end-users
Working from strategic goals via design to delivering a shared and intended outcome to the user is complicated and has more to do with managing a product than UX. This is why we see DesignOps, which tries to tie in broader business goals and that the designer can participate in tackling these issues.
Developers write code to provide users with product functionality. As you can imagine, development, like design, is a broad topic and covers many disciplines. In recent years automating the development journey has played a vital part in decreasing the lead time for getting features to users quickly. DevOps enables this and is, unsurprisingly, an integral part of any modern software release procedure.
Plugging the gap
What is usually suggested is that we need DesignOps to intersect and overlap with DevOps and make sure they align the work. Sadly, broadening the knowledge domains doesn't work because there is no code switch, no change in narrative. The gap is actually indicating a missing role.
Enter the Design Engineer. They understand the designer's output to codify, standardize and even automate the solution.
Designers move from idea to a wireframe, a prototype, a logo, or even just a drawing. Developers move from a problem or feature to a coded solution that is solved and released. Both are creative, both are in aid of the end-user. The Design Engineer role is also creative and authors code but systematically translates a design towards implementation in a structured way.
I have never worked anywhere where there wasn't someone trying to close the gap. This role is often filled in accidentally, and companies are totally unaware of the need. Recruiters have never heard of it, and IT consultancies don't have the capability in their roster. We now name the role "Design Engineer" because the gap is widening, and the role has become too complex to not exist.
Who is your Design Engineer?