UI design implementation guideline for engineers (and designers)

How to manage the precarious designer-engineer relationship.

Adnan Puzic
UX Collective
Published in
7 min readMar 25, 2020

--

We’re all familiar with that never-ending battle or rather, the Cold War between engineers and designers. You create a functional UX, a beautiful UI, and the client is excited. Then, after a couple of months when development has reached completion, the feedback you get is totally unexpected. Instead of praise for your excellent work, everyone seems disappointed, and sure enough, when you take a look — your design not only looks unimpressive, it’s also super clunky to use.

So why is there such a gulf between what you delivered and the final result? Unfortunately, what it comes down to is that your vision and carefully planned design simply doesn’t align with the engineer’s implementation.

Why is there a problem?

So, you shared the Figma link, Sketch file, Zeplin, Invision, and Avocode, and delivered a comprehensive style guide containing all UI elements and all possible states. You did everything right, even down to sharing that inspect mode link with all the CSS. Yet still, the result is unsatisfactory. So why does this happen?

Engineers (developers) are a special kind of people. They are meticulous and hard-working folks always looking for smart ways to solve problems and are forever determined to discover new ideas, refine their processes, and make even more significant improvements. They are under constant pressure to deliver slicker, smarter solutions to tight deadlines in the highest possible quality.

If designers are the artists, then engineers are poets, just like Wordpress says:

Code is poetry.

Never has a truer word been spoken, engineers are masters of the new era poetry. For someone who doesn’t know anything about development, code can appear both complex and nonsensical. At best, a person might think what’s in front of them is a bunch of hacking code.

Developer coding on a computer.
Developer “hacking”

The reality is, however, that engineers are masters of their specialty, and conquering code takes huge amounts of energy, dedication, and focus. For anyone that understands coding, observing a good piece of HTML or CSS code is a privilege, it’s no wonder they say, “code is poetry.”

When designers hand over their work, it can be challenging for engineers to pick up on the small pixels, the tiniest of tweaks that we designers are sensitive to. An engineer’s primary goal is generally to “make it work.” They don’t have the capacity or sensitivity to spend too much time or focus on small pixels and alignments that are invisible to the average person’s eyes.

How to solve the problem?

Generally, there isn’t a ‘one size fits all’ approach for designer-engineer communication. The best approach is to ensure clarity and to manage expectations during every step of the process. This kind of problem requires a systematization, which means each part of the process should be defined in detail.

Just like when an architect designs a building, it is he who creates the vision, but it is the construction workers who bring that vision from paper to life. So it follows that we designers and engineers need to have that process defined too. The initial step towards resolving issues is arming oneself with the right knowledge. In short, a designer should at minimum know the basics of front-end coding.

It makes sense for an architect to know statics, restrictions and any potential issues before they begin their design, right? Similarly, therefore, a designer must understand what restrictions there are in coding that might impact their vision. If you know what’s possible to code and what’s not, what requires 10 days, and what requires 2 hours to build, you will be able to design accordingly, and also know when you are being taken for a ride.

A less reputable engineer might respond: “Man, this is possible but requires at least ten days to put together,” when in fact, it would only take one. If you aren’t knowledgeable, then you may end up making slow progress and having to extend deadlines just because you didn’t arm yourself with the right knowledge from the get-go.

Of course, this is a two-way street, and a good engineer should be familiar with the fundamentals of design such as spacing, paddings, font sizes, colors, and so on. With that knowledge, they will be able to understand the design and comprehend what it is that the designer had in mind. From this, by using their experience and talents, a developer will leverage the design to something that works even better than you could have hoped for!

Systematization

A useful approach in solving the designer-engineer problem is to observe the typical obstacles in their communication with one another. We are all familiar with the usual workflow: Designer creates the UX and the UI, designs a style guide with all UI components and their states, and delivers everything to the engineer via Invision, Zeplin, Avocode, Figma or any other tool available.

The engineer receives all the assets and starts to think about the structure and functionalities he needs to implement the design. During that process, very rarely do the designers and engineers commit a kick-off meeting to go through the plans and all the specs that follow. Why? Because on first glance, everything seems straightforward both to the designer and the engineer.

Every engineer has a unique way of translating those neat pixels into code poetry. Unfortunately, because there is no standardized implementation method, this increases the chances of the end product failing expectations, because even a small missed detail may seriously affect the user experience.

Here is a high level example of systematization in architecture:

Systematization graph in architecture.
Systematization in architecture

As you can see in the graph above, every step is strictly defined and depends on the previous one. Each is assigned to a specific role. Some steps can enter a loop and remain there until the criteria required to move to the next one is fulfilled.

Let’s go back to the architect analogy for a moment. During construction, supervisors have a critical role. Until all their criteria are met, and they are entirely satisfied, the completion of construction will not end. There are many supervising roles during the development and creation of a building. The architect, who designed the building, plays one of the essential functions, and satisfying his or her requirements is very important to accurately translate the original idea into a real functional, tangible thing.

Similar principles can be applied in UI/UX and development, from a high level this is a proposal of systematization:

Systematization graph in UI/UX design and development.
Systematization in UI/UX and development

In design, the “architect” is the UI/UX designer, and to reach the best possible result, the designer should behave as a supervisor and have much more authority and decision making power. Constant reviews, updates, and refinements may be necessary. However, this shouldn’t be considered as a “battle” between engineers and designers. Both should contribute, using their strengths, and find an effective way of communicating to ensure that their shared goal of delivering a seamless user experience can come to fruition.

Communication naturally plays a vital role in the process. It’s just not enough to showcase the design and assume everyone is on board and clear. Engineers need to know all the details and receive precise instructions — because 0.1 seconds can make a difference between something feeling natural to something terrible. Because of this, designers need to think beyond just delivering the design itself.

Every component of the application is essential even if it seems obvious and logical; it is worth having a discussion, so everyone is absolutely on the same page. The designer, in some cases, should provide animated examples of how complex components interact with the user to ensure complete clarity.

Designer — engineer relation

Good design usually gets left on the table, and it is the responsibility of designers to build excitement and trust early in the process. We live in a world where phrases such as, “no we don’t need that” are excruciatingly common. Because of this, designers need to spend more one-to-one time with engineers and share ideas, as well as both their positive and negative implications for the end-user. Communication, education, and a shared vision are crucial and will result in smoother collaboration and a better result for everyone involved.

Some engineers have a fantastic understanding of design; they will receive it, write a bunch of lines of code and take it to the next level, creating something even better than you ever imagined.

Engineering should not be a blocker, engineer should notice and leverage those “little big details” that make all the difference when it comes to creating a truly breathtaking design.

Key Takeaways

  • Introduce systematization and define every step of the process.
  • Designers need to think beyond just delivering the design itself.
  • Designers should spend more one-on-one time with engineers.
  • Engineers should be familiar with basic fundamentals of designs.
  • Designers should act as a supervisors and have much more eligibility in making crucial decisions.
Communication and teamwork

The engineer — designer relationship is not one that needs to be fraught with stress and tension. If you are clear from the outset, set out expectations and shared goals, and find ways of collaborating that work for both of you, and communicate effectively from the start, the process could even, dare we say it, be an enjoyable, fruitful and satisfying one!

Sign up to discover human stories that deepen your understanding of the world.

Free

Distraction-free reading. No ads.

Organize your knowledge with lists and highlights.

Tell your story. Find your audience.

Membership

Read member-only stories

Support writers you read most

Earn money for your writing

Listen to audio narrations

Read offline with the Medium app

--

--

Published in UX Collective

We believe designers are thinkers as much as they are makers. Curated stories on UX, Visual & Product Design. https://linktr.ee/uxc

Written by Adnan Puzic

UI/UX, web, and graphic designer with more than eight years of professional experience in this industry.

No responses yet

What are your thoughts?