Hey, Designer, do you know why front end developers hate you?

Alisa Smelkova
Ace for Engineering Leaders
4 min readJun 20, 2019

The way designers and front-end developers work is broken.

As a design lead, who had some severe tension with the front end department I know what I’m talking about.

A typical case:

You just imagined some great interface, analyzed use cases, researched your Google Analytics, and here it’s: your ideas are embodied in a great piece of the interface.

You give it to your front end team and wait for implementation. Then the front-end drops you a link to test your interface: you anticipate…click…and finally have 5 stages of depression, because what you see is far from what you planned…

  • typography
  • proportions
  • margins

So many small insults, that you open task manager and angrily type 500 hundred visual bugs of HIGH PRIORITY.

In the meanwhile…

On the other end of the conversation, front end developer, who has recently finished some (as he poorly thinks) good work, has no doubt what a bag full of bugs you prepared.

And she finally sees a list of bugs and he can’t stand. He put so many hours to the work that is smashed. And all these “constructive” critics don’t work, because it’s so much to change, so that’s why front end hates us.

It was our team a year ago.

This is a vicious circle of hatred. But I could tell you how to change this.

Pull Production: What we‘ve learned from Toyota

It turned out that building apps are no different from building cars.

In manufacturing exist 2 types of production: Push system and Pull System.

The story I told in the previous part is Push System. It simply means you made you work the way you think it must be done and PUSH it to the next stage, in our case, it’s frontend developer.

The idea of a pull system is then front-end developer PULLs your work to the next stage.

To make it easier to grasp, consider that front-end developer is your client and she gives you requirements on how files must be organized:

  • formats
  • icons
  • descriptions
  • margins
  • etc

So this is the main difference that you design not only for end users, one of the users of your design is a front-end developer who needs your design to be prepared.

Here is how you design looks for end users vs front-end developer.

This is a unified margin system.

It’s the way how front-end developer should receive a design file if you use the PULL system.

Remember Explicit is better than implicit, this approach gives your UI to look better systematically and not based on someone ‘eagle-eye’ abilities.

3 things you can use in UI Design to make front-end developers love you.

  1. Create UI Kit (always)

In the world of front-end development, you design is deconstructed and constructed again.

It means that he looks for all common components between pages: buttons, cards, header, dropdown, inputs, and whatever.

And here is a fact: Front-end developer is not the creator of the UI. It means that the chance she misses some of UI logic is 100%.

So help your front-end developer and give him a UI kit. Here’s Vectorly UI Kit.

2. When you create components don’t miss states.

The state is a case of how a component may look. Some big components in your interface can 10–20–50 states and if you don’t show it, that front-end developer does it his way, at the results in many cases may be questionable.

Here are all the states of the skill card component on https://vectotly.team

3. Provide explanations to all your interfaces

The purpose of an interface, how it should work, anything that you find will make your interface better understood.

We are knowledge workers, it means that to work effectively we should understand what we do in order to concentrate our mental power.

If you give explanations to your interface, it increases the productivity of front-end developer and her affiliation to the final result, because she understands the logic and purpose behind the UI.

So designer, from this day 1 you are a writer as well ;)

I hope you enjoyed reading.

--

--