When working as a front-end developer, sometimes I was handed designs created in what I’d call a print state of mind. Both printed materials and websites can be thought of as two-dimensional images that should convey a message in an aesthetically pleasing manner, but that’s where similarities end.
The tools used by designers are often the same for print and web design, which can lead to ignoring the differences between the two. In this post, I’d like to highlight a few things that designers should keep in mind when designing websites.
If you’ve been designing for the web for some time, the following might seem like simple common sense. But you’d be surprised. While I originally wrote this post mainly for designers who were just starting out or transitioning from print to web design, it never hurts for even the most experienced designers to keep their developers in mind.
When the project requirements state that the user should be able to fill out a contact form, it’s easy to think that a couple of text inputs and a big button will do the trick.
In reality, this is just the beginning.
The obvious minimum is a success state for when the form for was submitted correctly. But the internet is a very complex thing, things can break at any moment, and users make mistakes or simply do not understand the interface. An error state, clear validation messages, and disabled states for fields and buttons of the form are a must.
Forms are a very clear example, but the designer should also be aware of a non-ideal state in any dynamic or interactive element. When designing a news feed, remember that there may not be any news items. The design should also indicate if the empty state is the result of an error or whether there are simply no items to display.
Catching user flow errors just by looking at the design takes some experience. Fortunately, we humans are very good at telling and understanding stories. A good user flow is like a good story — by looking at a single view (a scene, so to speak) the user should be able to tell at which part of the process they’re at, how did they get there, and how to get back if need be.
Getting lost in a digital interface is very irritating, and coding illogical interfaces is even more vexing. Before handing off the designs, spend a moment just telling someone (it can be a rubber duck!) the story of your design. Where does the user click, why, what should happen and how does the design handle whatever should not happen.
If you want to take it up a notch, create a digital prototype or an animation. A picture may be worth a thousand words, but an animation — you guessed it — can be worth even sixty thousand words per second. Check out Principle, Figma, or if you have more time, do your own research based on this big list of prototyping tools. A clickable prototype can save a lot of development time later on, as changing the prototype will always be less time consuming than rewriting code.
A style guide is one of those things that are extremely beneficial, yet very often overlooked. For a developer, it provides a clear overview of all the components used in a project, and for a designer, it’s a library that can greatly speed up ongoing development of a project.
It also helps to think about a project as a design system, not a just series of visually related views. Once a system is complete and documented in a style guide, adding new views or components is much easier. On top of that, onboarding new team members with a style guide in hand is a lot faster that walking them through all the possible views.
Check out MailChimp’s and Lonely Planet’s style guides for some quality examples.
Your users are probably looking at your site on a phone, and very possibly on a spotty 3G connection. It’s easy to forget when sitting in an office with super-fast wifi while looking at a 27″ screen, but outside, mobile is eating the world.
There are three key points here: screen size, bandwidth, and performance.
It’s not only about the small screens, it’s about any conceivable screen, up to huge 4K screens on which most websites look just… tiny. When designing, forget about any fixed screen size. The interface should look great regardless of the screen size and it should adapt to the constraints — otherwise you’re forcing the user to adapt, and they don’t have time for that.
Remember that last time when you tried to look up some website on a terrible café or hotel wifi? That’s everyday reality for a lot of people. Think twice about high-resolution full screen background images or loading more than two custom fonts on a website.
And last but not least — performance. Your high-end computer probably has no problems dealing with those very interactive and stunning websites that win all the awards. But remember that some of them will not even load on a lousy phone that might be the only internet-connected device for someone else.
Sometimes there is this unsettling feeling after the development of a website is finished — that even though the developer did everything pixel-perfect, it just looks kinda worse than the original design. And then the developer sees that all the text on the design just aligns perfectly with everything else and that every picture has the perfect colour and composition.
You can’t blame the designer for making it pretty — after all it’s their job. But sometimes designers forget that content changes and some people have surnames that will take two lines of text. It’s best to let go of this imaginary land of perfect-length copy and create designs that will look good in any configuration. That is the real quality mark.
Technology is improving and more and more things are possible, however keeping elements aligned to a grid will not only make development much faster, but also make the site more reliable on older browsers.
And when you choose a grid size, stick to it. One of the more annoying things a designer can to to a developer is changing the grid size just for one component or page. As is the case with style guides, consistency is the key to happiness.
Design files can get messy. Nevertheless, they are documents that are the primary source of information for a developer. Named and logically grouped layers, especially when they describe different component states, are a sign that the designer respects the developer’s work.
As for the images, a good rule of thumb is that if something can be exported as vector graphics in SVG format, it should be. SVG files are way lighter than raster images, and they can be manipulated via code (e.g. icon colours).
I hope I haven’t hurt anyone’s feelings by suggesting that some designers are bad at their jobs — it’s not about that. Front-end is a constantly changing field, and even the programmers have a hard time following all what’s happening. It’s hard to require of designers to know all the quirks that come with modern web standards and practices. I hope this post will help to bridge the gap between the design and the code.
Additional links:
Install LogRocket via npm or script tag. LogRocket.init() must be called client-side, not
server-side
Learn more →
$ npm i --save logrocket
// Code:
import LogRocket from 'logrocket';
LogRocket.init('app/id');
// Add to your HTML:
<script src="https://cdn.lr-ingest.com/LogRocket.min.js"></script>
<script>window.LogRocket && window.LogRocket.init('app/id');</script>
Hey there, want to help make our blog better?
Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
Sign up now
Learn how to manage memory leaks in Rust, avoid unsafe behavior, and use tools like weak references to ensure efficient programs.
Bypass anti-bot measures in Node.js with curl-impersonate. Learn how it mimics browsers to overcome bot detection for web scraping.
Handle frontend data discrepancies with eventual consistency using WebSockets, Docker Compose, and practical code examples.
Efficient initializing is crucial to smooth-running websites. One way to optimize that process is through lazy initialization in Rust 1.80.
