Design Review Process

How to use this page

The design review process is the final step before handing design over to developers. Unlike feedback, the goal is not to reiterate on feature concepts, solutions, UI or layout.

Instead, the goal of the design review is to make sure base cases are well documented and that the design adheres to standards (internal and external) as well as accessibility guidelines and spelling.

The design review process should be structured to minimise the amount of work to be redone when errors are found. E.g. the most fundamental issues should be addressed first.

If new components were created and added to our Design System during the design of a new feature. Make sure each component undergoes a design review of their own.

This page is also useful as a reference during the design process! After all, it’s the cheat sheet for what will be checked before designs are approved.

The design review process

1. States

One could bake the following questions/checklist in their design process to make sure that it covers all aspects of the user experience:

  1. First time use: What would happen when the user lands on our product for the first time? How would the system help them get on boarded?
  2. Empty states / no data: What would happen when they have been on boarded but there isn’t any data? What should be the ideal call to action then?
  3. Feedback: How does the system provide feedback about the consequences of my actions? How will I know that an action has been successful or that a state has been saved?
  4. Error handling: What if they were taking an action and it ended up in an error? What are some of the alternate flows for them to recover from the error? Is there need for undo or redo functions? If a process can not be undone, has the user been properly warned?
  5. Loading: What would the product show when it’s trying to load some data based on a user action? Animation if it’s a quick turn around time? Or, blank templates where data would show up (lazy loading)? Or, something else altogether?
  6. Lots of data: How would you like to show lot of data? Does it make sense for an infinite scroll? Or, shall we paginate the records?
  7. Navigation / dead ends: How will the user get out of the current view or flow? How are pointers or other component states used communicate intent and the results of a users action ahead of time?

Use Figma plugins like Content Reel to fill in test data for various fields. Also consider Google Sheets Sync plugin for data consistency, especially for testing and marketing purposes.

2. Documentation

There is a documentation component in our design system and it should be used as often as ever possible. Any interaction, conceptual model, decision, error or system state should be explicit.

Knowing what should be added as documentation can be hard, as some things can be clearly read from the designs alone. A rule of thumb is that questions posed by developers or designers should usually be resolved by adding some documentation for future reference.

3. Design system

  1. Components: Existing ones used where applicable. New ones created when necessary, but built flexible enough not to require new components for new situations. E.g. if you’re creating multiple components for lists, you’ve probably not made the initial one flexible enough through abstraction or variant toggles.
  2. Colour and typography styles: All text and all visual elements should utilise colours and typography defined in our Design System. Illustrations should also use our colour system as a starting point, but have the flexibility to work between the defined colour steps.
  3. Spacing: We use a base 8px system, allowing for flexibility down to 4px on occasion. The necessity of using 4px is subjective as we don’t have a clear system yet, but usually presents itself in the relation between elements that are grouped closely together such as an input field and it’s error text below, which might be distanced at 4px rather than 8px, or 12px rather than 16px to clearly show their grouped relation.

4. Responsive design

Using Figma auto layout in a thoughtful way during component creation and overall layout will drastically increase the responsive capabilities of our designs, and ease developer hand off.

Once we’ve implemented the first iteration of responsive mobile views, we should add a section here to address how responsive views are checked.
Note that the developer tab in Figma translates auto-layout to Flex-box instructions. This might create cause for interpretation by developers, and some situational documentation requirements for designers. For instance, situations where css grid is intended, might not be clear to developers looking at a Auto Layout Figma-file.

5. Accessibility

We have to prioritise the big baddies when it comes to accessibility. There will be some accessibility debt in the system now in our early days, but we can make it as small as possible by following a few simple steps.

  1. Colour contrast: WCAG has clear guidelines to follow for accessibility. We adhere to the AA standard.
  2. Colour alone does not convey meaning: When colour is used to convey meaning, such as warning, error, success, increase or decline, it should always be complimented by visual and/or text elements.
  3. No important actions hidden by hover-only
  4. Alt texts for assets: All images and illustrations should have decriptive alt-texts that developers can use in their implementation.

Consider using Able (shameless self promotion) or Contrast (which is actually updated and therefore better) or some other plugin to check contrast of colour relations not already defined in the design system.

6. Spelling and terminology

Writing is hard, but at this point the actual content should have been ironed out through the feedback process. At this stage we check two things:

  1. Are we consistent in our use of terminology. For instance, are the designs consistent in the use of “rooms” vs. “spaces”, or in describing our users as “members” vs. “employees” etc.
  2. That spelling is correct according to English US standards.

SPELLL is a free plugin for spell checking in Figma. It allows you to set the prefered language and works great, but if you want to check only a single view, you might want to copy that into a separate page temporarily.

7. Assets

Assets like illustrations, photos and videos must be available from the design file. This could include links to Drive folders or other Figma-files. Note that permanent files should be stored in Drive and not only in Notion.

  1. They should be the right size, grouped and their export settings properly set up.
  2. The asset (or group in Figma) should be named to be understandable for our users if they were to right click and download an asset.
  3. Dimensions should be 4px base

8. Extra steps for design system components

While a design system can contain all kinds of things, like illustration guides and typography, most will consist of various components to be used in our design system. In addition to the steps above used for design of all features, components should be created with a few extra bells and whistles.

Abstraction level

Components should be as reusable as possible. This means that components should not reflect a specific use case, but rather a building block or pattern (series of components used together). For instance, think of an input field. As it can be used in almost any context it should be flexible enough to do just that. Therefore we only need one component for input fields. It might have various sizes (mobile, desktop, s, m, l) or states (hover, active, disabled), but we do not create multiple versions for different contexts (registration, settings, etc.).


Naming layers

Components should have each individual layer labeled. Note that text layers can be renamed not to match their content, meaning the text on a button saying “Create room” could still be named “Label” in the layer panel. This is useful for developers.

Layers should be named to reflect their abstracted use case. E.g: Label or Icon.

Layer naming should follow the convention most commonly used in our tech stack: camelCase.

TODO: Double check that we use camelCase and not snake_case or something.

Responsive design

While we will have mobile (iPhone 8 base) and desktop views defined for all designs, components should also exemplify how they act when screensizes become very large (4k or even ultrawide displays) or very small (iPhone SE 1st Gen or Android basis view).

Pass the scale test! You should be able to create an instance of a component and resize it as you please by dragging or filling it with content without breaking the layout. That tests wether you have used auto-layout correctly.
Use Figma plugins like Measure to add measurements in documentation. As our developers use a base 16px system where 1 rem = 16px, you can enter this formula into the unit field of the plugin to translate correctly for developers: ($/16) rem