Design implementation checklist
Last modified on Mon 17 Jul 2023

This article is a cheatsheet for checking design implementation before Design review or QA testing. Over the years, we have noticed that the same mistakes keep popping up in implementation. We decided to make them into a checklist for both mobile and web developers so that we don’t have to focus on those common mistakes in the design reviews.

If you didn’t already have one, the design review (officially should be called design implementation review) is a way for a designer to check if everything is implemented as it is defined in the design. Think of it as the last stage of debugging design to keep errors from getting in production. These reviews usually involve a designer and (in an ideal case) software tester. We go through the staging version of the app or a web and look at (and abuse) all of the screens and components. After we notice that something is off we will point the developer to the documentation (most often a style guide in Figma) and show them where it differs. If something doesn’t function quite right we will explain the issue, current behavior, and expected behavior.

Back to the checklist, the idea is that once you got everything working smoothly, you do a comparison with the design documentation and check for hiccups that got in along the way. There are some details developers might miss, and therefore not implement, but in design, those details are what make all the difference and it’s greatly appreciated if they are given some attention while making them come to life. The purpose is to maintain a consistent user experience as well as UI quality.

Everything should be clearly defined from the designer’s side before you start with the implementation, but if something is missing or you have any questions regarding the look or behavior of a certain component please reach out to the designer anytime - the product’s excellence is in everyone’s best interest.

Figma tips

Here are some useful Figma tips for developers and QA:

Read a bit more about the Developer’s inspect view here.


Style definitions

The following attributes are usually defined through text styles.

Adapting for different screen sizes

Spaces and alignments

We use the 8 pt grid (usually with a multiplier of 8, sometimes of 4) so you will see a lot of values like 48 px, please don’t round up to 50 px. A lot of grey hair is grown over these details, please take them into consideration.


Watch out for visual properties like color, borders, and radius.

Drop shadows


Icons and illustrations



Scrollable vs fixed

Keyboard type (on mobile)



Web specifics

Pointer type (web)


Responsive (or adaptive?)

Animated element states (hover/pressed, default, disabled)

Page/Modal Loading or Closing


Fallback font (when the page is not loading)

Text highlight color

Focused state outline (blue keyboard outline)

Navigating with keyboard

Check if designers have already specified