10 Reasons To Have Design Checklists & UI Kits

Web and mobile application development is a multi-layered process with numerous specialists from different teams involved on various stages. In order to be time-efficient and productive, the development process has to be transparent.

There has to be a clear and obvious reasoning behind every design decision made and feature implemented. People should be able to seamlessly switch back and forth between projects. New employees’ adaptation period has to be as short as possible.

Product Transition From Designer To Developer

All of this benefits project development tremendously and can be achieved by reaching the state of shared mindset. So what are the delivery methods of shared mindset? I believe there is a number of strategies for that.

Our choice was in combining designer checklist, manager questionnaire, and UI kit as an auxiliary design document passed to the development team. The main purpose of this document is in minimizing the number of errors and discrepancies between product development phases.

A designer checklist helps us to:

• Arrange the designer’s delivery pack requirements.
• Create a basic knowledge guide for a newbie designer.

We came up with the following reasons benefitting the transition:

1. Abiding The Color Profile

90% of the times, layers with blending modes different from Normal are impossible to implement. In order to retain the original element colors designed with specific intent, the color mode has to be consistent.

When talking about web design, the delivery file and everything about it must be within the sRGB color model.

2. Decluttering Layers

Often times a design file turns into the chronicles of changes with unclear states and all sorts of abandoned elements inside.

After I defeated my hoarder syndrome and deleted all the redundant stuff, the file got two times lighter than it used to be.

3. Preserving Relevant Names

Designing the pages and screens, take care of the clear and concise naming system for layers, mockups, and folders.

For example, you can add the btn_ prefixes to the buttons. Or name user registration mockups as registration_form_default.psd.

When a new designer or a client opens the file, they’ll be grateful.

4. Maintaining The Retina Compatibility

Zeplin can turn any icon drawn with the help of shapes into an SVG file. However, if its a raster image, Zeplin will only offer the conversion to PNG or JPG.

Choose one way to follow during the entire project: SVG or raster. All the remaining graphics should be put into Smart Objects, as the ×2 version is frequently required.

5. Resizing The Default Size

Designing a new mockup, keep in mind the default size of 1280px.

When the mockup is finished, think over the resizes: 1920px, 768px, 320px. As the 768 and 320px versions are mobile, design elements have to consider this.

Perfect practice: Create a grid and document its behavior in the UI Kit for all the resizes.

6. Dealing With Additional States

Every mockup might have the states that are not obvious, but must be elaborated on in design. For example:

• Unusual behavior of the OnScroll page.
• Popups with error reports and notifications.
• Page states during switching.
• Paginators.
• Loading states and spinners.
• AdBlock extensions

7. Ensuring Consistency

The biggest issue developers have with mockups is the consistency of elements within the files. Buttons performing similar actions should look the same. Headers of alike pages have to be similar in size and color.

When creating a new element, definitely add it to the UI Kit with documented behavior.

8. Respecting Size Parity And Data Format

If you are creating or changing the sizes of elements, try preserving elements with parity. This is required for the correct multiplication of ×2 and ×3 sizes.

Such a check also helps eliminate mysterious half-pixels (what’s up Photoshop and Sketch developers!)

Check the format of the data in elements. Some designers neglect data validation and this results in UIs built with discrepancies in metric systems, currency symbols positioning, and so on.

9. Checking With The UI Kit

In order to solve the problem of element dissimilarity and missing states in UI design, we introduced a new auxilary document — the UI Kit.

It describes all the main objects and their states , typography, modular grid, and its behavior.

Note: Our term of UI Kit is not what is usually sold on designer stock platforms. Our format UI Kit is a document for developers, managers, and QA teams that helps them familiarize with the design files.

Basic Structure

• Buttons
• Fields
• Lists
• Drop-down lists
• Tables
• Checkboxes
• Radiogroups
• Headers H1-H6
• Paragraphs
• Signatures or factoids
• Spinners/Loaders
• Modular grids
• Color schemes
• Font pairs

File format must be .psd or sketch adjusted for Zeplin.

10. Providing All Element States

A developer should not assume elements behavior and states. These must be introduced by a designer’s UI Kit in their entirety. The states include the following:

• Resting
• Hover
• Focus
• Clicked On
• Error
• Empty
• Complete
• Full
• On
• Off
• Switched
• Visited

Integrity And Format

If you are working on a giant project, you can divide the UI Kit into different parts.

Today we are delegating the creation of UI Kits for projects to the individual designers. But in the long run, we are planning to come up with a common, universal, and scalable template for the entire design team.