ユーザーに素早く
価値を届けるための
デザインシステム
構築支援サービス
ブランドビジュアルの再構築から
効率的なエンジニアリングまで
サポートします。
デザインシステムとは？
デザインシステムの構成要素
デザイン原則
プロダクトの核となる「らしさ」や「重要なことはなにか？」を定義・明文化したもの。
デザインガイドライン
デザインシステムのルールを記載したもの。レイアウトのルールや、コンポーネントの使用方法など。
コンポーネントライブラリ
デザインパターンをコンポーネント化したFigmaのAssetsや、それと同期するReactライブラリなど。
各種リソース
デザインシステムを運用していく上で必要なデザインファイルやドキュメントなど。
INTRODUCTION
いま、
なぜデザインシステムが
必要とされているのか。
VUCAと言われる社会の中では、変化に素早く対応するスピード、すなわち、利用者により良い体験を素早く提供することが重要です。現在のデジタルプロダクトの世界では、全く新しい物を生み出すよりも、既にあるものを上手く活用して最適化を繰り返すことが重要といえます。そうした状況の中で企業は、複数のプロダクト・複数の部署・複数のデザイナーが一貫性のあるデザインを素早く的確に適用しなければなりません。そうした背景によって今、デザインシステムによる解決が求められています。
よくあるデザインの課題
01 CONSISTENCY
一貫性が
担保されていない...度重なる機能追加・改修で、デザインの一貫性が失われている。例えば、似たようなボタンがたくさん存在している。
02 UNIFICATION
プロダクト全体の
統一感がない...メインのデザイナーが変わったり、サービス毎に異なるトンマナが適用されていて、複数プロダクトの関連性が希薄。
03 EFFICIENCY
実装に手間が掛かり
改善が進まない...サービスの仕様変更時にデザインと実装の修正に、時間と手間がかかり困っている。
このような課題を
デザインシステムを用いて解決します
- CASE 01
一貫性が担保されていない...
デザインを整理・パターン化
画面遷移、レイアウト、UI部品のデザインや挙動などを整理・パターン化しアプリに反映させることで、操作性や見た目が一貫したものになり一貫したUXが実現できます。
- CASE 02
プロダクト全体の統一感がない...
ブランド定義から丁寧に
i3DESIGNのデザインシステム制作はプロダクトにおけるブランドのあり方から定義します。はじめにきちんと言語化し、ブランドにしっかりと結びついたビジュアル表現を再定義することで、ブレなくプロダクトの一貫したブランドを高めることができます。
- CASE 03
実装に手間が掛かり、改善が進まない...
再利用しやすい設計
一度デザイン・実装したものは再利用できる形にすることで、運用での作業工数を減らすことができます。
デザインシステムの
制作プロセス
- PHASE
01
01調査・分析フェーズ
対象のデザインシステムを作るにあたって必要な範囲や計画を行います。厳格なシステムが必要か、または変化に柔軟に対応するシステムとするかを考えます。また、デザイン原則を作成するための下準備として競合調査やブランド分析を行います。
ヒアリング
CI/VIの確認から、顕在化している課題の確認など、現状を理解します。また、ターゲットユーザーの定義や、プロダクトの強みなど、デザインシステムの目的と目指すべき「良いデザイン」が何であるかの認識を合わせます。
競合調査
既知/未知の競合について幅広く調査し、業界のトレンドや市場でのポジションなどを掴みます。競合のサービスを観察することで、ビジュアルデザインの方向性を決めるための材料や、差別化のポイントを掴みます。
ブランド分析
サービス提供者の持つ想いからサービスの持つ人格を導き出します。顧客像・業界のポジショニングなどの要素とバランスをとりながらビジュアルの定義まで具現化していきます。
- PHASE
02
02デザイン原則作成フェーズ
ワークショップなどを通して自分たちの「らしさ」がなにかを探索します。
これを言語化した上で、ビジュアルデザインへと落とし込んでいきます。「らしさ」の言語化
デザインシステムはブランドを効率的にデジタルプロダクトに適用するためのツールです。企業の持つブランド=プロダクトのブランドとは限らないために、改めてプロダクトのらしさとはなにかを定義する必要があります。「らしさ」は「デザイン原則」となり、デザインに迷ったときの助けになったり、何を優先すべきか、何のために作られるべきかという指針になります。
トーン&マナー設計
プロダクトのブランド定義から、実際のビジュアルデザインに落とし込まれた場合にどうなるかを検証・定義します。ブランドアーキタイプの定義からムードボードの作成、ムードボードに基づいた画面デザイン上でのパターン検証を行い、プロダクトのビジュアルコンセプトを決定します。
- PHASE
03
03UIデザイン作成フェーズ
デザインの基盤となる要素から定義を行い、コンポーネントのデザイン定義まで進めます。
デザインファンデーション作成
色やフォント、レイアウトなどのデザイン原則に基づいたデザインの基盤要素となるルールを定義します。既存プロダクトがある場合は、汎用的な要素を切り出して作成していきます。
コンポーネント定義
プロダクトで扱われるコンポーネントを定義します。 定義が必要なコンポーネントの洗い出しから、コンポーネント名称の確定までを行います。運用・実装効率を意識して、適切な制約を設けます。
パターン・プロパティ定義
コンポーネント毎に汎用性を定義します。パターンの洗い出しと、コンポーネントライブラリとしてコンポーネントの持つプロパティをそれぞれ定義します。
- PHASE
04
04実装・ガイドライン作成フェーズ
コンポーネントライブラリの実装と必要なドキュメントの作成を行います。
実装・Storybookでの確認
コンポーネントライブラリを実装します。 Storybook上での確認を行いながら、デザインファイル上での定義を実装します。
ドキュメントの作成
スタイルガイドやデザインガイドラインを作成します。 コンポーネント毎の詳細なスペックや静的なデザインファイルでは伝えきれない情報を、ノンデザイナーにもわかりやすくまとめます。
よくある質問
- Q
コストをかけずにやる方法はありますか？
A既存のUIライブラリをカスタマイズして活用するなど、コンパクトに始める方法があります。運用体制によっては、システムに厳格な制約を設ける必要がない場合など、状況に応じてプロジェクトの範囲と深さが変わりますので、是非一度ご相談下さい。
- Q
コンポーネントライブラリはどのような形式で納品されますか？
A弊社が実装の場合、JSフレームワークはReactとなります。また、デザインファイルはFigmaを基本としていますが、ご指定があればAdobe XDやSketchでの納品も可能です。
- Q
社内にデザイナーがほとんどいないのですが大丈夫ですか？
Aデザインシステムの運用にはデザイナーが必要とされています。とはいえプロダクトの更新頻度や運用体制は企業によって様々ですので、人数が少ない場合であっても管理ができる規模などのご提案を致します。
- Q
ネイティブアプリのデザインシステムは作成可能ですか？
AネイティブアプリにはHuman Interface GuidelineやMaterial Designといったプラットフォーマーのデザインシステムが存在しています。これに加えて独自のデザインシステムを構築するのは複雑になりコンフリクトが発生してしまいますので、基本的にはプラットフォーム毎のデザインシステムを準拠するか、範囲を限定して作成することをおすすめしています。
プロジェクト開始までの流れ
お問い合わせ
まずはお気軽にお問い合わせください。
ヒアリング
抱えている課題やご要望について詳しくお話を伺います。
ご提案
お客様の要望にぴったりのご提案をさせていただきます。
ご契約
提案に合意いただけたら、ご契約手続きを行います。
開始
プロジェクトに合ったメンバーでチームを編成し、キックオフを行います。