A Framework To Ensure Front-end Engineers and Designers remain friends for very long time!

(or how using expensive tools like Invision or Zeplin, MixPanel, Mockingbird and a lot of style-guides will make you the next billion dollar designer. Or at least a cool person in the eyes of the front-end developer master-race)

Is it just me or is it hard to cultivate a maintain smooth relationships between designers and a front end engineers? It is hard right? Especially when they’re not in the same room, office or location! Tensions can rise quickly, and so whining about one another.

Designers are great people, they spend hours pushing pixels on the screen. They make things look pretty and functional so that us, users of many platforms, can feel at ease and be productive from the get go.

Front-end engineers are cool folks and can experience tough times when interacting with designers! Making sure that the design is reflected in a real, usable interface (and that it is connected with a back-end of some sort) with all the bells and the whistles that designers spent hours crafting.

Ultimately what they create together makes a visitor into a customer and a customer into money.

Money — runs businesses!

However…sometimes things don’t work out — the designer’s vision is poorly rendered by the developer, the designer and developer’s relationship takes a turn for the worse…

I sat down with an extremely experienced UX/UI/Designer that I was lucky enough to work with in Paris and this is what I learned!


1. The Tools And The Versioning

When a designer creates a screen they often works in a tool of their choice such as Photoshop, Sketch or Illustrator. They release these documents to developers and it should be obvious that the front-end person should be able to open that file. I personally do not have a copy of Photoshop on my laptop how do I make sure I can gather the metadata of every element designed ?

Don’t do this.

We’re in 2017 and you should use the tools that you have been given by industry to fix this problem. No need to purchase expensive PSD


Long are the days where you do back and forth between designers and developers, exchanging heavy weight files with weird naming like the ones depicted in the image above. Use version control!


When you design something beautiful, be it a styleguide or a whole page or a particular components of your design, doesn’t it suck that you have to tell the designer all the spacing and sizes? This tool takes all the pain away from the process.


Just like in treasure hunt you need a map, a designer needs to produce a map for the developers which carefully explain (or let the developer figure out easily) the how elements of the UI should be represented.
I like to believe that a developer should be able to quickly identify

  • The fonts used (typography)
  • The colors scheme
  • The gradients and images
  • The spacing between elements and layout
  • The characteristics of the UI, like their style, borders, radiuses for buttons and forms

Trust me all these elements including spacing are really annoying for a developer to figure out without seeing the “map”.

A style guide (here is one for YELP to give you a real example) for the project with UI elements & patterns is really important. If a designer doesn’t provide one, the developer will have to make stuff up. That is usually not a good idea.

Sometimes 3 pixels are the reason a designer and a developer won’t look at each other in the eyes, ever again — true story.

Hear me out designers, dumping a JPG/PDF of your artboard or a screenshot of you Adobe Illustrator window won’t cut it for a job well done.

2. Lorem Ipsum Is Tragic

The copywriter often works with the designer(s) — but the copywriter rarely works with the developer(s). Making sure all the text is in place before handing a design off to a dev is a big plus. No one likes to go over the same work twice and replace generic “lorem ipsum” with text that looks like doesn’t belong there because there is too little or too much of it.
More importantly a developer needs to be able to space text and columns on a 2D area.
When the text is bogus, a lot of chaos is created. When everything else fails use the Pirate Ipsum generator yarrrrrr

3. Paint a pretty picture

A sitemap should be handed to the developer before the start of the development phase. Take a few Post-it notes and sketch out on a wall what the site will look like, which pages are more important, how does the navigation work. Play around with different orders and hierarchies. Then send this information to the dev.
More often than you would imagine, the developer is asked at the last minute to add a bunch of “marketing” pages for this or that reason.

4. Go Wire-framing, then go further

Wireframe, shows what each part of the site should convey and how elements are placed in the bigger picture

Wire-framing isn’t designing. A wireframe is not sufficient to bring a product to life.

I used tools like Balsamiq in the past and even Google Drawings.

The advantage of stuff like Moqups however, is that a lot of the elements are drag-n-drop, no need for you to reinvent the wheel and draw everything by hand. This alternative here is more lightweight and cleaner to use for smaller projects.

Some people even get to the point where they want to draw stuff on a whiteboard or paper. What are you nuts? What are you going to do, take a picture and then send it to your friends?

Let’s be honest we’re in 2017, let’s use HTML5-ready webapps and stay clear of Flash-plugin-enabled stuff.

As a developer you will love wireframing, it’s like designing without the fluff. As a designer wireframing allows you to have peace of mind.
When a designer and a developer go wireframing, they can quickly communicate in the same language. As a developer I know how beautiful simple, minimalistic designs are. As a designer I love the fact that I can quickly show some ideas to these smelly devs (jk — devs are always wonderful 🖖).

5. Show responsiveness

Designers should work for responsive layouts. What elements of the design will be resized or broken down when the mobile user looks at your page? Each element should ideally be sticking to a corner based on the parent container.


Four thumbnails A, B, C, D.

How should these boxes align in mobile view?

What should the front-end developer code these thumbnails to look like when the page is seen on a mobile screen. Is this the answer?

Or should we stack them vertically?


As a front-end engineer, I wouldn’t know what the best way is, unless you told me, of course!

And let’s not forget…what item should not be visible on the UI when on a small screen?

How do you tell your developer about these ninja items that appear or disappear based on the resolution and width of display used if not by communicating it to them in a clear way?

6. Show or describe animations

How are developers going to animate the expandable menus and buttons if you do not communicate them? Showing an hover state or a click state for a certain UI element is a good practice, even better if you are really picky would be to add the type of animation that should occur between the two states in CSS terms.

Don’t be a sore player, use a tool like Codrops — here’s an example

If you have custom built animations, it is probably better to have a one-on-one, designer and developer, to clearly define the chosen animations and then give them a name to refer to them so everyone is on the same level!

7. Grab the real feedback

Feedback is crucial. Especially when you’ve implemented your design into a useable user interface.

With Mixpanel you can track any interaction that happens on the UI, you can create beautiful reports and funnels to understand what actions happen on a determined page depending on your business goals.

Not only it’s easy to set up, anyone who can copy paste and use Query Selectors will be able to use Mixpanel effectively — after a developer has loaded the JavaScript library.

If a button is never pressed, a flow is never followed, as a UX designer this valuable insight can help you craft the next iteration to be better. Without data to back you up, you’re nobody.

8. Sketch and Iterations

Iterate, Iterate, Iterate.
Also use tools that don’t suck. Nowadays the cool kid on the block is Sketch. It has a lot of plugins and integrations and you should at least give it a try.
The only thing I hate about Sketch is that my trial never ran out. I am not sure what’s going on.

Sketch works wonderfully with InvisionApp, like I mentioned earlier. This combo can help you once again, not only because it lets you stay organized with folders and keeping track of all changes but you can automatically sync your mockups and design into the app. With Sketch or Photoshop you can mark which artboard, layers and symbols you want to export and the plugin automagically creates assets for you. Your developers will love you forever. They will never have to open Photoshop ever again on their new Macbook Pros with touchbars and 128gb of SSD space.

Isn’t this the dream?

Only One Truth

Communicate, communicate, communicate. If you’re not communicating your issues and doubts as a developer with the designer (and vice-versa) then you’re doing your job wrong. And remember, communication takes two or more parties, right?