はじめに

こんにちわ、デザイナーの川畑です。

現在Nagisaではゲームを除いたwebやアプリのUI開発ではデザイナーがSketchファイルを作りエンジニアが参照して実装します。
(ありがたいことにエンジニアさんがSketchを触ってくださっています)

そんなSketchを中心にデザインが伝達されるのであれば、とことんファイル1つを見やすく、作りやすくしてしまおう!
ということで今回の記事では、

  • 全体の統一感を持ちつつデザイン制作
  • 実装するエンジニア、共同制作するデザイナーに設計意図を伝達

を効率よくできるファイル制作と管理方法を紹介したいと思います。

上記を目指すにあたって、
Atomicdesignの デザインパーツを合体させて、繰り返し利用可能な要素やテンプレートが作成できるシステムを構築する考え方 と、
Sketchの 再利用するパーツの修正変更が一括して行えるSymbol機能 を利用しています。

Atomicdesign,SketchのSymbol機能の詳細が知りたい方はこちらをご覧になってみてください。
珍しいワークフロー:Atomic Designの原則とSketchでデザインからプログラミングまで
Sketchのシンボル機能とは?シンボル機能の使い方を紹介

またSketchを参照する方への向けたTipsを記事にまとめていますので、デザイナーとエンジニアで共通認識を持っていると意思伝達が捗るかと思います。
[動画解説付き]デザイナーがUI実装時に伝えるべき5つのSketchTips! 〜エンジニアの困っている声に応えました〜

実例紹介

デザイン制作の品質保持と意図伝達において特に重要だと感じている

  • カラーシステム制作
  • Symbolのレベル別管理
  • レベル別デザインガイドライン

について、実例と工夫している点を紹介したいと思います。

カラーシステム制作

サービスの効果的な印象付け、伝わりやすく使いやすいUIには統一されたカラーシステムを反復して使うことが重要です。

Atomicdesignにおいてもデザイン構成要素の最小単位である原子(Atoms)として据えられていることからもわかるように、全てのデザインに影響する要素と言っても過言ではありません。
なので効率の良いデザイン運用と意図伝達において、カラー利用を体系立てて運用することは必須です。

スピードが重視されたり、画一的な印象を与えたいプロダクトの場合は、
既にシステム化されている各プラットフォームのカラーガイド(MaterialDesignのcolorpalleteなど)を用いることで、手軽に質の高いカラーシステムの恩恵を受けられるのでこちらをオススメします。

サービス独自のカラーニュアンスが重要であるとか、プラットフォームを横断する大規模な運用で柔軟性を持ったシステムが欲しい場合などは独自で作ることが求められます。

プロジェクトに求められているカラー設計によって使い分けるとして、
この項目では後者の独自のカラーシステムを制作する場合の例を紹介します。


こちらはとあるプロジェクトで実際に使用しているカラー一覧です。
主要色、階調色、背景色…などよく見るカラーガイドラインの項目かと思います。項目の分け方についてはあえて触れませんが、大体理解できるかと思います。
それぞれの色を作る上で工夫している部分のみ紹介させていただきます。

 

 

各色に名前と役割を与える

明確な名前、役割の一覧、汎用的に扱える洗練された色はアップデートの度に類似する色が無尽蔵に増えることを防ぎます。

名前については、
形容詞 色 透明度

PaleBlue65
のように表現しています。実装者や共同作業者とわかりやすい共通認識として規則を持てればなんでも良いかと思います。
(遊び心でブランドカラーに固有の名前付けると愛着湧きます)

役割については、
色の役割についてどの画面で使われるのかを定義することでもありますが、
柔軟性のあるシステムにするあたって大事にしたいことは Atomsの役割を抽象化 することです。

例えば、
Blackをアラートに用いる見出し文字色 → ページ内で最も注目して欲しい文字色
Black10をXXの一覧画面に用いる境界線 → 近似するコンテンツの塊を区切る色
Yellowを購入ボタン背景 → 金銭にまつわる色

といったように原子(Atoms)の要素を画面や利用シーンを限定しすぎない定義や色作りをします。

 

このままではカラーの具体的な利用箇所(ボタン背景色、大見出しなど…)がわかりづらいので、後述するレベルまたはコンポーネント別のデザインガイドでまかない、
ここでは 限りなく色が少なくなるように定義し、汎用的に使えるよう色を調整します。

こうすることで新しいページが増えた時に各色の役割の解釈を都度検討したり追加していく手間が減ります。
h1,h2のようにしてもいいのですが職能や経験問わず誰でも共通認識を持てる役割としてどう抽象化するは意識したいところです。
(端的にわかりやすい役割名が思い浮かばず探し続けています。…もし良い例がありましたらご連絡ください!)

 

 

階調色の調和

UIデザインでは要素のまとまりや情報の優先度付けに頻繁にグレーの階調色が利用されています。
特に他の色との調和や汎用性が求められるため、ある種UIの見やすさ、使いやすさを担っている色のまとまりであるとも言えます。

透明度階調
これはよく用いられているので実践されている方も多いかと思いますが、
同一の色に透明度差分を与えることでよって階調付けています。(もちろん後から各階調の微調整は入ります)

理由はグレースケールの階調ごとの差分によって情報の優先度を表すことが多いのですが、
透過であれば如何なる背景色であっても階調色間の強弱関係が崩れにくくなります。

極端な例ですが
白地で同一の文字色ですが、背景色が動的に変化する時など文字色の強弱の度合いが変化してしまいます。

またダークUIのような階調が反転しない限り、 1つの階調色群でも様々な背景色で強弱関係を保てます。

このように新しい背景色に伴って別の階調色を導入する、よくある似ているけど微妙に違う色。名前と役割が不明瞭な色ができてしまうのを防いでいます。

 

 

主要カラーとの調和
繰り返し使われるグレースケールにさりげなく主要なカラーと調和したり、引き立てあう色味をプラスすることで画面の印象を変えることができます。

上の図は赤橙に対する補色をうっっっすらと一律でブレンドしています。(図ではちょっと大げさに色ブレンドしています)
個人的にあまり好きなバランスではないですが笑 赤色がより目立つ風合いになったかと思います。
Sketchの公式ページも黄色と青~紫のコントラストが美しいように、少しだけグレースケールに補色入れてみるのも面白いかもしれません。

またこのようなブレンドをしても透明度階調によって強弱関係が保たれているので
ベースの純粋なグレースケールの透明度差分さえしっかりしていれば、様々な風合いを試すことができます。

Symbolのレベル別管理

主に繰り返し利用するUIコンポーネントをこちらの記事の定義に基づいてSymbol制作と整理,管理をしています。
※今回の効率化に当たって下記の記事がとても参考になります。是非ご覧になってください。
Atomic Designの概念を参考にSketchのシンボルを効率的に管理する方法

記事に倣うとこのようなSymbolページが出来上がります。

各Symbolの命名規則は上記記事に倣いこのようになっています。

レベル/コンポーネントの種類/コンポーネント名

Lv1……Atomsに相当。それ以上構造を分解できない単体のコンポーネント。アイコンやボタンなど。
Lv2……Moleculesに相当。アイコンと矩形の組み合わせでできたコンポーネント。複雑なボタンやナビゲーションバーなど。
Lv3…… Organismsに相当。Lv1ないしLv2の組み合わせでできたコンポーネント。コンテンツに相当するブロックやリストなど。

コンポーネントの種類(一部)
icon……アイコン類。主にLv1に使用。
pic……アイコンよりも大きい画像類。主にLv1に使用。
txt……テキスト類。主にLv1に使用。
img……写真類。主にLv1に使用。
btn……ボタン類。主にLv1、Lv2に使用。
list……リスト類。主にLv2、Lv3に使用。
bar……ナビゲーションバーやタブバー。主にLv2、Lv3に使用。
block……複数レベルでできたブロック。主にLv2、Lv3に使用。

Symbolのアートボード位置とLv毎に整理したり、グループ名を自動で表記できるプラグインとしてSymbol Organizerを使用しています

ここでもプラットフォーム独自のコンポーネント名をなるべく排し汎用的に扱えるように意識しています。(Floating action button → btn-circleなど)

 

また独自の解釈としてコンポーネントの種類にサブカテゴリを設けています。
Lv1/btn-basic/red-base

これを用いることで後述する コンポーネントに対する振る舞いや実装時に参照するガイドラインの一覧性が高くなります

レベル別ガイドライン

前述したSymbolをレベル別に制作した後に、
ページ内にレベル毎にコンポーネントの振る舞いやデザイン制作ルールを書いてしまいます。

Symbolに近い箇所にガイドを設けることで常に参照しやすく、柔軟にガイドライン自体を調整、検討することができます。
また実装時にSymbolからデザインのプロパティを参照する際デザインルールが近しくあるので、何を使い回すべきかが見やすくなり、無駄なUIコンポーネントが発生するのを防ぎます。

(コンポーネントの状態、可変要素パターンの参照/制作のすゝめはこちらをご参照ください[動画解説付き]デザイナーがUI実装時に伝えるべき5つのSketchTips! 〜エンジニアの困っている声に応えました〜)

特にLv1のデザインガイドラインをしっかりルール付けすることで大部分のUIコンポーネントの秩序を保てるので
コチラを整備することをオススメします。
Lv1については前項のColorのルールを含めて主に以下が定義されています。

  • Color…主要,階調,背景…などの色に対して名前と役割
  • Size…font,Icon,Space,Button,Imageに対してbaseサイズを基準にlarge,smallなど段階分け
  • Button…各ボタンの状態

詳細度の高いルールに対しては、コンポーネントのサブカテゴリ(btn-circleなど)に紐づいてルールを書くことで振る舞いが明確になります。
Lv1ほど多くは汎用的なルールではありませんが、Lv2,3も同様にコンポーネント種別にガイドラインを引くことで無駄なくレベル内の設計思想を可視化することができます。
(Lv3は画面固有のコンポーネントである場合が多いので表示ロジックなど、より画面に紐づいたガイドを記入するのもいいかもしれません)

またLv分けやのコンポーネント種別の解釈が人にとってバラバラになりがちなので、一覧で前提を確認することができます。
そうしてLv1~2まで作ったガイドがこちらのようになります。
SymbolがLv毎ガイドに区切られ、どういった部分に留意して制作すべきか、どんなコンポーネントが存在し体系立っているのか見やすくなったかと思います。
ガイド上はSymbolを配置しているのでデザイン変更時に即反映されるのもポイントです。

まとめ

以上が僕が実践しているSketchファイル1つで完結するデザイン制作と伝達のツボの紹介でした。
いきなりデザインガイドやAtomsをはじめから敷いて制作することはなかなか難しいです。
まずは基本的なLv1~2のシンボルが入ったテンプレートを配置した後に、ユーザーに届く画面を自由に改変し、
一度制作したものがどういう作用をして知覚されているか抽象化しながら、
何を反復すべきか、強調すべきかを厳選してガイドラインを考えて行く
ことが良いと感じます。

サービスのフェイズに合わせ、デザインもアップデートできる懐の広い設計思想こそこれから重要だと思います。
制作管理方法もアップデートし続けることが大事だと思うのでご意見ご感想ありましたら是非ご連絡ください。

こちらの記事で扱ったSketchテンプレート(Lv分けSymbol、カラースキームの見本)が欲しい方、デザインの設計思想や開発に興味がある方、一緒に働きたい方、お待ちしておりますので、ご連絡ください!