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

"情報設計" と "体験設計" の観点から捉える UI 構築の考え方 / Approaches...

"情報設計" と "体験設計" の観点から捉える 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. 自己紹介 - 高瀬 和之 (たかせ かずゆき) 2019 年に Chatwork 株式会社へ

    フロントエンド・エンジニア としてジョインし、 リリース基盤やビデオ通話アプリケーションの開発に従事 2020 年から エンジニア採用広報に転身 し、技術イベント運営や エンジニア採用を主業務とする。パラレルワークで講師業 も営む  :@Guvalif YouTube にて アーカイブ配信中! 2
  2. そもそも DDD とは何か? 6 Minimal Imple- mentable Modula- rized Iterative

    1. 対象領域における 必要最小限かつ実装にも反映可能な "モデル" に焦点を当てて ... 2. 概念 (およびその集合) に応じて モジュール化 して ... 3. 反復的 に設計すること cf. 『エリック・エヴァンスのドメイン駆動設計』 ド メ イ ン
  3. DDD のよくある誤解 7 󰢃 誤解 󰢏 正しい解釈 DDD を実践するには、 現実を写実的にモデリングする

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

    キーワード:問題空間 (サブドメイン) と解決空間 8 問題空間 (サブドメイン) 解決空間 対象領域 (ドメイン) をそのまま扱うと 広大かつ難解な場合において、 対象領域を分割した際の一単位 単一もしくは複数の問題空間に対して、 どのように概念をモデル化して 実装しているか (≒ How) の影響範囲 cf. 『実践ドメイン駆動設計』 対象領域 (ドメイン) 解決空間 - - - -
  5. キーワード:問題空間 (サブドメイン) の種類 - コアドメイン - 事業戦略やプロダクト戦略の観点から、もっとも取り組む価値のある問題 - 支援サブドメイン -

    コアドメインと一蓮托生ではあるが、コアドメインから分離可能な問題 - 汎用サブドメイン - コアドメインには関わらないが、対象領域全体としては考える必要のある問題 cf. 『実践ドメイン駆動設計』 9
  6. 情報設計 の実装 体験設計 の実装 メンタルモデル の実装 コンテキストマップ 12 対象領域の 部分

    領域 (UI の関心ごとにフォーカス) 汎用サブドメイン 支援サブドメイン コアドメイン 依存 依存 or Interface を通じた間接依存 対応 対応 部分対応 UI の関心ごとに応じて 解決空間 を分割し、対応する 問題空間 を図示したもの → 主張:このような構造を意識することで、UI の保守性を高めることができる IMPORTANT
  7. メンタルモデルの置き場所に正解は無く、必ずしもサーバーサイドである必要も無い コラム:メンタルモデルの置き場所に関する誤謬 14 解決空間 (クライアント) 解決空間 (サーバー) 例) Notion や

    Figma など、 メンタルモデルが クライアント優位な場合 解決空間 (サーバー) 解決空間 (クライアント) 認証 / 永続責務などを BaaS 的に薄く構成 デザイン / ユースケース※ / モデル などが 一様に存在し、設計戦術が高い効果を持つ デザインなどを 薄く構成 API / ユースケース※ / モデル などが 一様に存在し、設計戦術が高い効果を持つ 例) Stripe や Auth0 など、 メンタルモデルが サーバー優位な場合 ※ ユーザーストーリーに対応づく、モデルの進行役を担うモジュールのこと
  8. なぜ "情報設計" を汎用サブドメインに対応づけたいか? 特に、アプリケーション設計 (≠ コンテンツ設計) の場合だと: - 概念操作 ×

    意味 - 概念操作 × 表示 それぞれに関わる規格整理が必要。なおかつ: - 分類 - デザイン原則 - デザインパターン といった項目は、(固有の) メンタルモデルに依存しない普遍的な法則 が適用可能 17
  9. デザインシステム "デザインシステム" の役割は、情報設計を体系化し、チームの共有知とすること 󰢃 React などによる、ただの Component 集として用いる 󰢏 情報設計の各項目を、互いの関連性を伴って体系化する

    Component 集として用いる場合であっても、 Props などからメンタルモデルへの依存を調べ、体系に組み込むべきかを判断できる 18 interface Props { message: Message; } interface Props { type: 'plain' | 'secret'; line: 'single' | 'multi'; } 固有型が現れるなら、メンタルモデルへの依存を持つ可能性が高い 固有型が現れず、デザインパターンのみを想起させる
  10. 標準化仕様 情報設計を汎用サブドメインに対応づけた方が良いもう一つの理由として、 さまざまな標準化団体 (および発行される仕様) の存在が挙げられる: - IETF (ietf.org) - W3C

    (w3.org) - WHATWG (whatwg.org) - etc … つまり、情報設計が (固有の) メンタルモデルに依存する ことは、 標準化仕様を逸脱し、開発者やユーザーへ混乱を招く 可能性が高い 20
  11. ケーススタディ: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)
  12. "体験設計" ::= 要求に関するインタラクション整理 とここでは定義 インタラクションとは、ユーザーとの相互作用のこと: - 要求を満たすルック & フィールの定義 ≒

    機能の実現 - ユーザーの 行動を適切にナビゲートする 状態管理の定義 - ポジティブ感情を誘起する 仕掛けの定義 - etc… これらを整理するのが体験設計の役割 (※ 厳密には、プロダクトの外部環境も体験設計の考慮範囲です) 23
  13. なぜ "体験設計" を支援サブドメインに対応づけたいか? 端的に言えば、体験設計に際して "メンタルモデル" を考慮したい場合が多いから - メンタルモデルに 直接依存 する場合

    - メンタルモデルに Interface を通じて間接依存 する場合 (API 連携も含む) どちらであっても、支援サブドメインとして対応づく 24 メンタルモデル (解決空間) 体験設計 (解決空間) 名前を入力してください ユーザー名モデル 表明 1:アルファベットのみか? 表明 2:文字数が 1 〜 30 文字か? ︙ 利用 表明違反の 通知 Error: 文字数が不足しています!
  14. Ubiquitous UI メンタルモデルに依存する Component を、 情報設計におけるデザインパターンと区別する意味で、Ubiquitous UI と呼称してみる 25 IMPORTANT

    export function Message({ message }: Props): ReactElement<Props> { const [date, dateTime] = useMemo(() => TimeSecond.toDateStrings(message.postedAt), []); const name = useUserAccountNameQuery(message.postedUserId); return ( <div className={style.message}> <p className={style.metaText}> <span className={style.userName}>{name}</span> <time dateTime={dateTime} className={style.date}>{date}</time> </p> <p className={style.messageText}>{message.text}</p> </div> ); } メンタルモデルへの依存の例
  15. 体験設計に際して、メンタルモデルの別解釈が表出しうる 例えば、オークションアプリにおける "残り時間モデル" の取り扱いはその際たる例: - メンタルモデル → ある 特定の時刻 を表現したい

    - 体験設計 → 非同期的なカウントダウン を表現したい 26 ◦◦ モデル (別解釈) AAA BBB CCC ◦◦ モデル XXX YYY 体験設計者 視点 ◦◦ 視点 体験設計 (解決空間) メンタルモデル (解決空間)
  16. ケーススタディ:Redux の取り扱い 28 model ia-domain ux-domain use-case repository api- service

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

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

    SSR 系フレームワークへのアーキテクチャ移行例 そもそも解決空間がクライアントとサーバーに分離しないため、 メンタルモデル (別解釈含む) とのインピーダンス・ミスマッチを防ぎやすい 体験設計の実装 情報設計の実装 メンタルモデル Container 他
  19. まとめ 01 UI の構造化は、"情報設計" / "体験設計" / "メンタルモデル" を それぞれ意識すると良い

    02 簡単なところから試すのであれば、メンタルモデルの型を手がかりに、 Component を区分けしフォルダ分けするだけでも良い