はじめに

こんにちは!
社長室インキュベーションチームで新規サービスのデザインを担当しています田村です。

先日、デザイナーリーダーの川畑が執筆した記事にある通り、Nagisaではデザイン手法としてAtomic Designを採用しています。

Atomic Designは、コンポーネント指向のデザイン手法です。
コンポーネント指向はパーツの再利用と効率の良い運用を可能とし、デザインの追加・変更が容易であり作業の効率化に繋がります。

また、React Storybookなどを使用すれば「あのボタンがない」「カラーが違う」などの実装段階での抜け漏れも防げますし、デザイン変更のハードルも下がるかと思います。
コンポーネントの粒度がしっかりと定義できていれば、エンジニアさんとの共通言語が増えてコミュニケーションの質が高まることも期待できます。

このようにAtomic Designはデザイナーの作業効率を高めるだけでなく、エンジニアさんとの開発コミュニケーションの助けとなる素晴らしいデザインシステムです。

一つのSketchファイルでAtomic Designを実践する上での問題点😱

上記のメリットばかりでなく、Atomic Designを実践していく上でいくつか問題も出てきました。

問題①:Symbolページの肥大化

SketchでAtomic Designを実践する際には、Sketchの仕様上、一つのSymbolページに全てのコンポーネント郡をまとめておく必要がありました。

サービスが拡大していくにつれて自然とコンポーネントの数も増えていくでしょう。
コンポーネントが多くなれば、その分Symbolページは肥大化し管理が難しくなるかと思います。

また、異なる粒度のコンポーネントが混在していると、スタイルガイドとしての一覧性の担保に欠ける場合が出てきてしまうことがあると思います。

問題②:Symbolの同期性とコンポーネントの整合性が保てない

規模の大きなサービスを運用されている組織では、機能・フローごとに複数のデザイナーが関わっている場合が多いかと思います。

全てのUIデザインが一つのSketchファイルにまとまっていれば、担当デザイナーが異なっていてもコンポーネントの整合性はある程度保たれます。

しかし、もし機能・フローごとに異なるSketchファイルを運用している場合は互いのSymbolの同期性を保つことは難しく、結果としてコンポーネントの整合性を保つことも難しいでしょう。

複数デザイナーが担当する共同制作において品質と開発効率を向上させるために、将来的な運用を考えた時に起こりうる問題の対策を今のうちから練ることはとても大切です。

「Sketch Libraries」と「Abstract」を使った解決策💪

上記で挙げた問題をSketch LibrariesAbstractを組み合わせることで解決していこうと思います。

まずは両者の特徴をご紹介します。

「Sketch Libraries」について💎

Sketchはバージョン47から「Libraries」という新機能が追加されました。
Librariesは、Sketchファイルを横断してSymbolを同期することのできる機能です。

Symbolを外部ファイルとして用意しておけば、複数のSketchファイルで一つのサービスを運用している場合でもSymbolの同期が可能となり、コンポーネントの整合性も保つことができます。

実際の使用フローはこちらの動画を観ていただくとわかりやすいかと思います。

「Abstract」について

Abstractは簡単にいうと「デザイナー版GitHub」です。

例えば、複数のデザイナーが一つのSketchファイルを編集するとします。
作業が進めば当然ファイル間で差分が生まれます。

問題は「差分をどうやって埋めるか」ですが、
手作業で差分を埋めるという選択肢は現実的ではないですよね・・・

そんな時に役に立つのがAbstractです。
自動でSketchファイル間の差分を検出しマージすることができます。
また、変更をコミットできたりなどバージョン管理が可能です。

Abstractの概要と使用方法については下記の記事が参考になるかと思います。

デザインデータのバージョン管理ができるAbstractを試してみた✌

どう組み合わせるか?🤔

今回はサンプルとなるSketchファイルを用意しました。

Dropboxで配布していますので、詳しくみてみたい方は下記のリンクから参照してみてください!

Nebula | Dropbox

全体の構造を先に述べますと、以下の画像の通りとなります。

Atomsの集合体としてMoleculesが、Moleculesの集合体としてOrganisimsが、そしてPagesが存在します。
OrganisimsまではLibraryとして Nebula.sketch に読み込ませて、Abstractで管理しています。

まず、Atomsに当たるのは

  • colors.sketch
  • icons.sketch
  • buttons.sketch
  • tags.sketch

になります。
ここで注意していただきたいのが、Atom間での依存関係です。

buttons.sketch は各パーツに内包されている icons.sketch に依存し、icons.sketch , tags.sketch はカラーを指定するcolors.sketch に依存しているという関係性になっています。

本来のAtomic Designの概念にはAtom間での依存関係は定義されていませんが、SketchでのUIデザインにおいては作業の効率化ができるので、あえてこのような形にしました。

colors.sketch(Atoms)

まずはどこにも依存していない colors.sketch から作成し、Libraryとして保存します。

Preferences > Libraries > Add Library から新規でLibraryにしたいSketchファイルを追加します。

icons.sketch(Atoms)

次に icons.sketch を作成します。
アイコンに対するカラーの指定は、先ほどLibrary化した colors.sketch の中の任意のカラーをマスクさせることで実現しています。

左上の「Insert」を開くと「colors」というLibraryがリスト上にあると思うので、任意のカラーを選択し、アイコンにマスクさせます。

もし別のカラーに変更したい場合は、左のパネルの「Shared Style」から変更できます。
カラーを新しく追加したい場合には colors.sketch に追加するようにルールを守れば、UIが増えた時にもカラーの管理が行いやすく大変便利です。

このように小さいコンポーネントから順番に作成していくことで最終的にPagesが完成します。

サンプルファイルか以下の画像をみていただければその他のコンポーネントの作り方もわかると思いますのでここでの説明は省略します。

buttons.sketch(Atoms)

tags.sketch(Atoms)

molecules.sketch

organisms.sketch

Nebula.sketch(Pages)

Abstractでのバージョン管理

全てのSketchファイルを作成し終えたら最後にAbstractでのバージョン管理を行なっていきます。

新しくプロジェクトを作成し、「Import Sketch File」からPagesに当たる Nebula.sketch をインポートします。
そしてLibrary郡は「Import Sketch File as Library」からインポートしていきます。

インポートが完了するとこのように反映されます。

これで全ての準備が完了しました!
これでSymbolページを肥大化させることなく、複数人での開発においてもSymbol, コンポーネントの整合性を保ちながら存分にデザインすることができます!

複数人でAbstractを使用する場合ですが、

    1. MasterブランチからDevelopブランチを切る
    2. Developブランチから追加・変更箇所ごとにFeastureブランチを切る
    3. FeastureブランチをDevelopブランチにマージ
    4. DevelopブランチをMasterブランチにマージ

という流れでやっていけば事故は少ないと思います。

まとめ

以上、Sketch LibrariesとAbstractを使ったAtomic Designの実践について、複数人での開発も視野に入れながら書かせていただきました。

私自身、以前からSketch Librariesのリリースは楽しみでしたので流れてくる情報は常にウォッチしていました。
実際に使ってみてからは期待を大きく上回る非常に強力な機能だと感じました。
Atomic Designをより良く実践することを可能とし、Abstractを組み合わせて使うことでチーム開発の効果に大きく貢献します。

また、今回記事内でご紹介したSketchファイルは以下で配布していますので参考になれば嬉しいです!

Nebula | Dropbox

さいごに

Nagisaでは、ワークフローからデザインしていきたい方、世の中をもっと面白くしていくサービスを作りたいデザイナーを募集しています!
お気軽にオフィスに遊びに来て下さい!