デザインパターンとユーザー課題をどう結びつけるのが良いのか
この記事はfreee Designers Advent Calendar 2022の13日目です。
こんにちは、freeeでデザイナーをしているfkadyと言います。
デザイン基盤というチームにて、デザインシステムの運用やガイドライン作りなどをしています。
本記事では「デザインパターンとユーザー課題の結びつけ方」について今段階で考えていることを共有できたらなと思います。
なぜデザインパターンとユーザー課題の結びつけ方を考えているのか
本題に入る前に、その背景やfreeeにおけるデザインシステムの状況を補足させてもらえたらなと思います。
freeeでは2019年頃からデザインシステムを作り始めて今まで運用してきています。
以前の登壇資料に、立ち上げの背景から現在に至るまでの流れを載せています。
今更ですが、先月のセミナーで話した資料をアップしました。デザインシステムに一般的に期待できる効果とその解釈、freeeではどのタイミングで効果を経験してきたかという流れになっています。https://t.co/XqGz8aQjKS
— fkady (@_fkady) May 20, 2022
また近頃は、コンポーネントレベルのデザインシステムを、より大きいまとまりとしたデザインパターンとして提供しようという取り組みも始めています。
デザインパターンが求められた経緯については以前の登壇資料を参考までに載せさせてもらいます。（登壇資料では画面パターンという言い方をしていました）
先日のDesign System Build#01での登壇資料です。「freeeの目指す方向性から画面パターンと結びついたデザインシステムを考え始めている」という話になります。具体的な取り組みはこれからですが、判断の経緯など参考にしてもらえたらなと思います#DesignSystemBuildhttps://t.co/EbsKeFrac8
— fkady (@_fkady) August 25, 2022
特に経緯として大きかったのは、統合型クラウド型ERPの発展のため「プロダクト横断して一貫性を持つ、新しいプロダクトをスピード感を持って立ち上げる」といったことを、デザインシステムとして支えていきたいと考えたことでした。
コンポーネントレベルとパターンレベル（デザインパターン）との比較は以下のようなイメージです。
コンポーネントレベルの提供は
テキスト
ボタン
フォーム
メッセージ
etc…
というように「単独で使用される単位」で存在しているのに対し、
デザインパターンとしての提供は
Header・Navigation・PageContentといった全体の構成
PageContent内でのレイアウト・構成
PageContentの各内容（一覧/詳細/集計/etc…）
PageContentの各内容を構成するまとまり(タイトル/検索/コメント/etc…）
etc…
のように、画面構成の中での「意味をなすコンポーネントのまとまり」をパターンとして提供することを想定しています。
上記のような流れでデザインパターンについて取り組みはじめていましたが、その一方で下記のような疑問も生まれてきました。
デザイナーはデザインプロセスの中で、デザインパターンをどう利用するのが良いのだろうか
デザインパターンを何となく当てはめるようなことが起き、肝心のユーザー課題が解決されにくくならないだろうか
そのような疑問のもと、今回はデザインパターンそのものではなく「デザインパターンとユーザー課題の結びつけ方」について、現時点での見解を共有したいなと思います。
デザインパターンが効果的に利用されている状態は何か
まず「デザインパターンが効果的に利用されている状態は何か」と着地点から考え始めました。
言語化していくにあたっては、ShopifyのデザインシステムであるPolarisでの記述を特に参考にさせてもらいました
A design pattern is a repeatable solution to a common UX problem in a specific merchant situation.
定義部分では「デザインパターンは特定のsituationにおいて、よくあるUX problemに向けて繰り返し適用されるsolutionである（意訳）」との記述があります。
続けて、Consistent/Unified/Contextualの３原則があるとした上で、
A pattern is always paired with the problem it solves and the situation it appears in. A solution applied in a context it wasn’t designed for is not a pattern.
Contextualについては「パターンは常に、解決するproblem・それが現れるsituationとペアになっている。コンテキストを伴っていないsolutionはパターンとはならない（意訳）」との記述もあります。
上記、Polarisの定義を参照すると「デザインパターンのUI(solution)だけが先行せず、コンテキスト(situation/solution)を伴った形で利用されるべき」と考えるのは確かに理にかなっていそうに感じます。
ただ、デザインパターンのUIが汎用的（抽象的）であるのに対して、ユーザーのコンテキストは具体的であるところにギャップがあるかもしれないと考え、個人的には以下のような解釈を加えています。
特に、具体のproblemから抽象（汎用）に伸びている矢印を意識して加えています。
「具体的なsituationにおける具体的なproblem」と「汎用的なデザインパターンのペアとなる抽象的なproblem」を結びつけるには、「具体problemの抽象化」が重要になるのではと考えました。
ここまでを踏まえると、デザイナーの業務として
デザインプロセスを通して、具体的なsituation/problemを把握する
具体的なproblemを抽象化する
抽象化されたproblemをsolution(デザインパターン)にあてはめる
以上のようなことができると、「デザインパターンとユーザー課題」がデザイン業務の中でうまく結びつけられるのではないかと考えました。
続いて、上記３つがどのように行われるのかの想定を書こうと思います。
デザインプロセスを通して、具体的なsituation/problemを把握する
ここでいうデザインプロセスは具体的なUIを作り込む前のプロセスを指します。
UXリサーチのような「探索」
ペルソナ作成・ユーザーストーリーマップ(as-is)・ペインポイントの把握、のような「現状把握」
ペインポイントの重要性判断・ideation・ユーザーストーリーマップ(to-be)のような「理想状態の定義」
フローチャートやOOUIモデリング、のような「情報設計」
などが当てはまると考えます。
挙げたようなデザインプロセスに関しては、デザイナーが普段の業務で行っている事になると思いますし、デザインプロセスに関しては他でも様々解説されていると思うので本記事では割愛しますが
「各プロセスによってどんなアウトプットが得られるのか」を意識する
一連のデザインプロセスを通して「ユーザーの具体的なコンテキスト(situation/problem)」を把握する
というのは、デザインパターンとユーザー課題を結びつける上で特に意識されるべきなのではと考えています。
具体的なproblemを抽象化する
problem/situationという言葉の解釈は色々できそうですが、デザインプロセスの中で出てきやすい言葉と対応させようとすると、
problem = ユースケース
situation = ユースケースの起こる状況
上記が近い対応になるのではないかと思っています。
その上で「具体的なproblemを抽象化する」のは、「ユースケースの要点は何かと深掘りする」行為に近いように考えます。
仮の例を挙げてみましょう。「従業員が自由に借りることのできる書籍の管理サービス」があるとして、そのサービスの画面の一つに「会社の持つ書籍の一覧」があるとします。
その上で、以下のようなことが具体的なコンテキスト(situation/problem）が、デザインプロセスを経て出てきたとします。
situation
人から勧められた、twitterで話題になっていた、など「借りたい特定の本が既に頭にある」
problem
会社の持つ書籍の一覧から、「頭にある特定の本を見つけたい」
上記の具体problemの要点を考えていくと、
「会社の持つ書籍の一覧」から、頭にある特定の本を見つけたい
=> 特定の本を見つけられるような検索の形にしたい
=> 特定の本を見分けるには、表紙も大きな手がかりになる。
上記のように、具体problemの要点を掘り下げることで段々とproblemが抽象化されていくのではないかと思います。
抽象化されたproblemをsolution(デザインパターン)にあてはめる
problemが抽象化されていると、用意しているデザインパターンとの結びつけは考えやすくなるはずです。
先ほどの例でも
「特定の本を見つけられるような検索の形」と対応する検索UIを用いる
「特定の本を見分けるには、表紙も大きな手がかりになる」を満たすように、本の一覧は画像を強調した表示となるUIを用いる
上記のようにコンテキストに応じたUIを考えられそうです。
例ではメインとなるユースケースを中心に考えましたが、ある画面においては他にもユースケースはあるはずなので、メインのユースケースを抑えつつ「他のユースケースにも対応できるような汎用性があるか、極端にタスクベースになっていないか」は当然考慮したいです。
まとめと考察
「デザインパターンとユーザー課題の結びつけ方」について、以下のような方針を持っています。
着地点
「デザインパターンのUI(solution)を、コンテキスト(situation/solution)を伴った形で利用する」と「デザインパターンが効果的に利用されている状態」を満たせるのではないか
着地点に至る要素
デザインプロセスを通して、具体的なsituation/problemを把握する
具体的なproblemを抽象化する
抽象化されたproblemをsolution(デザインパターン)にあてはめる
ただし、上記はデザインの考え方やプロセスを新しく提示しているわけではないとも考えています。
「ケースに応じてUIを独自に編み出すのではなく、ケースに応じたUIを世の中慣習も考慮しつつ考える」というのはUIデザイナーが一般的に持っている観点だと思います。そう考えると「ケースに応じたUIを自社で用意するデザインパターンを用いて考える」というのは、デザイン業務の基本的な考え方を変えずに行えることなのではないでしょうか。
また、必ずしも順番通りにデザイン業務を進めなければいけない訳ではないとも考えます。Sociomediaの上野さんのツイートやfigmaCPOの山下さんの記事にもある通り、解決案が先に浮かぶこともありそうです。そう考えると、最も意識されるべきは着地点の「デザインパターンのUI(solution)を、コンテキスト(situation/solution)を伴った形で利用する」であり、デザインプロセスを行き来する中でそれが裏づけされていくと良いのではないかと考えます。
着地点が意識されることで「problemに対して今のデザインパターンでは対応しきれないのではないか」と気づくきっかけにもなり、「今あるパターンを改善するのか・新しいパターンとして定義するのか・あえてパターンとはしないのか」など、デザインパターンを継続的にアップデートしていくことにも繋がるのではないかと思います。
以上となります。
ここまで書いて最後にちゃぶ台返しをする様ですが、本記事の内容は現時点では仮の見通しに過ぎません。策定中のデザインパターンが確立され、実際にデザイン業務として運用してみるともっと考慮すべき点も出てくるかと思います。
そのような段階であえて書いた記事という前提にはなりますが、思考の過程など何かの参考になれましたら幸いです。
明日は今年freeeに入社され関西拠点でご活躍中のzunさんです、お楽しみに！