sinshutu_kibotuの日記

大体、大抵、大半、備忘録

Atomic Designの勉強会に参加してきた

atomic design 勉強会 アジャイル 堅牢なUIコンポーネント コンポーネント vue web フロント

DevLove主催の https://devlove.doorkeeper.jp/events/75944 へ行ってきました

登壇者は「Atomic Design ～堅牢で使いやすいUIを効率良く設計する〜」の著者の 五藤 佑典さん ( @ygoto3_ ) でした

内容

アジャイルしてますか? * スプリント * UI変更をどんどん適応する

変更に強くないデザインとは?

  • 実装が原因
    • プログラムのバグ
    • レイアウトのバグ
  • デザインが原因
  • コンテンツのバグ
  • ナビゲーションのバグ(ページからページへの遷移)

構造はなぜ大切か?

  • アジャイルには変更に強い構造が必須
  • ソフトウェアの構造
    • 構造を意識になくても動作するものは作れる
    • しかし
      • スパゲッティーコードとか
      • その時は理解できるけど、あとから変更しにくいことになる
      • コードの負債
    • リファクタリング
      • 動作はそのままに、構造を変えること
  • デザインの構造
    • フォトショとかで
      • 構造わけしていないレイヤー
      • 見つけるのが辛い

デザインデータだけの問題ではない

デザインデータの外で問題が発生してる デザインはデータではない、アイデアである アイデアの構造化が必要

構造のデザインパターン

UIデザインは多くのパターンで構成されている デザインパターン -> 整理術 - 本: 人生がときめく片付けの魔法

atomic design

パーツの組み合わせ方法に少々の制限やルールを与える 人間が予測しやすい状態に整理する 5つのカテゴリ - 原子 - 分子 ...

5段階層

原子を組み立ててページを作る

  • 依存関係
    • 大きい要素は小さい要素に依存するように作る
      • 中間層で変更が起きたとき、その階層より大きいものだけ確認すればよい
      • 原子に比べてがページはすくないので、変更にかかるコストが小さくなる
      • 不具合の減少

どのように階層構造をつくるのか

世の中の階層アーキテクチャを参考にする

  • OSI参照モデル
    • 依存の方向が一方向
    • 各層で責務を共通して持っている
  • ドメイン駆動設計
    • 依存の方向が一方向 それぞれの階層で、責務を共通化させることが大切

A D

UIデザインの責務 - ユーザー行動のデザイン - 行動プロセスを基準につくる - プロセス -> デザイン対象 -> 層 - プロダクトの存在をしる -> マーケ -> page層 - アクセスする、初見でみたところからなにかを探す -> 画面レイアウト -> レイアウト層 - コンテンツに興味をもったら次の行動が生まれる -> コンテンツのみせ方 -> オーガニズム層 - 行動を阻害しない操作性 -> 行動を阻害しない操作性 -> - 全体を通してサービスに良い印象を受ける -> デザインの統一性 -> 1

コンポーネント

ソフトウェアは軸雑な問題を解決するもの 問題の分解が必要

UIコンポーネント

変更しやすいデザイン

構造化されたデザインのアイデア デザインを変更したい意図に対して変更の範囲が予測できる つまり、変更に強い

UIデザインは複数人が関わっている、デザインフローの見直し

現状

異なる側面でUIデザインを考えている - ディレクター - デザイナー - エンジニア

ワークフロー 分業している場合はコミュニケーションが必要 - ワイヤーフレーム - デザインカンプ - カンプの役割 - 実装前に完成イメージを共有する - ユーザーに対して、必要なものを見つけられる

実装が難しいデザインだと、実装を依頼してから出戻りが発生する

デザインの構造化フロー

  1. 構造の設計
  2. 情報の設計
  3. 構造のレビュー
  4. 実装

構造化の指針があれば、難しいデザインを依頼してしまうことが少なくなる

構造化した状態を維持するために

デザインガイドライン - 作り込まない - 方向性だけ決めて徐々に細かくできればよい

命名規則を決める - みんなの頭の中で指しているものが違う - コミュニケーションコストの減少

コンポーネントリスト - 作成したコンポーネントは再利用される - 一覧化して、どんなものかが分からないといちいち見に行ったり調べたりする必要がある - storybook - コンポーネントのテスト

UIテストの効率化もはかどる

チームのコラボレーション

  • コードレビュー
  • 文言レビュー
    • 影響範囲が明確であること
    • 文言の長さによるデザインの崩れとか

tips

interface inventory ワークショップ デザインの意味に応じて、部品を種類分けする それによって、統一性が図られているかどうか、小さい違いやその意味を再認識できる http://bradfrost.com/blog/post/interface-inventory/ http://makotottn.hatenablog.com/entry/2017/12/04/010923

オープン・デザイニング( モブ・デザイニング) - モブ・プログラミングと同様に難しい課題に向き合うとき、レビューコストがなくなる - 全員で頭を使うので解決が早い - 仕様レベルの話、実装レベルの話を同時にできる

感想

デザインの階層アーキテクチャで重要な部分で、層ごとに役割と責任を明確にしておくことが大切だと感じた

自分もVueJSを使って開発しているのでコンポーネントベースの開発はしていたのですが、デザインまわりはあまり巻き込んでいない開発をしています アイデアの構造化という視点はおもしろいなと感じたのと、デザインには意味や情報があるのでそれをアトミックに整理することで、ユーザーにも提供できる情報の質もあげられるのではないかなとか思いました

tipsでも上がっている interface inventoryで既存のサービスを分解して実装してみるのは勉強によさそうですね

また、書籍のご購入はこちらからどうぞ