There are situations when front-end developers complain about designers. You might hear: “Their mockups are unclear! The indents are different, There are headings of different sizes and shapes, the elements don’t match the grid. I don’t want to work with them!” Designers, in turn, complain that the front-end developers corrupt their layouts.
These complaints are complementary. If you start to understand the root of the problem, then both could be and generally are guilty. So, how do you prevent a quarrel between a designer and front-end developer? First, It is necessary to understand that in most cases, both need to change their stance.
Grids are designed to organize all the elements on the artboard. Thanks to the grid, vertical and horizontal layout rhythms are created. The design becomes orderly and systematized. Initially, everything is designed “by eye,” then the mockup is built into the grid system.
You can use a 10, 8 or 4-pixel grid. Lately, I’ve been using an 8-pixel grid. By using this size and multiples of 8 pixels for blocks, indenting, line spacing, icons and other interface elements you get a logical and visually consistent interface.
Very often it happens that a designer doesn’t show and doesn’t even tell a front-end developer about hover effects (what they’ll look like when users hover or click on an object).
In cases such as these, often front-end developers create hover effects the way they imagine them in their heads. Don’t make them think for you.
You can display the state of objects as I have in the example below:
Standardize all objects on the layout. If the title is in Open Sans 1.2em, then let it be Open Sans 1.2em everywhere. Do the same for buttons, paragraphs, leading and indenting. I don’t mean that everything should look the same. You should understand that the more typed objects you have, the easier it is for a front-end developer to work with them.
Too often a front-end developer gets layouts with layers that are chaotically located with no titles. The more understandable the layout is for them, the faster the mockup becomes an excellent site or application. Of course, this is also very helpful for designers too. When there are a lot of layers, it’s obviously more convenient to navigate layouts if they are clearly named. To do this, rename the layers according to their meaning. Use common terms such as button, title, footer and so on in the layer names. Group all the layers that are part of the same component together and follow the sequence from top to bottom. The header should be at the very top, the content in the middle, the footer below, etc.
Collect all the typed elements of the system on a separate page, such as:
If you’ve previously standardized objects, then you can easily transfer them to the UI guide on a separate page. Thanks to this, the front-end developer can quickly prepare the database and collect the site like lego blocks.
If you provide a static layout for a front-end developer, try to leave as many comments as possible on the design elements for any questions that may arise. Don’t be lazy. Take the time right away and provide answers for questions that are likely to come up in the future. Most programs for creating interfaces have really convenient ways to make comments. At WeAreBrain, we use Zeplin and InVision — really great programmes.
It’s very important to evaluate the artistic work of the designer before the development of the page. You may think that this or that object will be difficult to build, but first, try understand why the designer created it this way, and whether the picture would be as seamless if you removed or changed the object? Ask the designer about their version, and in most cases, they will be able to explain to you why they used this particular solution, and whether it is possible to change or delete it without a loss to the layout.
Sometimes, when building a page, front-end developers ignore some “little things” and don’t create them. They may be convinced that the designer just got carried away, and designed unnecessary elements. A good designer studies the product, works on the elements and composition, then places everything on this layout and creates a single picture. If you experience any doubts about the changes you think need to be made to the design, always coordinate with the designer.
Discuss the design. After receiving the layout, evaluate it and tell the designer where and why you need to make edits. Clarify controversial issues: maybe the designer deliberately destroyed the rhythm of the composition, and it wasn’t just negligence. If the button, link or picture doesn’t have a hover effect, ask what it should look or where it is drawn. Discuss the controversial points, it will not only improve your work, but will also improve the work of the designer.
Front-end developers often have to receive layouts in uncommon formats, which makes it difficult to see the dimensions, colors, shadows or padding. Decide together with the designer which program is best for you both. In the case of creating user interfaces, you have a choice between Adobe products (for example Adobe XD), Sketch, Figma or Framer. Select one or more programs and decide how you will collaborate.
The most important thing for two front-end workers is to create an understanding of each other’s skills and way of working. And of course communication! As you’ll find in any relationship, there must be consistent and well-established communication. If you start implementing these suggestions one by one or all at once, you’ll definitely notice that working together becomes much more exciting because you’re creating awesome things as a team.
An executive’s guide to AI and Intelligent Automation. Working Machines takes a look at how the renewed vigour for the development of Artificial Intelligence and Intelligent Automation technology has begun to change how businesses operate.