Skip to content

πŸ’Ž The Design Checklist for Creative Web Designers and Patient Front-End Developers

License

Notifications You must be signed in to change notification settings

UBCCM/Front-End-Design-Checklist

Β 
Β 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

Β 

History

25 Commits
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 

Repository files navigation

Front-End Design Checklist

UBC Front-End Design Checklist

The UBC Design Checklist for Front-End Developers is an exhaustive list of elements which can help developers to analyse and understand web designs and ensure the quality of their Front-End development.

PRs Welcome Join the chat at https://gitter.im/Front-End-Checklist/Front-End-Design-Checklist CC0

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. This checklist has been revised to include UBC specific materials.

UBC CLF: UBC's websites are guided by the UBC Common Look and Feel (CLF). Remember to visit the CLF website while building your site to ensure your site follows the guidelines. The website is a wealth of knowledge, so if you're ever stuck, you can likely find the answer to your question there.

Table of Contents


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.

Why you need to use the Design Checklist?

  • 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

1. - Design Requirements

Designing a website or a webapp requires following some rules. Remember that the project is not only a design project, but a web project too. The next sections are crucial for any web project.

1.1 - Grid system

Grid system

  • A grid should be explicitly provided in the design, and the details of the grid should be present in the technical specification (width, gutters, number of columns…).

    ℹ️ UBC's CLF has grid specifications. Use these specifications in all UBC projects. Designers may want to download an Illustrator template of the CLF, which includes a transparent layer that shows the grid.

    ℹ️ Guide Guide is a plugin for Photoshop that can help you easily build your grid if you prefer to work in Photoshop.

    ℹ️ 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:

⬆ back to top

1.2 - Colors

Colors

  • All colors used in the design are labeled according to their HEX code or sRGB codes. Talk to you developer about what colour mode they prefer. If you are looking for the HEX codes of UBC's brand colours, download the colour codes from the UBC Brand Site.

  • The different color state of some elements (like buttons, links, inputs...) are defined and work in the contexts of a light or dark background and with a light or a dark text.

  • Ensure that your color combinations meet accessibility standards. It is likely that some of your website users will have a vision limitation, so it is important that colours help their ability to read a site. Check all your text colours early in the process to avoid having to change your design later on to accommodate vision issues. Use the links below.

Additional Resources:

⬆ back to top

1.3 - Fonts and texts

Fonts

UBC has a license to use the font Whitney on any ubc.ca websites. To use this webfont, please send a request for the font on UBC's Brand Site. Please note that you will need to do this for each unique URL address.

UBC has a license for only three weights of Whitney: booke, book italic and semibold.

UBC also allows for the use of Arial and Open Sans on websites.

Resources:

If you are not using one of UBC's webfonts, 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:

⬆ back to top

1.4 - Links and navigation

Links and navigation

  • All links and buttons 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).

1.5 - Images / Icons

Images

Check with your web developer about whether you need to export images at different sizes for each platform (mobile, tablet, desktop), and if you need to export for retina displays.

Also check with your web developer about proper naming structure for images.

Compress your images before sending them to the developer. You can use a program like Kraken to reduce your images' files sizes.

  • If developing a new site, provide 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:

⬆ back to top

1.6 Forms and buttons

Forms

  • 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:

⬆ back to top

1.7 - Responsive Web Design

Responsive

  • 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.

⚠️ The pixel perfect notion is today in a certain way deprecated. Today, it’s impossible to have a design that worked the same facing the multitude of the screen sizes.

Additional Resources:

⬆ back to top

1.8 - Style Guide and component approach

Styleguide

  • 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.

⚠️ In the case where the Style Guide is missing, it's a good practice to build yourself a living Style Guide to facilitate your work. Some CMS like Drupal, for example, have plugins that allow to develop a living Style Guide using Pattern Lab.

Additional Resources:

In the case of an existing project:

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.

⬆ back to top

1.9 - Delivery files

Delivery files

  • For all websites, the web designer needs to provide at least 2 PSD or AI (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:

Specific rules for PSD file:

  • 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.

⬆ back to top

2. - Analysis and pre-work phases

Analysis and phases

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, Illustrator or Sketch is used? Some features are specific to some versions of Illustrator, Photoshop or Sketch. It is important to flag any issue regarding this as soon as possible.
  • Is the width of each file 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?

⬆ back to top

2.1 - Paper analysis

Paper Analysis

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).

  1. Define the structure of the pages, the headers, the sections, the articles, main, footer outlining these on at least one printed page.

  2. Find all the headings that structured a page, ensure the H1 is 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.

  3. 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 β€œ

  4. 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.

  5. 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.

⚠️ After the paper analysis phase, you can invite the creative team to use a tool like InVision, to facilitate the communication and exchange between the creative team and the developers. The possibility to comment directly on pages can be a time-saver and allow to keep a history of modifications and decisions.

2.2 - Pre-development phase

  • 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:

⬆ back to top

3. - Validation

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. It is essential that developers ensure the quality of the delivery before starting to code.

4. - Development phase

  • 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 by icon-, hero banners by hero- or banner- and so on.

5. - Before production

Before launching your website, be sure to review all your pages using the Front-End Checklist!

⬆ back to top


Support

If you have any question or suggestion, don't hesitate to use Gitter or Twitter:

Author

David Dias

Contributors

This project exists thanks to all the people who contribute!

License

CC0

All icons are provided by Icons8

⬆ back to top

About

πŸ’Ž The Design Checklist for Creative Web Designers and Patient Front-End Developers

Resources

License

Code of conduct

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published