
01
カラーガイドラインの策定
既存SCSSのカラー変数を調査・整理し、 必要なカラーを新たに設計。 カラー名・HEX値・変数名・用途を対応づけ、 Figma上に共通基準を整備しました。
詳しく見る →
プロジェクト概要
NETSEA UIリニューアルプロジェクトにおける取り組みの一つです。
長年の改修によって複雑化した既存UIと実装を整理し、 カラー・ボタン・フォームの共通ルールを整備しました。 既存のSCSS変数や共通スタイルを調査・整理したうえで、 Figma上にデザインルールを体系化。 デザインと実装の両面から、一貫したUIを継続的に制作・改修できる基盤づくりに取り組みました。
改善のハイライト
長年の改修によって複雑化した既存UIと実装を整理。 カラー・共通UIの表現を見直すとともに、 既存SCSSを起点としてFigma上のデザインルールを整備しました。

01
既存SCSSのカラー変数を調査・整理し、 必要なカラーを新たに設計。 カラー名・HEX値・変数名・用途を対応づけ、 Figma上に共通基準を整備しました。
詳しく見る →
02
ボタンをフラットな表現に統一。 チェックボックスは枠線やカラーを見直し、 非活性状態を判別しやすいデザインへ変更しました。
詳しく見る →
03
重複・不要なコードや共通スタイルを整理。 Figmaと実装の対応関係を明確にし、 PC・SPの表示やテンプレートとの整合性を確認しました。
詳しく見る →※制作時間短縮や不具合削減の効果は定量計測していないため、 実際に整備したルール・UI・コードを成果として掲載しています。
プロジェクト詳細
NETSEAのUIリニューアルでは、TOPページやヘッダーの情報設計と並行して、 サイト全体で使用するカラーや共通UIの見直しを進めました。 本記事では、既存のSCSSを調査・整理し、 デザインと実装で共通の基準を参照できるようにした取り組みを紹介します。
01 · 課題の整理
長年の機能追加や個別改修によって、 カラー・ボタン・フォームなどのUI表現にばらつきが生じていました。 SCSSにはカラー変数や共通スタイルが存在していたものの、 Figma上ではそれらに対応するデザインルールが十分に整備されていませんでした。
また、既存コードには重複・不要な記述が残り、 共通UIを変更する際には影響範囲の確認が必要でした。 そこで、既存の実装資産を活かしながら、 画面を横断して一貫した判断ができる基準を整備することを課題としました。
UI表現の不統一
画面ごとにカラーやボタンの表現が異なり、 同じ役割のUIを一貫して扱う基準が必要でした。
デザインルールの未整備
SCSSには既存の定義がある一方、 Figma上で用途や使い分けを確認できるルールが不足していました。
状態表現の分かりにくさ
チェックボックス単体では非活性状態を判別しにくく、 枠線やカラーによる表現の見直しが必要でした。
既存コードの複雑化
重複・不要な記述や複雑なファイル構成が残り、 継続的な改修に向けた整理が必要でした。
02 · 共通ルールの設計方針
新しいデザインルールをゼロから定義するのではなく、 既存のSCSS変数や共通スタイルを確認するところから着手しました。 既存の定義を活かしつつ、必要なカラーやUI表現は新たに設計し、 画面を横断して使用できる基準として整理しました。
SCSSのカラー変数や共通スタイルを確認する。
既存カラーを分類し、必要なカラーやUI表現を設計する。
フォームの非活性状態など、操作状態が伝わる表現を検討する。
実装との対応を考慮し、参照できる共通基準にまとめる。
03 · カラー・ボタン・フォーム
カラー・ボタン・フォームについて、 従来の表現と改善後のUIを比較しながら、 変更の目的と設計上の判断を整理しました。
| 項目 | 変更前 | 変更後・設計判断 |
|---|---|---|
| カラー | SCSSにカラー変数は存在していたものの、 デザイン上の用途や使い分けを確認できるルールが未整備でした。 | ![]() 既存カラーの整理と新規カラーの設計を行い、 用途別のカラーガイドラインを策定しました。 |
| ボタン | ![]() 立体的な表現が中心で、 サイト全体に古い印象が残っていました。 | ![]() サイトの印象を刷新するという事業部の要望と、 情報量の多いECサイトの特性を踏まえ、 フラットな表現に統一しました。 |
| フォーム | ![]() チェックボックス単体では、 非活性状態を判別しにくい表現でした。 | ![]() 枠線の太さやカラーを見直し、 単体でも非活性状態を区別しやすい表現に変更しました。 |
04 · Figmaと実装の整合性
共通UIの変更を一度限りのものにしないため、 既存SCSSの変数や共通スタイルを調査・整理し、 Figma上のデザインルールとの対応関係を明確にしました。 特にカラーは、既存の変数定義を活かしながら、 新規カラーも含めて用途や使い分けを整理しました。
| 対象 | 既存実装の確認・整理 | Figmaへの反映 |
|---|---|---|
| カラー | SCSSに定義されていたカラー変数を確認し、 既存カラーと新規カラーを整理しました。 | カラー名・HEX値・変数名・用途を対応づけ、 ガイドラインとしてまとめました。 |
| ボタン | 既存のボタン表現や共通スタイルを確認し、 変更対象を整理しました。 | リニューアル後のボタン表現を、 共通のデザイン基準として整理しました。 |
| フォーム | 既存のチェックボックスの表示と状態を確認しました。 | 枠線・背景・カラーによる状態表現を整理し、 非活性状態を判別しやすい基準をまとめました。 |
設計のポイント
新しいデザインを既存コードに一方的に適用するのではなく、 実装されている変数や共通スタイルを把握したうえで、 必要な部分を整理・再設計しました。デザインと実装で共通の基準を参照できることを重視しました。
05 · 実装・品質管理
共通UIの保守性を意識し、 SCSSや既存の共通コードに残っていた重複・不要な記述の削除、 関連ファイルの統合、共通ロジックの整理に取り組みました。 既存ページへの影響を確認しながら、 デザインルールと実装の整合性を保つことを意識しました。
STG環境ではPC・SPの表示や、 ボタンのクラス、HTML構造、テンプレートの整合性などを確認し、 共通UIの変更による表示・実装上の不整合を整理しました。
既存SCSS・共通コードの整理
既存の変数や共通スタイルを確認し、 重複・不要な記述を整理しました。
ファイル構成・共通ロジックの見直し
関連ファイルの統合や共通ロジックの整理を行い、 継続的な改修を見据えた構造へ見直しました。
リリース前の品質確認
PC・SPの表示と既存テンプレートを確認し、 デザインと実装の不整合を整理しました。

振り返りから得た学び
既存の実装資産を整理する際には、 共通化すること自体だけでなく、 変更がほかの画面に与える影響を把握する必要がありました。 今後も、既存機能への影響と保守性を考慮しながら、 継続的に改善できるUI基盤を設計したいと考えています。
成果と学び
カラーガイドラインの策定、ボタン表現の統一、 フォームの状態表現の見直しを行いました。 あわせて既存SCSSや共通コードを整理し、 デザインと実装の両面から一貫性と保守性の改善に取り組みました。
制作時間の短縮や不具合削減については定量計測していないため、 本記事では整備したルールと制作物、 実装・確認した内容を成果として示しています。
| 整備前の課題 | 今回整備したこと | |
|---|---|---|
| SCSSにカラー変数はあるものの、 Figma上で用途や使い分けを確認しにくい。 | 既存カラーと新規カラーを分類し、 用途・変数名を確認できるガイドラインを作成しました。 | |
| 同じ役割のUIでも、 画面によって表現が異なる。 | ボタンやフォームの表現・状態を整理し、 共通の判断基準を整備しました。 | |
| 既存コードに重複・不要な記述が残っている。 | SCSSや共通コードを整理し、 既存実装との整合性を確認しました。 | |
| デザインと実装の対応関係が分かりにくい。 | Figma上のルールと既存SCSSの定義を対応づけました。 | |
学び
共通UIの整備を通じて、 見た目を統一するだけではなく、 次の改修でも用途や状態に応じて判断できるルールを残すことの重要性を学びました。 既存の実装資産を理解し、 デザインと開発の両面から継続的な改善を支える設計に取り組みたいと考えています。