What to Check When You Receive Design Data for the First Time | Explaining Key Points to Review Before Coding

Introduction

In web production, you often receive design data from designers in formats like Figma, Adobe XD, Photoshop, or Illustrator, and
use it as a basis to code in HTML/CSS.

Recently, in particular, there has been an increase in cases where design data is received via Figma.

However, when you receive design data for the first time,

“What should I check first?”
“Where should I start looking?”
“How do I export images?”
“How do I check fonts and margins?”
“Where do I look for differences between the PC and smartphone versions?”

Many people may find themselves wondering these things.

When you receive design data, it is important to check the entire thing first rather than jumping straight into coding.

If you proceed with the work without performing an initial check, problems can arise later, such as
“there was a smartphone version,” “this design was outdated,” “images were not finalized,” or “the font could not be used on the web.”

In this article, I will explain the points that should be checked when receiving design data for the first time,
in a way that is easy to understand for coders and web creators.

First, check if it is the latest data

The first thing you should check is whether the design data you received is the latest version.

In practice, design data may contain multiple drafts.

For example,

• First draft

• Revision proposal

• For review

• Old design

• Adopted proposal

• Rejected proposal

• PC version

• Smartphone version

• Wireframe

• Design for implementation

and other items may remain within the same Figma file.

Therefore, before you start coding, be sure to confirm "which frame should be implemented."

In Figma especially, there may be multiple pages within a single file, with many frames lined up inside them.

It is dangerous to assume on your own that "this one looks the cleanest, so it must be the latest version."

It is always safer to check with the director or designer by asking,

"Is this the correct frame for implementation?"

before proceeding.

Check if there are both PC and smartphone versions

The next thing you want to check is the design for both the PC and smartphone versions.

Since responsive support is standard for websites, you need to consider the display not only on PC but also on smartphones.

Once you receive the design data, first check the following:

• Is there a PC version design?

• Is there a smartphone version design?

• Is a tablet version necessary?

• Where does the layout change between PC and smartphone?

• Are there any elements that are hidden in the smartphone version?

• Are there any elements that are only displayed in the smartphone version?

If you proceed with coding by looking only at the PC version, you may encounter significant rework later for the smartphone version.

For example, cards that are arranged horizontally on a PC might be arranged vertically on a smartphone.

Even if the header navigation is arranged horizontally on a PC, it might become a hamburger menu on a smartphone.

Also, images displayed on a PC might be replaced with different images on a smartphone.

Therefore, you should check both the PC and smartphone versions at the beginning to understand how the layout changes.

Check the number of pages and the scope

Once you receive the design data, you should also check the number of pages to be coded.

For example, the following types of pages might be included.

• Top page

• Company overview

• Service list

• Service details

• News list

• News details

• Recruitment information

• Contact us

• Privacy policy

It is important to confirm from the start whether you are coding all pages or only a portion of them.

Also, in the case of WordPress projects, it involves not only static pages but also post lists, detail pages, custom posts, and category pages.

For example,

"Only the top page and static pages"
"News list and details are also needed"
"Custom post detail pages are not required"
"Use existing plugins for forms"

Clarifying the scope of implementation, such as these examples, will help prevent future trouble.

Just because something is in the design data does not necessarily mean it is part of the current implementation scope.

Always be sure to check it against the contract scope and instructions.

Check the fonts

Once you receive the design data, you should also check the fonts being used.

Even if it looks fine in Figma, you may need to load it as a web font to use that font on a website.

The points to check are as follows:

• Font name used

• Is it Google Fonts?

• Is it Adobe Fonts?

• Is it a paid font?

• Is it a Japanese font?

• Can it be used on the web?

• Are the necessary weights available?

For example, if "Noto Sans JP" is used in Figma, it can be loaded from Google Fonts.

On the other hand, if commercial or special fonts are used, a web usage license may be required.

Font weight is also important.

If Regular, Medium, Bold, etc., are used in the design, the implementation side must also load the necessary weights.

If the font is not loaded correctly, it will be replaced by another font in the browser,
which will change the impression of the design.

Before you start coding, make sure to check the fonts used and whether they are licensed for web use.

Checking font size, line height, and letter spacing

It is necessary to check not only the font name but also the font size and line height.

The following information is crucial for accurately reproducing the design.

• font-family

• font-size

• font-weight

• line-height

• letter-spacing

• color

Line-height is something that is particularly easy to overlook.

Even if the font size is correct, the visual impression will change significantly if the line height is different.

For example, if the body text in Figma is 16px and the line height is 28px, you can write it in CSS as follows.

.text {
  font-size: 16px;
  line-height: 1.75;
}

Also, there are cases where letter-spacing is set for headings.

For Japanese headings, increasing the letter spacing slightly can sometimes improve readability.

While checking the values in Figma, make sure to translate them correctly into CSS.

Checking colors

Checking colors in design data is also important.

The main colors to check are as follows.

• Main color

• Sub-color

• Accent color

• Text color

• Background color

• Button color

• Link color

• Border color

• Hover color

In Figma, you can check the color code by selecting an element.

However, you need to be careful if multiple similar colors are used.

For example, even with colors that look black,

#111111
#222222
#1A1A1A
#333333

there may be a mix of slightly different colors.

Check whether this is intentional or just a discrepancy during the design process.

When implementing, it is convenient to manage primary colors as CSS variables.

:root {
  --color-main: #005BAC;
  --color-text: #222222;
  --color-bg: #ffffff;
  --color-accent: #F5A623;
}

Standardizing colors makes it easier to handle future revisions.

Check the margins

Margins are very important for reproducing web designs.

There are several types of margins, such as the following:

• Vertical margins between sections

• Horizontal margins for content

• Between headings and body text

• Between images and text

• Spacing between cards

• Inner padding of buttons

• Spacing between form items

In Figma, with an element selected, you can check the distance between elements by holding down the Option key on Mac or the Alt key on Windows and hovering over another element.

If Auto Layout is used, you can check the padding and gap in the right-hand panel.

In implementation, translate the confirmed margins into CSS using margin, padding, and gap properties.

For example, if the margin between cards is 32px, you can write it as follows.

.card-list {
  display: grid;
  gap: 32px;
}

If the inner padding of a card is 24px, you can write it as follows.

.card {
  padding: 24px;
}

However, it is not recommended to handle all margins confirmed in Figma using only the margin property.

Use them according to their roles: padding for inner spacing, gap for spacing between items, and margin for outer spacing.

Check the content width

On websites, the maximum content width is also important.

For example, the central content width on the PC version might be set to 1120px or 1200px.

The points to check are as follows.

• Overall width

• Maximum content width

• Left and right margins

• Width for each section

• Is only the background full-width?

• Is only the content centered?

For example, there are cases where the background color spans the full width of the screen, while the content inside is centered at 1120px.
In CSS, this can be implemented as follows.

In CSS, this can be implemented as follows.

.section {
  background: #f7f7f7;
  padding: 100px 0;
}

.section__inner {
  max-width: 1120px;
  margin: 0 auto;
  padding: 0 20px;
}

As shown here, it is important to think about the background and the content width separately.

Instead of just looking at the appearance in Figma, check which areas are full-width and which are content-width.

Check which images need to be exported

Design data may contain photos, illustrations, icons, background images, and more.

Before you start coding, check which images need to be exported.

The main items to check are as follows:

• Main visual

• Service images

• Portrait photos

• Logos

• Icons

• Background images

• Decorative images

• SNS icons

• OGP images

However, you do not necessarily need to export everything in the design as an image.

For example, simple background colors, lines, rounded corners, buttons, and text can be reproduced using CSS.

On the other hand, photos, complex illustrations, logos, and icons are often exported as images.

Use the appropriate image format for each case.

• Photos: JPG, WebP

• Transparent images: PNG

• Icons: SVG

• Logos: SVG or PNG

• Complex decorations: PNG

Organizing which assets you need before exporting images will make implementation smoother.

Check the icon format

In web development, icons are often handled as SVG.

Search icons, arrow icons, phone icons, email icons,
and social media icons are less likely to degrade when scaled if exported as SVG, and they are also easier to resize using CSS.

However, icons with complex gradients or decorations may sometimes be easier to handle as PNG.

The points to check are as follows:

• Can it be exported as SVG?

• Does it need to be exported as PNG?

• Are the sizes consistent?

• Will the color be changed via CSS?

• Does the color change on hover?

If icon sizes are inconsistent, it becomes difficult to center them or adjust the layout during implementation.

Check if sizes are consistent in Figma, such as 24px or 32px.

Check for hover and state variations

Design data may include not only the normal state but also states such as hover, active, and disabled.

The following are particularly important to check:

• Button hover

• Link hover

• Menu open/closed states

• Form input states

• Form error states

• Checkbox selection states

• Accordion open/closed states

• Modal display

• Hamburger menu expanded state

If you implement based only on the normal state, you may end up with additional revisions later, such as "Please change to this color on hover" or "We need the look for form errors."

It is safer to check if state variations exist in Figma, and if not, confirm them in advance.

Hover states for buttons and links, in particular, are almost always required during implementation.

If not specified in the design, the coder may create a natural hover effect, but depending on the project, prior confirmation may be necessary.

Check components and common parts

In Figma, elements like buttons, cards, headers, and footers are sometimes turned into components.

Components are common parts that can be reused.

When you receive design data, check which parts are shared.

For example,

• buttons

• headings

• cards

• CTAs

• news lists

• FAQs

• forms

• headers

• footers

and so on.

If the same design is used across multiple pages, it will be easier to manage if you design it as a common class in CSS as well.

For example, a common button can be implemented as follows.

.c-button {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  padding: 12px 24px;
  border-radius: 999px;
  background: var(--color-main);
  color: #fff;
}

By checking the components, it becomes easier to grasp the common rules in the design.

Check the form items

If there are contact forms or reservation forms, be sure to check the form items as well.

The points to check are as follows.

• input fields

• required fields

• Optional item

• Placeholder

• Radio button

• Checkbox

• Select box

• textarea

• Submit button

• Error display

• Completion screen

• Presence of a confirmation screen

For WordPress projects, you may sometimes use plugins like Contact Form 7.

You also need to check if you can create the form as designed and if it matches the plugin's specifications.

Additionally, if the form's error displays or submission completion messages are not included in the design,
checking them in advance will save you from panicking later.

Check for animations or movements

Design data is often static, but actual websites may require movement.

For example,

• Slider

• Fade-in

• Accordion

• Tab switching

• Modals

• Hamburger menus

• Scroll animations

• Fixed headers

• Hover animations

and so on.

Even if only the visual appearance is displayed in Figma, instructions for movement may be written in the specifications or comments.

Before implementation, make sure to check whether any necessary JavaScript is required.

In particular, sliders, accordions, and modals are related to the HTML structure, so it is important to grasp them early on.

Check comments and revision instructions

In Figma, comments may be left on the design.

Comments may contain revision instructions or supplementary information from clients, directors, or designers.

For example,

• This text is placeholder

• The image is scheduled to be replaced

• This section will be hidden

• The smartphone version is under adjustment

• The link destination is undecided

• This part is scheduled for animation

and similar content.

If you implement without checking comments, you may end up reflecting unconfirmed details as they are.

When you receive design data, check to see if there are any remaining comments and whether they have been resolved.

Consolidating questions about unclear points

You may find unclear points while reviewing the design data.

It is smoother to consolidate your questions to some extent rather than asking small questions repeatedly on the spot.

For example,

• Are the fonts used available for web use?

• Are there specifications for hover designs?

• For pages without a mobile version, is it okay to adjust from the PC version?

• Is it okay to export images from Figma?

• Is a completion screen for the form necessary?

• Is this design the latest version?

• Is this section included in the implementation scope?

and so on.

If you proceed while leaving unclear points unaddressed, it may lead to major revisions later.

It is important to check early rather than proceeding with assumptions like "this is probably how it should be."

Checklist before coding

When you receive design data, it is useful to use the following checklist.

□ 最新デザインか確認した
□ 実装対象のページを確認した
□ PC版とスマホ版を確認した
□ ページ数と実装範囲を確認した
□ 使用フォントを確認した
□ 文字サイズ・行間・文字間を確認した
□ 色のルールを確認した
□ 余白を確認した
□ コンテンツ幅を確認した
□ 画像の書き出し対象を確認した
□ アイコン形式を確認した
□ hoverや状態違いを確認した
□ フォーム項目を確認した
□ アニメーションや動きの有無を確認した
□ コメントや修正指示を確認した
□ 不明点をまとめて確認した

Just by performing these checks at the beginning, you can significantly reduce hesitation and rework during coding.

Summary

When you receive design data for the first time, it is important to check the entire project first
rather than jumping straight into coding.

First, confirm which design is the latest version, which pages are to be implemented, and whether both PC and smartphone versions are available.

After that, go through the fonts, colors, margins, images, icons, hover states, forms,
animations, and comments in order.

Design data is not just a reference for reproducing the visual appearance.

It is an essential source of information packed with the website's structure, rules, assets, movements, and items to verify.

By performing the initial check carefully, you can improve your coding accuracy and reduce missed corrections or misunderstandings.

Beginners, in particular, will find it easier to avoid confusion by keeping the following workflow in mind.

1. 最新データか確認する
2. PC版とスマホ版を見る
3. 実装範囲を確認する
4. フォント・色・余白を見る
5. 画像やアイコンを確認する
6. 状態違いや動きを確認する
7. コメントと不明点を確認する

By checking in this order, you can handle the situation calmly even when you receive design data for the first time.

In web production, the ability to correctly interpret designs is also an important skill.

As you get used to how to view Figma and design data, you will be able to code more smoothly and accurately.