As front-end developers, our job is, essentially, to turn designs into reality via code. Understanding, and being competent in, design is an important component of that. Unfortunately, truly understanding front-end design is easier said than done. Coding and aesthetic design require some pretty different skill sets. Because of that, some front-end devs aren’t as proficient in the design aspect as they should be, and as a result, their work suffers.

My goal is to give you some easy-to-follow rules and concepts, from one front-end dev to another, that will help you go from start to finish of a project without messing up what your designers worked so hard on (or possibly even allowing you to design your own projects with decent results).

Of course, these rules won’t take you from bad to magnificent in the time it takes to read one article, but if you apply them to your work, they should make a big difference.

Do Stuff In A Graphics Program

It’s truly rare that you complete a project, and go from start to finish while maintaining every single aesthetic mutation in the design files. And, unfortunately, designers aren’t always around to run to for a quick fix.

Therefore, there always comes a point in any front-end job where you end up having to make some aesthetic-related tweaks. Whether it’s making the checkmark that shows when you check the checkbox, or making a page layout that the PSD missed, front-enders often end up handling these seemingly minor tasks. Naturally, in a perfect world this wouldn’t be the case, but I have yet to find a perfect world, hence we need to be flexible.

A good front-end developer has to use professional graphics tools. Accept no substitute.

A good front-end developer has to use professional graphics tools. Accept no substitute.

For these situations, you should always use a graphics program for mockups. I don’t care which tool you choose: Photoshop, Illustrator, Fireworks, GIMP, whatever. Just don’t just attempt to design from your code. Spend a minute launching a real graphics program and figuring out how it should look, then go to the code and make it happen. You may not be an expert designer, but you’ll still end up with better results.

Match the Design, Don’t Try To Beat It

Your job is not to impress with how unique your checkmark is; your job is to match it to the rest of the design.

Those without a lot of design experience can easily be tempted to leave their mark on the project with seemingly minor details. Please leave that to the designers.

Developers have to match the original front-end design as closely as possible.

Developers have to match the original front-end design as closely as possible.

Instead of asking “Does my checkmark look amazing?” you should be asking, “How well does my checkmark match the design?”

Your focus should always be on working with the design, not on trying to outdo it.

Typography Makes All the Difference

You’d be surprised to know how much of the end look of a design is influenced by typography. You’d be just as surprised to learn how much time designers spend on it. This is not a “pick-it-and-go” endeavor, some serious time and effort goes into it.

If you end up in a situation where you actually have to choose typography, you should spend a decent amount of time doing so. Go online and research good font pairings. Spend a few hours trying those pairings and making sure you end up with the best typography for the project.

Is this font right for your project? When in doubt, consult a designer.

Is this font right for your project? When in doubt, consult a designer.

If you’re working with a design, then make sure you follow the designer’s typography choices. This doesn’t just mean choosing the font, either. Pay attention to the line spacing, letter spacing, and so on. Don’t overlook how important it is to match the typography of the design.

Also, make sure you use the right fonts in the correct spot. If the designer uses Georgia for headers only and Open Sans for body, then you shouldn’t be using Georgia for body and Open Sans for headers. Typography can make or break aesthetics easily. Spend enough time making sure you are matching your designer’s typography. It will be time well spent.

Front-end Design Doesn’t Tolerate Tunnel Vision

You’ll probably be making small parts of the overall design.

Tunnel vision is a common pitfall for front-end developers. Don’t focus on a single detail, always look at the big picture.

Tunnel vision is a common pitfall for front-end developers. Don’t focus on a single detail, always look at the big picture.

An example I’ve been going with is making the checkmark for a design that includes custom checkboxes, without showing them checked. It’s important to remember that the parts you are making are small parts of an overall design. Make your checks as important as a checkmark on a page should look, no more, no less. Don’t get tunnel vision about your one little part and make it something it shouldn’t be.

In fact, a good technique for doing this is to take a screenshot of the program so far, or of the design files, and design within it, in the context in which it will be used. That way, you really see how it affects other design elements on the page, and whether it fits its role properly.

Relationships And Hierarchy

Pay special attention to how the design works with hierarchy. How close are the titles to the body of text? How far are they from the text above them? How does the designer seem to be indicating which elements/titles/text bodies are related and which aren’t? They’ll commonly do these things by boxing related content together, using varying white space to indicate relationships, using similar or contrasting colors to indicate related/unrelated content, and so on.

A good front-end developer will respect design relationships and hierarchy. A great developer will understand them.

A good front-end developer will respect design relationships and hierarchy. A great developer will understand them.

It’s your job to make sure that you recognize the ways in which the design accomplishes relationships and hierarchy and to make sure those concepts are reflected in the end product (including for content that was not specifically designed, and/or dynamic content). This is another area (like typography) where it pays to take extra time to make sure you’re doing a good job.

Be Picky About Whitespace And Alignment

This is a great tip for improving your designs and/or better implementing the designs of others: If the design seems to be using spacings of 20 units, 40 units, etc., then make sure every spacing is a multiple of 20 units.

This is a really drop-dead simple way for someone with no eye for aesthetics to make a significant improvement quickly. Make sure your elements are aligned down to the pixel, and that the spacing around every edge of every element is as uniform as possible. Where you can’t do that (such as places where you need extra space to indicate hierarchy), make them exact multiples of the spacing you’re using elsewhere, for example two times your default to create some separation, three times to create more, and so on.

Do your best to understand how the designer used whitespace and follow those concepts in your front-end build.

Do your best to understand how the designer used whitespace and follow those concepts in your front-end build.

A lot of devs achieve this for specific content in the design files, but when it comes to adding/editing content, or implementing dynamic content, the spacing can go all over the place because they didn’t truly understand what they were implementing.

Do your best to understand how the designer used whitespace and follow those concepts in your build. And yes, spend time on this. Once you think your work is done, go back and measure the spacing to ensure you have aligned and uniformly spaced everything as much as possible, then try out the code with lots of varying content to make sure it’s flexible.

If You Don’t Know What You’re Doing, Do Less

I’m not one of those people that thinks every project should use minimalist design, but if you’re not confident in your design chops and you need to add something, then less is more.

Less is more. If your designer did a good job to begin with, you should refrain from injecting your own design ideas.

Less is more. If your designer did a good job to begin with, you should refrain from injecting your own design ideas.

The designer took care of the main stuff; you only need to do minor fillers. If you’re not very good at design, then a good bet is to do as minimal amount as you can to make that element work. That way, you’re injecting less of your own design into the designer’s work, and affecting it as little as possible.

Let the designer’s work take center stage and let your work take the back seat.

Time Makes Fools Of Us All

I’ll tell you a secret about designers: 90 percent (or more) of what they actually put down on paper, or a Photoshop canvas, isn’t that great.

They discard far more than you ever see. It often takes many revisions and fiddling with a design to get it to the point where they’d even let the guy in the next cubicle see their work, never mind the actual client. You usually don’t go from a blank canvas to good design in one step; there’s a bunch iterations in between. People rarely make good work until they understand that and allow for it in their process.

If you think the design can be improved upon, consult your designer. It’s possible they already tried a similar approach and decided against it.

If you think the design can be improved upon, consult your designer. It’s possible they already tried a similar approach and decided against it.

So how do you implement this? One important method is taking time between versions. Work until it looks like something you like then put it away. Give it a few hours (leaving it overnight is even better), then open it up again and take a look. You’ll be amazed at how different it looks with fresh eyes. You’ll quickly pick out areas for improvement. They’ll be so clear you’ll wonder how you possibly missed them in the first place.

In fact, one of the better designers I’ve known takes this idea a lot further. He would start by making three different designs. Then, he’d wait at least 24 hours, look at them again and throw them all out and start from scratch on a fourth. Next, he’d allow a day between each iteration as it got better and better. Only when he opened it up one morning, and was totally happy, or at least, as close as a designer ever gets to totally happy, would he send it to the client. This was the process he used for every design he made, and it served him very well.

I don’t expect you to take it that far, but it does highlight how helpful time without “eyes on the design” can be. It’s an integral part of the design process and can make improvements in leaps and bounds.

Pixels Matter

You should do everything in your power to match the original design in your finished program, down to the last pixel.

Front-end developers should try to match the original design down to the last pixel.

Front-end developers should try to match the original design down to the last pixel.

In some areas you can’t be perfect. For example, your control over letter-spacing might not be quite as precise as that of the designer’s, and a CSS shadow might not exactly match a Photoshop one, but you should still attempt to get as close as possible. For many aspects of the design, you really can get pixel-perfect precision. Doing so can make a big difference in the end result. A pixel off here and there doesn’t seem like much, but it adds up and affects the overall aesthetic much more than you’d think. So keep an eye on it.

There are a number of [tools] that help you compare original designs to end results, or you can just take screenshots and paste them into the design file to compare each element as closely as possible. Just lay the screenshot over the design and make it semi-transparent so that you can see the differences. Then you know how much adjustment you have to make to get it spot on.

Get Feedback

It’s hard to gain an “eye for design.” It’s even harder to do it on your own. You should seek the input of others to really see how you can make improvements.

I am not suggesting you grab your neighbor and ask for advice, I mean you should consult real designers and let them critique your work and offer suggestions.

Let designers critique your work. Put their criticism to good use and don’t antagonize them.

Let designers critique your work. Put their criticism to good use and don’t antagonize them.

It takes some bravery to do so, but in the end it is one of the most powerful things you can do to improve the project in the short-term, and to improve your skill level in the long run.

Even if all you have to fine tune is a simple checkmark, there are plenty of people willing to help you. Whether it’s a designer friend, or an online forum, seek out qualified people and get their feedback.

Build a long-lasting, productive relationship with your designers. It’s vital for useful feedback, quality, and execution.

Build a long-lasting, productive relationship with your designers. It’s vital for useful feedback, quality, and execution.

It may sound time consuming, and may cause friction between you and your designers, but in the big scheme of things, it’s worth it. Good front-end developers rely on valuable input from designers, even when it’s not something they like to hear.

Therefore, it’s vital to build and maintain a constructive relationship with your designers. You’re all in the same boat, so to get the best possible results you have to collaborate and communicate every step of the way. The investment in building bonds with your designers is well worth it, as it will help everyone do a better job and execute everything on time.

Conclusion

To summarize, here is a short list of design tips for front-end developers:

  • Design in a graphics program. Don’t design from code, not even the small stuff.
  • Match the design. Be conscious of the original design and don’t try to improve it, just match it.
  • Typography is huge. The time you spend making sure it’s right should reflect its importance.
  • Avoid tunnel vision. Make sure your additions stand out only as much as they should. They’re not more important just because you designed them.
  • Relationships and hierarchy: Understand how they work in the design so that you can implement them properly.
  • Whitespace and alignment are important. Make them accurate to the pixel and make them evenly throughout anything you add.
  • If you’re not confident in your skills, then make your additions as minimally styled as you can.
  • Take time between revisions. Come back later to see your design work with fresh eyes.
  • Pixel-perfect implementation is important wherever possible.
  • Be brave. Seek out experienced designers to critique your work.

Not every front-end developer is going to be a fantastic designer, but every front-end dev should at least be competent in terms of design.

You need to understand enough about design concepts to identify what’s going on, and to properly apply the design to your end product. Sometimes, you can get away with blind copying if you’ve got a thorough designer (and if you’re detail oriented enough to truly copy it pixel for pixel).

However, in order to make large projects shine across many variations of content, you need some understanding of what’s going through the designer’s head. You don’t merely need to see what the design looks like, you need to know why it looks the way it does, and that way you can be mindful of technical and aesthetic limitations that will affect your job.

So, even as a front-end developer, part of your regular self-improvement should always include learning more about design.

About the author

Bryan Grezeszak, United States
member since February 10, 2016
Bryan is a primarily front-end developer with over a decade of professional experience. He's a JavaScript master and a pixel-perfect builder of visuals and interactive experience. He loves to be a problem solver and has a passion for challenging work. While he specializes in front-end development, he also has capable experience in back-end development and in graphic design which he uses to augment his abilities as a front-end developer. [click to continue...]
Hiring? Meet the Top 10 Freelance Front-End Developers for Hire in December 2016

Comments

Michel H.
Hi Bryan, I really like: "In fact, a good technique for doing this is to take a screenshot of the program so far, or of the design files, and design within it, in the context in which it will be used. That way, you really see how it affects other design elements on the page, and whether it fits its role properly." and I completely agree with it! Thanks for the post!
Ivo Gregurec
"Developers have to match the original front-end design as closely as possible" - when every element in design has decimal value in pixels and none of them is aligned to the grid, a developer have to ask for help from his inner designer ;)
Bryan Grezeszak
That's a fair point. I was definitely going on the assumption that you have proper designs to work with in the first place. If you've got junk designs then I guess point #11 would be "offer to redesign it for the client" :)
Marcelo Carneiro
This got me deep, "I don’t care which tool you choose: Photoshop, Illustrator, Fireworks, GIMP, whatever. Just don’t just attempt to design from your code. Spend a minute launching a real graphics program and figuring out how it should look". LOL.
Dennis Vogel
As a Winforms designer I can offer a little advice. Use a drafting triangle to make sure every control is aligned perfectly. Misaligned controls may not be obvious to the user but they are stressful if you spend hours in front of a design.
Clouds
Good designers/developers don't follow rules, they create rules.
pramodliv1
What's your opinion on this article, https://signalvnoise.com/posts/1061-why-we-skip-photoshop ? They don't seem to support graphic programs.
Bryan Grezeszak
You're absolutely right! However, this isn't targeted at experts, so we're good. This is for front-end developers that, while they may be great programmers, are lacking in the designers side of the equation and need some guidance to better themselves and their work.
Ivo Gregurec
It only happened once so far and to avoid a drama I fixed it up from the shadow and never mentioned until now :)
Bryan Grezeszak
It comes down to a difference in goals. A major theme of that article revolves around "it's not efficient and it's too detail oriented", to which I can only say "correct, great design is NOT efficient (it's actually quite the laborious process) and is very detail oriented...but it's worth it." We just have different end goals. He espouses speed of development over detail-oriented aesthetics, whereas I'm teaching people how to take extra time and pay attention to detail in order to get better aesthetics. And the difference does show. The first thing I did was click the username of the author, which took me to a page that showed a new design of their product...a design which had very elementary mistakes in design (alignment, spacing, poor visual hierarchy, etc) that are exactly the kind of things that typically get solved by designing from a graphics program instead of from the code. But I'm sure it was much quicker to develop that way...so I'm sure he's fine with that. That's just his set of goals clashing with mine. So, in the end, the difference of goals accounts for the difference in workflow opinion. I, personally, would not recommend taking his attitude to most high-end client work...it only works for him because he's in an organization that has decided to have those values (speed of development over aesthetics). If you're doing high end work for clients (or want to be doing high end work for clients) I'd say quality over quantity wins the day. Especially for front-end devs that are getting a designer's great designs that a company has already invested a lot of money into creating...take the extra minute to not screw them up! Most of that time is already spent, no point in going backwards just to save a few minutes now!
Im So Meta Even This Acronym
It still gives me the shiver when I remember the term, 'pixel accurate sitebuild' :)
Ionut Cirja
I totally agree, as long as the design is ready for the developer when he starts his work. Otherwise, fuck the design.
Augustin Riedinger
> Match the design. Be conscious of the original design and don’t try to improve it, just match it. This is a very narrow-minded view. In some (rare) cases, the design *is* pixel-made and the designer just built it without an inch of possible modification. But most of the time, many things are missing. A PSD is a still image, while a web interface lives. It is impossible for a designer to anticipate all the different states and constraints that the interface will output while building the design. As far as I'm concerned, I'd say a good front-end dev needs to understand the designer's desires to being able to extrapolate them where things aren't defined by the designer, or simply don't make sense. In a small and fast iteration environment like startups, if a round circle with the designer can be avoided by trying something that make sense, *this* is precious time saved!
Bryan Grezeszak
That particular quote is a summary of a section, and that section is about matching the aesthetics of the original design in any additions you make. E.g.: the checkmark that you add to the clean and minimal design made by the designer should not be purple and spotted and look like a dinosaur...even if it does look kinda cool, because that doesn't match the aesthetic of the design. In other words: match the design, don't try to add your own improvements in the form of purple dinosaur checkmarks! It's your job to make your added checkmark match with the rest of the aesthetics, not to make your checkmark the most amazing thing on the page and take center stage. This is also related to the concept of tunnel-vision that is discussed as well. The idea (Iike you say) that the designer can't anticipate everything and that the dev needs to understand the design and how it works so that they can apply those concepts elsewhere is actually pretty much a (if not <em>the</em>) central theme of the article and presented in many places within it. :)
surfyogi
Be a robot. Just do as you are told. Never question the designer, But actually, humans need sounding boards, bouncing ideas from one to another. Examining and considering the various options, iteration, it's all part of the process. You don't sound very flexable in your thinking on this issue.
nemrut
IMO, developers should not be worrying about the minutiae of design which is covered in more the 80% of this post. If they did, they would be designers and never have time to do development.
Bryan Grezeszak
Considering it's an article that makes its premise as being for front-end developers that don't have very good design skills and therefore need some rigid rules to follow in order to not screw up designs...yes, it gives rigid rules that are based around not screwing up the designer's designs. It's all about context. This article is for a different point in the learning process than where you are. When you're a beginner you start out with rules that help you stop completely sucking. It's only as you grow that you learn to bend them and eventually break them...but someone still has to teach some rules for those at the shallow end of the pool :)
Bryan Grezeszak
I disagree! If they don't then that minutiae won't end up reflected in the final product and then there's no point in the designer having worried about it in the first place! What's the point of the designer figuring out perfect spacing and alignment if the developer is just gonna do it close enough in the final product anyway? Our job is exactly that: to understand the minutiae so that we can recognize it in the design and make sure it makes proper transition from design to product. Great products are made when a designer that can figure out all the minutiae to make a design great teams up with developer that can understand and work with that design minutiae to make stuff that looks as great in the final product as it looked in the PSD, even across changing content and modified layouts for new pages, etc. And yes, that does mean that the dev has spent some time learning parts of being a designer. This is a great cheat-sheet of what parts, specifically, pertain the most to that end goal for the front-end dev.
Lucas Medina
These are some really nice advices for front-end development. I usually follow them very faithfully, except for the first one, which I'm actually looking for it. Nice post! Also, I built one of the images at the post with HTML and CSS ;) http://codepen.io/lucasmedina/details/yOpBXo/
Paco Mt.
Clipped to one of my Gibbon playlists: https://gibbon.co/pacster/user-interface-design-basic-advice-for-developers I would like to add that my best experiences collaborating as a designer with other coders, are commonly those times where the coder teaches me new and better ways of displaying the UI (via animation, small improvs, optimisation, and so on). Thanks for the article!
John Mark
Thanks for advice = ) www.yourapphero.com
Rasin Bekkevold
Outstanding post! Thanks for sharing your great experience through this effective and helpful tips. http://goo.gl/6h21fq
comments powered by Disqus
Subscribe
The #1 Blog for Engineers
Get the latest content first.
No spam. Just great engineering and design posts.
The #1 Blog for Engineers
Get the latest content first.
Thank you for subscribing!
You can edit your subscription preferences here.
Trending articles
Relevant technologies
About the author
Bryan Grezeszak
JavaScript Developer
Bryan is a primarily front-end developer with over a decade of professional experience. He's a JavaScript master and a pixel-perfect builder of visuals and interactive experience. He loves to be a problem solver and has a passion for challenging work. While he specializes in front-end development, he also has capable experience in back-end development and in graphic design which he uses to augment his abilities as a front-end developer.