Bridging The Design Execution Gap

A humble response to Patrick Morgan’s The Design Execution Gap.

After reading Patrick’s piece, the AVP of Product Design at Southern New Hampshire University’s internal innovation office asked for my take on the last two questions he put forth. Specific to our own team and use cases.

• As a designer, how might I level up my technical skill to share more ownership of the last 10% of design execution?
• As a developer, how might I architect a more approachable and inclusive way to craft and maintain application styling?

Here goes…

Get out of my head Patrick.

I agree 100% with his take, so why am I hopping on my soapbox? Because this was a request from a peer. As I interpreted it, asking how I found success bridging that gap previously and, most importantly, how we, as a Product Design and Development team inside SNHU, could do the same.

For context, I was lucky to be previously embedded into three separate, tightly integrated design and development teams over the past 12 years. Each time, I straddled that wiggly line between software development and design.

Here, in that middle ground, let me restate the value and importance of effective collaboration between designers and developers. We can achieve great success in our projects through frequent and open dialogue. But effective collaboration isn’t just about talking — it’s also about understanding each other’s perspectives and skillsets.

Documentation is not conversation.

No matter how thoughtfully written a Jira ticket from an animation design request is, essential information needed for execution may often be lost. I recently reviewed a development ask with ample video references and bezier functions. The designer wanted to know if this information was sufficient for an external resource to execute. I didn’t believe so. It was enough to get “good enough” work, which is only acceptable for proof of concepts. A 30-minute conversation between them and myself, followed by a 30-minute prototype, exposed every piece of missing information.

Collaboration is not a concession.

As a developer, it’s essential to understand the value of design and how it can contribute to the success of a project. Developers can create a more approachable and inclusive environment for crafting and maintaining applications by working closely with designers and valuing their contributions. It’s on us to show empathy while defending established standards and existing policies.

Consistent vocabulary is vital to improving collaboration and streamlining the development process. Design tokens are just one form of shared language. Like learning any new language, the best way to become fluent is through practice. In other words, talk more, learn more. Embrace the cyclical nature of alignment and clarification. These exchanges become less frequent the more fluent everyone becomes. Designers feel seen and included in the process, and developers feel secure and safe in making decisions on execution.

I don’t care how often we chat, pivot, or full-on refactor a project. If we meet the deadline and the experience is rock solid — it was all worth it.

Leggo Your Ego

I’ve seen resistance to this from both sides, but most notably from a particular class of developers. Those who treat HTML/CSS as if it were base ten math and only showed up to class for Precalculus. The foundation of front-end development isn’t this dumb subset of scripting and markup languages. It is the soul of every product we build. It defines what things are, should be, and can be.

As a front-end developer, I remember when you were measured by how precise your UI was; How strictly it adhered to design specifications; How performant it was in the browser; How many browsers could it retain its fidelity?

Software engineering teams sometimes treat the fundamental front end as an afterthought. It’s not entirely their fault. Design tools have helped to bridge the gap by providing UI developers with values, tokens, and serviceable CSS. But that’s all just a tiny piece of the puzzle. The DOM elements used, their source order, interface transitions, and so on require as much attention as the designers themselves poured into it.

Designers: It’s a two-way street. The browser is not Figma. Sometimes, what you envision — flat-out doesn’t work in practice. For you to trust that recommendation, you must also trust the developer delivering it. Building and maintaining that trust takes time, and I’d argue is best accomplished through action. Everyone involved needs to get humble and vulnerable. Screenshare, pair, and iterate often.

UI developers should advocate for the design vision while keeping designers honest and consistent. When we find an issue, either in the Figma file or in the user’s actual experience, we might be surprised at how often we are also met with empathy and trust.

Stop Being Clever

Patrick put forth another question in his article.

[We] need to find a way to re-expose the stylistic portion of the front end to the people who both deeply care about it and have the skills to fine-tune it. But how?

Front-end frameworks like React, Vue, and Angular amplify this. Even Bootstrap and Tailwind can contribute to this confusion. In the document object model, anything can be anything. This is also amplified by hyper-creative; and ill-informed developers. Who either don’t care or are excited by writing UIs with as little of a specific language as possible. With the right combination of HTML attributes, creative CSS, and enough JavaScript, what you see when you inspect a web page can leave a seasoned developer scratching their head.

But that doesn’t belong in our work. Like design that pushes certain edges. Reserve those creative endeavors for personal sites, sandboxes, and community challenges.

Our work, what we create for the countless internet denizens, needs to be as straightforward and scalable as possible. I don’t want to overprescribe a specific fix. As a community, we tend to be evangelists for whatever works for us. But teams have found success here. Whether you take the simple but manual step of adhering to detailed code style guides, leverage an entirely new “designeloper”… “devigner”… (let’s workshop it) tool, or restructure your teams to embrace front-end developers with a UI specialization; It can be done.

Practice essentialism

If our foremost measure of success is the user’s experience, our interfaces should be rock-solid well before we are concerned with how best to make things “functional.”

That may be the core answer to the original question. To be true to our mission. Focus on what we can control, and control the heck out of it. Pixels, milliseconds, semantics, and accessibility matter. Let’s work together to ensure there isn’t a gap to fill.

Originally published at https://antoinebutler.com.