The **Design Checklist for Front-End Developers** is an exhaustive list of elements which Web Designers and Front-End Developers need to take into consideration to facilitate their collaboration. The following elements are a mix between known practices and new elements based on a long experience analysing web designs.
- 1. Design requirements
- 2. Analysis and pre-work phases
- 3. Validation
- 4. Development phase
- 5. Before production
Tip
⭐️ I've just launched a new project for UX developers about patterns, feel free to check it out! ⭐️
In case you are looking for a list of all elements you need to have/to test before launching your site/HTML page to production, take a look on the → Front-End Checklist.
When comes the moment where developers discover new web designs, before converting them to code, some important elements may be missing. The Front-End Design Checklist is a tool for Front-End developers and Web Designers which aim to help both to work in a seamlessly way.
You can share that checklist to Web Designers to ensure time will be saved at the delivery time or you can use it to review all elements delivered by the creative team and ensure everything is correct before digging into the code integration.
- Ensure all points are taken into consideration by the Creative Team
- Having a document where Web Designers and Developers can rely to ensure a better communication and coherence in the way they interact.
- Because it's easy to forget some important elements when you are pushed by short timelines
- Avoid discovering issues after the creative team is already working on another project.
- To show the complementary work between a Web Designer and a Front-End Developer
Designing a website or a webapp requires following some rules and taking into consideration that the project is not only a graphic project but a web project too. The next sections are crucial for any web project.
-
A grid is explicitly provided in the design, and the details of the grid are present in the technical specification (width, gutters, number of columns…). The Web Designer can keep the grid in a transparent layer and use it on all his project.
ℹ️ Guide Guide is a plugin for Photoshop that can help you easily build your grid.
ℹ️ On Sketch, you can use the integrated “Make Grid Tool” to design your desired grid.
-
Be familiar with the grid system you’ll use on your project. Most of the time, some options (like alignment, offsetting, nesting…) are ignored by the developer and tend to be replaced by manual padding or margin unnecessarily.
-
Before working on each components of your website, you can build every templates used in the creatives only with the grid classes. Building the structure before everything else, will facilitate your work afterwards.
<div class="container">
<div class="row">
<div class="col-sm">
<!-- Let empty at first -->
</div>
<div class="col-sm">
<!-- Let empty at first -->
</div>
<div class="col-sm">
<!-- Let empty at first -->
</div>
</div>
</div>Additional Resources:
- All colors used in the creatives are named ($gray-light, $gray-dark, $green) or accordingly with their use ($body-background, $body-copy, $text-paragraph…). They can be exported in an ACO file (if use Photoshop or on a symbol page for Sketch) and shared with the developers.
-
The different color state of some elements (like buttons, links, inputs...) are defined and worked in the context of a light or dark background and with a light or a dark text.
-
All or the most important/used colors are accessible in the design to allow a fluid navigation on the website/webapp.
Additional Resources:
- 🛠 WCAG - Contrast Checker
- 🛠 Color Safe - accessible web color combinations
- 🛠 Coolors.co - The super fast color schemes generator
Fonts are an essential part of every design, they shouldn’t be chosen without discernment. Choosing the wrong font for a project could have financial and legal impacts.
It is recommended to ask your client to buy these fonts to avoid possible future issues and take into consideration the condition of use. Some webfonts are limited in terms of pageviews and can’t be hosted (Understanding Webfont Licensing Structures).
-
The fonts for desktop (TTF or OTF in general) and the webfonts, in WOFF, WOFF2 and TTF format were provided (in a Zip file or given access to the website where they were bought).
ℹ️ TTF format for desktop is not the same than TTF for Web.
Resources:
-
Fallback font stacks were specified in a document (ideally the Style Guide) to the Front-End Developer.
Resources:
-
The total weight of the all webfonts don’t exceed 1-2 Mb (all variants included: italic, bold etc).
-
As far as possible, all texts are provided in the proper language instead of dummy texts in English (Lorem Ipsum and affiliates).
ℹ️ In case of a multilingual website, always ask yourself how the design can react if the text is longer than it was previously define. Remember that Web Designers use to create perfect designs and don’t always think about possible issues or situation with too much text.
Additional Resources:
- 📖 Web Font Optimization | Web Fundamentals | Google Developers
font-displayfor the Masses | CSS-Tricks- Rhythm in Typography | improve legibility, readability, and visual hierarchy
- All links have a default, hover, focus, active and visited state clearly defined (the Style Guide is the best document to specified these).
- Alternate views of all navigation states (hover, active/current page).
-
A favicon image with at least 512px X 512px is provided in PNG format. The generation of all the others Favicons can be easily done with online tools.
Resources:
-
All icons are provided in SVG format, each in the same square dimension, in black and in a separated folder.
Resources:
-
The name of each icon starts with
icon-and is entirely in lowercase (without any space and using dashes to separate each word).
Additional Resources:
- All forms possess a title that can be used as a legend
- An example of the different states of all input fields were provided (at least focus and inactive/disabled state).
- All error messages were provided, the text (eventually in a separated document) the position and the color are clearly identifiable in the creatives and consistent. Some messages should be different according to the error. Resources:
- Indicators of required/optional fields are provided.
- The primary and secondary buttons are clearly identifiable and are used following common practices. Resources:
- An example of the different states of a button were provided (Normal, hover, focused, pressed and inactive state).
- Buttons with built-in loading indicators are provided and can be applied to any button.
Additional Resources:
- 📖 Design Better Forms – UX Collective
- 📖 Design Better Input Fields – UX Collective
- 📖 Designing Perfect Text Field: Clarity, Accessibility and User Effort
- 📖 Button UX Design: Best Practices, Types and States – UX Planet
- 📖 How To Design Better Buttons — Smashing Magazine
- 📖 Buttons in Design Systems – EightShapes – Medium
-
The mobile version of the design is provided before or at the same time of the desktop version.
If the “mobile first” thinking was not followed by the creative team, some irregularities and inconsistencies may appear between the mobile and the desktop version. Check and flag these issues before starting the development of the project.
-
The tablet version of the design in certain cases should be provide too.
Additional Resources:
-
All components designed on each page were created with the component based approach (Atomic Design). If not, issues can occur in terms of performance, maintainability of the project...
Resources:
-
A Style Guide needs to be provided listing all elements, components, styles, dimensions. Some boilerplates like UX Power Tools can help saving time and keep consistency in the designs.
Additional Resources:
- 📖 Style Guides – Design + Sketch – Medium
- 📖 The CodePen Design Patterns and Style Guide
- 📖 Lonely Planet Travel Guides and Travel Information
- 📖 Styleguide
Sometimes, the creative team needs to add new pages or modules in an existing project. They should have or create a list of all existing elements and try to use what is already there. Having a Style Guide already created can save hours and ensure consistency of the project.
-
For all websites, the web designer needs to provide at least 2 PSD (mobile, desktop and eventually tablet) or at least 1 Sketch file which needs to be delivered with the dimension below (if you have Photoshop CC 2015 and above, I recommend using artboards).
ℹ️ Some web designers could eventually create multiple PSD corresponding to each components used and import them in a single PSD as “smart layer”. In that case, you’ll have multiple PSD linked to one or two files. In the case of Sketch, since the libraries exist since version 47, it is possible to link multiples files with symbols ……..
-
The creative files are cleaned before delivering to developers (empty and unnecessary layer needs to be removed to avoid large files).
-
The 404 error (and eventually the page 500 error) page were designed.
-
All popins, popups and alert boxes were designed and can be enable throw layers of compositions.
Additional Resources:
- Layer compositions are used to show each different pages, if multiple views are provided within the same PSD. It’s an easy way to avoid confusions and check that all elements are correctly organized.
Before starting the analysis and the pre-work phases and after receiving the creative files, you need to check some important elements:
- Which version of Photoshop, Sketch is used? Some features are specific to some versions of Photoshop or Sketch. It is important to flag any issue regarding this as soon as possible.
- Is the width of each PSD or artboard correct? In case some space is added on each side of the design, check the exact width of the website.
- Are the creatives using too much “box-shadow”, “linear or radial gradient”…? Don’t forget the .... Effect which can have impacts on the browser painting performance.
- Is a sitemap / breadcrumb provided to understand the architecture of all pages and their dependencies?
- Does the website needs to have retina images?
It is recommended printing some (or all) of the pages you have on an A3 format (or A4 if you don’t have this format). Because of the height of the page. you’ll probably need to print some designs on multiple pages.
I can’t imagine a better way to start than analysing creatives on a paper with a pencil (or different colourful pencils chosen to highlight different type of information).
-
Define the structure of the pages, the headers, the sections, the articles, main, footer outlining these on at least one printed page.
-
Find all the headings that structured a page, ensure the
H1is not on the logo and that the logical order is followed. Most of the time, the H1 for the homepage will be hidden with CSS but needs to keep its legitimate meaning. That analysis should be done with the help of a SEO specialist in case you have one in your team. -
Try to find and regroup similar components giving them an individual name regarding their functionality and not just their context. For example, naming a tab system “
-
Most of the creative elements can be done using CSS. Today, it is not recommended to create any layout element using images. Any simple graphical element like buttons or borders should be done in CSS to avoid performance or scalability issues.
-
Find some possible lack of coherence, in case a Styleguide was not provided by the creative team, it’s your responsibility to ensure that every graphic element belong to a possible category (Buttons, Typography, Sliders…). It’ll help you to create your own CSS / Sass architecture or to identify which component you’ll need from an identified CSS Framework.
- According to the specifications, plugins needed were defined in an early stage. Having a pre-list of possible plugins before starting the development can help the developer to stay focus and not spend too much time in doing research during the development phase. Obviously, some plugins may not perfectly fit and will be changed accordingly.
Additional Resources:
- 🛠 Awesome JS
- 🛠 BestOfJS
The validation phase is when everything seems to be ready to be integrated. The client, in general, validate the creatives without waiting for any approval from the technical team. As exposed in the Design Checklist, it is essential that developers ensure the quality of the delivery before starting to code.
-
All medias can be cut and saved before starting the development phase. That can help you to avoid back and forth between your creative software and your code editor.
-
The image folder has a clear architecture where you arranged the layout's images. It is important to stay consistent between projects in general. Defining a structure for that folder and a naming convention can be helpful.
You can find an example of a possible structure with prefixes used to recognise each image appurtenance.
.
└── images
├── background
├── banners
├── icons
└── layout- A naming convention is used like adding prefixes to differentiate types of images, all images used for background can be prefixed by
bg-, icons byicon-, hero banners byhero-orbanner-and so on.
Before launching your website, be sure to review all your pages using the Front-End Checklist!
The Front-End Checklist is also available in other languages. Thanks for all translators and their awesome work!
- 🇨🇳 Chinese: JohnsenZhou/Front-End-Design-Checklist
- 🇪🇸 Spanish: eoasakura/Front-End-Design-Checklist
If you have any question or suggestion, don't hesitate to use Gitter or Twitter:
This project exists thanks to all the people who contribute!
All icons are provided by Icons8