DevLOVE「Atomic Design ～堅牢で使いやすいUIを効率良く設計する〜」の参加レポ

2018-06-29 DevLOVE「Atomic Design ～堅牢で使いやすいUIを効率良く設計する〜」の参加レポートです。

著者の五藤さんご本人から書籍「Atomic Design ～堅牢で使いやすいUIを効率良く設計する〜」の解説と本には載っていないお話を聞けるイベントでした。

devlove.doorkeeper.jp

直近で書いたAtomic Designに関する弊社のブログはこの日に合わせてまとめたところもあり、独自で考えた観点や手順が五藤さんが携わってこられた現場と比べてどれくらい一致しているか、答え合わせのような気持ちで参加しました。

アトミックデザインを使ったコンポーネント指向のUI開発：序 - UGAP Engineer's Blog
アトミックデザインを使ったコンポーネント指向のUI開発：破 - UGAP Engineer's Blog

印象に残った話

結論としてかなり同じ考え方ができてたと感じ、自信につながりました。ただ、中には観点として足りてなかったことや本で紹介されていることの理解が足りていないことがあり、お話が聞けてよかったと思いました。

その中でも印象に残った話をピックアップします。

デザインデータの負債

デザインデータの負債というワードはエンジニアは聞きなじみのない言葉かと思います。

エンジニアの立場でアトミックデザインに注目していましたが、デザイナー側にも構造化されていないことが原因による問題があることがわかりました。

その一つに「デザインデータの負債」があります。

具体的にはPhotoshopなどのデザインツールでUIをレイヤー分けする際、そのレイヤーの名前や分け方が適当であるとそれを引き継いだデザイナーはまずレイヤーを理解することからはじめなくてはならないということです。

理解した後、同じことの繰り返しにならないようにリファクタしようとしても、今度はそのページ外での影響範囲が分からず手が出せない問題が引き起こされます。

故にデザイナー側でもデザインの作り方、なにか構造化の手段が必要になってくるというわけです。

アトミックデザインの責務の種類を揃える

アトミックデザインの構造化とその責務は本にまとめられた表と解説を読み、「なるほどそういう考え方もあるか」と思っていただけでしたが、その考えにいたるまでの過程を聞くと、とても論理的でさらに理解が深まりました。

デザインの構造化をする上で、まず他の構造化されたものに着目しており、例えば次のものをみると

OSI参照モデル
ドメイン駆動設計レイヤードアーキテクチャ

責務でわけられた各レイヤーの依存の方向が１方向であることがわかります。そのことから、アトミックデザインもまずは責務の種類を整理する必要があると考えられたようです。

さらに、デザインの構造化の手がかりを、「ユーザーの行動プロセス」から探し出すことにし、まずはユーザーの行動プロセスを順番に並べてることをされていました。

順番	ユーザーの行動プロセス
1	プロダクトを知る
2	画面全体から情報を探す
3	興味を引くコンテンツを見つける
4	コンテンツに促されて行動する
5	全体を通してサービスに良い印象を抱く

その次に、各レイヤーのデザイン対象を配置していくとこうなります。

順番	ユーザーの行動プロセス	デザイン対象
1	プロダクトを知る	マーケティング/プロダクトそのもの
2	画面全体から情報を探す	画面全体のレイアウト
3	興味を引くコンテンツを見つける	コンテンツの見せ方
4	コンテンツに促されて行動する	行動を阻害しない操作性
5	全体を通してサービスに良い印象を抱く	デザインの統一性

最後に、Atomic Designの各レイヤーを配置すると、各レイヤーの関心ごと（責務）が明確になりました。

詳しくは本に書かれていますが、依存方向が１方向であることを保ちつつレイヤーが分かれていることがわかります。

順番	行動プロセス	デザイン対象	レイヤー
1	プロダクトを知る	プロダクトそのもの	Pages
2	画面全体から情報を探す	画面レイアウト	Temlates
3	興味を引くコンテンツを見つける	コンテンツの見せ方	Organisms
4	コンテンツに促されて行動する	行動を阻害しない操作性	Molecules
5	全体を通してサービスに良い印象を抱く	デザインの統一性	Atoms

本を読んだときは各レイヤーの責務を（表を横に）見て、なるほどと思っていただけでしたが、行動のプロセスを（表を縦に）整理することから始めたと知り、自分の中でこの表の納得感がさらに増しました。

UIデザインは複数人が関わっている

こちらはかなり共感できることでした。デザインはデザイナーだけではなく、エンジニアを含めて複数人で関わっているというお話です。

ディレクター：機能要件・画面仕様
デザイなー：視覚情報・操作体験
エンジニア：実現

そのため、「構造化」というプロセスも全関係者が関わるべきプロセスであるとおっしゃっていました。

デザインカンプという手段は、ユーザが情報を見つけられるか確認できる手段としては有用ですが、構造化の面がおいてけぼりになるため、これまでのようにデザインカンプをデザイナーがつくってエンジニアが実装するフローは見直す必要があります。

なるべきフローは以下のようになると語られました。

構造化の指針を決める（関係者全員）
↓
情報をデザイン（デザイナー）
↓
構造をレビュー（関係者全員）
↓
ソフトウェアを実装する（エンジニア）

ここで重要なのは「常にレビューするようにする」ということだそうです。

レビューするにはGithubのようにバージョン管理と差分比較ができることが望ましいということで以下のツールを紹介していました。

[参考]デザインデータのバージョン管理ができるAbstractを試してみた✌ | UXデザイン会社Standardのブログ

上のツールを使うと、デザインカンプ作成中に構造のレビューができるのと同時にデザインの工程もオープンになる利点があります。
（嫌がるデザイナーもいそうですが。。）

レビューコストは気にされていて、レビューを効率化するために、デザイナーがCSSやReactコンポーネントを修正してしまうことを是としたり、 オープン（モブ）・デザイニングといった、モブ・プラグラミングのように難しいところは一気にみんなで解決して情報伝達も効率化しまおうという取り組みもされたようです。

「構造化づくりはチーム一丸になってやる」を理想ではなく、ちゃんとみんなが行動できる形にされていてすごいなーと感じました。

会場から出た質問

完全にメモったわけではないので、ざっくり書いときます。

MoleculesとOrganismsの判別の仕方は？

チェアマンの市谷さんからの質問でした。
そのときどのサイトを例に取り上げていたか忘れてしまったのですが、例えば次のようなショッピングリストはどこがMolecules（分子）で、どこがOrganisms（有機体）なのかという質問です。

f:id:uggds:20180702001913p:plain

回答
Organisms（有機体）はスタンドアローンであるといえるのでパーツとして切り離しても意味がわかる単位がOrganisms（有機体）といえる。
例えば評価（星）だけが画面にあっても意味がわからないので、それはMolecules（分子）になる。
プロジェクトで共通認識であればどちらでもいいとも思う。

個人的な意見
私はOrganisms（有機体）を「広告バナーのようにどの別のページでもそのまま使えるもの」と定義しました。下からフェードインしてきたり、フローティングしてたり、埋め込まれてたりと大小様々な広告がありますが、どの画面にでても意味が通じます。また、広告には訴求する文章が必要です。そのため、Organisms（有機体）には画像でもいいんですが、訴求文が含まれているべきかなと思います。例外はありますが。

[参考] アトミックデザインを使ったコンポーネント指向のUI開発：破 - UGAP Engineer's Blog