Upgrade to Pro — share decks privately, control downloads, hide ads and more …

"情報設計" と "体験設計" の観点から捉える UI 構築の考え方 / Approaches to UI Construction from the Perspectives of "Information Architecture" and "Experience Design"

"情報設計" と "体験設計" の観点から捉える UI 構築の考え方 / Approaches to UI Construction from the Perspectives of "Information Architecture" and "Experience Design"

このスライドは、2023/10/12 に開催された "株式会社サポーターズ" との共催イベントで発表したものです。

cf. https://talent.supporterz.jp/events/59126676-c947-449c-9f61-61831be47fa6/

TAKASE Kazuyuki

October 12, 2023
Tweet

More Decks by TAKASE Kazuyuki

Other Decks in Technology

Transcript

  1. Chatwork 株式会社 プロダクト本部
    エンジニア採用広報 高瀬 和之 (@Guvalif) 
    "情報設計" と "体験設計" の
    観点から捉える UI 構築の考え方

    View full-size slide

  2. 自己紹介 - 高瀬 和之 (たかせ かずゆき)
    2019 年に Chatwork 株式会社へ
    フロントエンド・エンジニア としてジョインし、
    リリース基盤やビデオ通話アプリケーションの開発に従事
    2020 年から エンジニア採用広報に転身 し、技術イベント運営や
    エンジニア採用を主業務とする。パラレルワークで講師業 も営む
     :@Guvalif
    YouTube にて
    アーカイブ配信中!
    2

    View full-size slide

  3. ※※※ 登壇を見るにあたって ※※※
    本資料は抽象度の高いトピックが含まれます
    一度に理解しきるのでは無く、脳内インデックスを作るイメージで
    ご視聴いただければ幸いです (適宜チャットからも質問まで 💬)

    View full-size slide

  4. 速習 Domain Driven Design
    UI の構造化戦略
    "情報設計" を汎用サブドメインに対応づける
    "体験設計" を支援サブドメインに対応づける
    1
    2
    3
    AGENDA
    アジェンダ
    4

    View full-size slide

  5. 1
    速習 Domain Driven Design

    View full-size slide

  6. そもそも DDD とは何か?
    6
    Minimal
    Imple-
    mentable
    Modula-
    rized
    Iterative
    1. 対象領域における 必要最小限かつ実装にも反映可能な "モデル" に焦点を当てて ...
    2. 概念 (およびその集合) に応じて モジュール化 して ...
    3. 反復的 に設計すること
    cf. 『エリック・エヴァンスのドメイン駆動設計』
    ド メ イ ン

    View full-size slide

  7. DDD のよくある誤解
    7
    󰢃 誤解 󰢏 正しい解釈
    DDD を実践するには、
    現実を写実的にモデリングする 必要がある
    実装にも反映可能なモデル にこそ価値があり、
    モデルを深堀りする中で、写実的な側面からは
    見いだせない構造が見つかることにも価値がある
    DDD を実践するには、
    クラス機構を用いる 必要がある
    概念に対して凝集度を高く保つ ことができるなら
    そもそもオブジェクト指向ですらなくてもよい
    DDD を実践するには、
    レイヤー化アーキテクチャを用いる 必要がある
    レイヤー化はモジュール分割の一手段 で
    しかなく、モデリングの一環ではない
    DDD を実践するには、
    スクラム開発を用いる 必要がある
    モデルが 恒常的にリファクタリングされる ことは
    前提だが、アウトカムが定期的にある必要はない

    View full-size slide

  8. 問題空間 A
    問題空間 C
    問題空間 D
    問題空間
    E
    問題空間 B
    キーワード:問題空間 (サブドメイン) と解決空間
    8
    問題空間 (サブドメイン) 解決空間
    対象領域 (ドメイン) をそのまま扱うと
    広大かつ難解な場合において、
    対象領域を分割した際の一単位
    単一もしくは複数の問題空間に対して、
    どのように概念をモデル化して
    実装しているか (≒ How) の影響範囲
    cf. 『実践ドメイン駆動設計』
    対象領域
    (ドメイン)
    解決空間
    - - - -

    View full-size slide

  9. キーワード:問題空間 (サブドメイン) の種類
    - コアドメイン
    - 事業戦略やプロダクト戦略の観点から、もっとも取り組む価値のある問題
    - 支援サブドメイン
    - コアドメインと一蓮托生ではあるが、コアドメインから分離可能な問題
    - 汎用サブドメイン
    - コアドメインには関わらないが、対象領域全体としては考える必要のある問題
    cf. 『実践ドメイン駆動設計』
    9

    View full-size slide

  10. 2
    UI の構造化戦略

    View full-size slide

  11. アプリケーション設計は "メンタルモデル" が大事
    特定の状況で、ものがどのように振る舞うかを経験的に記憶し、
    必要に応じて取り出せるまでに形成された心理的なモデル。
    同じような状況下での物事の判断や理解に利用することができる。
    例えば見たことのない道具を使う場合、人はその形状などから内部機構を
    瞬時に想像して (メンタルモデルを得て) 使い方を推測する。
    逆に実際の機構とかけ離れたメンタルモデルを持たせるデザインは、
    ユーザーにとって利用しにくくなる恐れが強い。
    11
    cf. メンタルモデル (sociomedia.co.jp)
    IMPORTANT

    View full-size slide

  12. 情報設計 の実装
    体験設計 の実装
    メンタルモデル の実装
    コンテキストマップ
    12
    対象領域の 部分 領域 (UI の関心ごとにフォーカス)
    汎用サブドメイン
    支援サブドメイン
    コアドメイン
    依存
    依存 or Interface を通じた間接依存
    対応
    対応
    部分対応
    UI の関心ごとに応じて 解決空間 を分割し、対応する 問題空間 を図示したもの
    → 主張:このような構造を意識することで、UI の保守性を高めることができる
    IMPORTANT

    View full-size slide

  13. コラム:クリーンアーキテクチャに関する誤謬
    レイヤー化アーキテクチャの Typical な例ではあるが、誤解を恐れず言えば、
    最外殻以外にも UI の関心ごとは存在する ことに注意!
    13
    cf. The Clean Architecture (blog.cleancoder.com)

    View full-size slide

  14. メンタルモデルの置き場所に正解は無く、必ずしもサーバーサイドである必要も無い
    コラム:メンタルモデルの置き場所に関する誤謬
    14
    解決空間 (クライアント) 解決空間 (サーバー)
    例)
    Notion や Figma など、
    メンタルモデルが
    クライアント優位な場合
    解決空間 (サーバー)
    解決空間 (クライアント)
    認証 / 永続責務などを
    BaaS 的に薄く構成
    デザイン / ユースケース※ / モデル などが
    一様に存在し、設計戦術が高い効果を持つ
    デザインなどを
    薄く構成
    API / ユースケース※ / モデル などが
    一様に存在し、設計戦術が高い効果を持つ
    例)
    Stripe や Auth0 など、
    メンタルモデルが
    サーバー優位な場合
    ※ ユーザーストーリーに対応づく、モデルの進行役を担うモジュールのこと

    View full-size slide

  15. 3
    "情報設計" を 汎用 サブドメインに対応づける

    View full-size slide

  16. "情報設計" ::= 意味と表示に関する規格整理 とここでは定義
    16
    cf. アプリケーションとウェブサイト、UI デザインにおける情報設計の違いとは?(fixel.co.jp)
    意味
    表示
    _コンテンツ_ _概念操作_
    導線設計
    デザイン
    パターン
    検索 分類
    デザイン原則
    モデリング

    View full-size slide

  17. なぜ "情報設計" を汎用サブドメインに対応づけたいか?
    特に、アプリケーション設計 (≠ コンテンツ設計) の場合だと:
    - 概念操作 × 意味
    - 概念操作 × 表示
    それぞれに関わる規格整理が必要。なおかつ:
    - 分類
    - デザイン原則
    - デザインパターン
    といった項目は、(固有の) メンタルモデルに依存しない普遍的な法則 が適用可能
    17

    View full-size slide

  18. デザインシステム
    "デザインシステム" の役割は、情報設計を体系化し、チームの共有知とすること
    󰢃 React などによる、ただの Component 集として用いる
    󰢏 情報設計の各項目を、互いの関連性を伴って体系化する
    Component 集として用いる場合であっても、
    Props などからメンタルモデルへの依存を調べ、体系に組み込むべきかを判断できる
    18
    interface Props {
    message: Message;
    }
    interface Props {
    type: 'plain' | 'secret';
    line: 'single' | 'multi';
    }
    固有型が現れるなら、メンタルモデルへの依存を持つ可能性が高い 固有型が現れず、デザインパターンのみを想起させる

    View full-size slide

  19. デザインシステムの参考例
    - デザイン原則
    - デザインパターン
    - デザイン基盤
    上記のみを、簡潔に体系化してみた例 (学生向けインターンシップで活用)
    19
    cf. Palupunte Design System (勉強会時のみ共有)

    View full-size slide

  20. 標準化仕様
    情報設計を汎用サブドメインに対応づけた方が良いもう一つの理由として、
    さまざまな標準化団体 (および発行される仕様) の存在が挙げられる:
    - IETF (ietf.org)
    - W3C (w3.org)
    - WHATWG (whatwg.org)
    - etc …
    つまり、情報設計が (固有の) メンタルモデルに依存する ことは、
    標準化仕様を逸脱し、開発者やユーザーへ混乱を招く 可能性が高い
    20

    View full-size slide

  21. ケーススタディ:Tailwind CSS (Utility CSS) の取り扱い
     Rapidly build modern websites without ever leaving your HTML.
    誤解を恐れず言えば、上記のキャッチコピーは設計思想を十分に説明していない
    - 十分に意味づけされた CSS は、メンタルモデルに依存する可能性が高い
    - それゆえに、単一責任の原則 から、再利用性が担保されづらい
    - 似ている CSS ≠ 同じ CSS,ということ
    - 情報設計のみを Utility として分離 して、再利用性を担保する
    … といったところに本質がある (Tailwind CLI はそのためのツールセットでもある)
    21
    cf. CSS Utility Classes and "Separation of Concerns" (adamwathan.me)

    View full-size slide

  22. 4
    "体験設計" を 支援 サブドメインに対応づける

    View full-size slide

  23. "体験設計" ::= 要求に関するインタラクション整理 とここでは定義
    インタラクションとは、ユーザーとの相互作用のこと:
    - 要求を満たすルック & フィールの定義 ≒ 機能の実現
    - ユーザーの 行動を適切にナビゲートする 状態管理の定義
    - ポジティブ感情を誘起する 仕掛けの定義
    - etc…
    これらを整理するのが体験設計の役割
    (※ 厳密には、プロダクトの外部環境も体験設計の考慮範囲です)
    23

    View full-size slide

  24. なぜ "体験設計" を支援サブドメインに対応づけたいか?
    端的に言えば、体験設計に際して "メンタルモデル" を考慮したい場合が多いから
    - メンタルモデルに 直接依存 する場合
    - メンタルモデルに Interface を通じて間接依存 する場合 (API 連携も含む)
    どちらであっても、支援サブドメインとして対応づく
    24
    メンタルモデル (解決空間)
    体験設計 (解決空間)
    名前を入力してください
    ユーザー名モデル
    表明 1:アルファベットのみか?
    表明 2:文字数が 1 〜 30 文字か?

    利用
    表明違反の
    通知
    Error: 文字数が不足しています!

    View full-size slide

  25. Ubiquitous UI
    メンタルモデルに依存する Component を、
    情報設計におけるデザインパターンと区別する意味で、Ubiquitous UI と呼称してみる
    25
    IMPORTANT
    export function Message({ message }: Props): ReactElement {
    const [date, dateTime] = useMemo(() => TimeSecond.toDateStrings(message.postedAt), []);
    const name = useUserAccountNameQuery(message.postedUserId);
    return (


    {name}
    {date}

    {message.text}

    );
    }
    メンタルモデルへの依存の例

    View full-size slide

  26. 体験設計に際して、メンタルモデルの別解釈が表出しうる
    例えば、オークションアプリにおける "残り時間モデル" の取り扱いはその際たる例:
    - メンタルモデル → ある 特定の時刻 を表現したい
    - 体験設計 → 非同期的なカウントダウン を表現したい
    26
    ○○ モデル (別解釈)
    AAA
    BBB
    CCC
    ○○ モデル
    XXX
    YYY
    体験設計者
    視点
    ○○ 視点
    体験設計 (解決空間) メンタルモデル (解決空間)

    View full-size slide

  27. ケーススタディ:コマンドとクエリの分離
    メンタルモデルを 操作する箇所 と、結果を受け取る箇所 は、異なる可能性がある
    (特に、Component が非正規形データを必要とする場合に顕著)
    → これらを分離する ことで、メンタルモデルを扱いやすくかつコンパクトに保つ
    27
    コ マ ン ド ク エ リ
    ○○ モデル
    XXX
    YYY
    操作責務
    Command Query
    結果集計責務
    (※ 必要に応じて用意)

    View full-size slide

  28. ケーススタディ:Redux の取り扱い
    28
    model ia-domain
    ux-domain
    use-case
    repository
    api-
    service
    Action
    Selector
    Middleware
    Store
    Container 他
    Chatwork における Redux を用いた現行アーキテクチャ例
    UI において、メンタルモデル (の振る舞い) を考慮する必要が多い場合に、
    Redux のような状態管理システムを導入する価値が高くなる
    体験設計の実装
    情報設計の実装
    メンタルモデル

    View full-size slide

  29. ケーススタディ:GraphQL の取り扱い
    29
    model-
    type
    ia-domain
    ux-domain
    use-case
    repository
    model
    Mutation
    Query
    GraphQL Resolver
    Container 他
    GraphQL へのアーキテクチャ移行例
    UI において、メンタルモデル (の振る舞い) を考慮する必要が少ない場合に、
    GraphQL はもっとも真価を発揮する
    体験設計の実装
    情報設計の実装
    メンタルモデルの型

    View full-size slide

  30. ケーススタディ:SSR 系フレームワークの取り扱い
    30
    model ia-domain
    ux-domain
    use-case
    repository
    Command
    Query
    SSR 系フレームワークへのアーキテクチャ移行例
    そもそも解決空間がクライアントとサーバーに分離しないため、
    メンタルモデル (別解釈含む) とのインピーダンス・ミスマッチを防ぎやすい
    体験設計の実装
    情報設計の実装
    メンタルモデル
    Container 他

    View full-size slide

  31. まとめ
    01 UI の構造化は、"情報設計" / "体験設計" / "メンタルモデル" を
    それぞれ意識すると良い
    02 簡単なところから試すのであれば、メンタルモデルの型を手がかりに、
    Component を区分けしフォルダ分けするだけでも良い

    View full-size slide

  32. 働くをもっと楽しく、創造的に

    View full-size slide