デザイン 勉強会 イベントレポート UI

OOUIからユーザビリティテストまで、スキル横断的にUIデザインを見る!Designer's MTG #10 UI Design編 レポート!

デザイン 勉強会 イベントレポート UI

こんにちは。
コーポレートデザインチームのmewmo(@mewmoppel)です。

ペパボではテレワークを基本とする働き方に移行することが決定され、社内デザイナーのナレッジシェアの場として開催されている「Designer’s MTG(通称 デザミ)」のフルリモート開催も当たり前の風景となってきました。
今回は「UI Design」のエキスパートスキルエリアのデザイナーにナレッジシェアしていただきましたので、その様子をお届けしていきたいと思います〜

これまでのデザミのレポートはこちら

「デザミとは?」「エキスパートスキルエリアとは?」については、前回の記事で紹介していますので、気になった方はあわせてご覧ください。

  1. UI Designのナレッジシェア
    1. UI Design Keynote
    2. OOUIについて
    3. Kindaichi tool実装におけるOOUIを考えるまで
    4. minne事例 - 3列表示から2列表示に戻した話 -
    5. 作成したUIの能力を実証する - ムームードメイン事例
  2. 新卒デザイナー自己紹介
  3. Webアクセシビリティ・ガイドラインについて
  4. まとめ

UI Designのナレッジシェア

UI Design Keynote

今回はUI Designのナレッジシェアということで、まずはきでりん(@kii0719)さんからイントロダクション。
GUIの歴史から始まり、ペパボのデザイナーが目指すUI Designのスキルの定義を共有し、より良いUXをつくるためにどのようなアプローチが必要なのかを簡単に話していただきました。

ペパボではUI Designのスキルを次のように定義しています。

プラットフォームのマナーに則り、ユーザビリティとアクセシビリティに優れた美的価値と機能的価値を両立したUIをデザインする。ペパボでは現状主にGUI。

まず、OSなどのプラットフォームのマナーに則ってデザインを行うことで、開発コストもユーザーの学習コストも下がります。次に、ユーザビリティとアクセシビリティはUXの重要な土台であり、美的価値と機能的価値はUXの向上に欠かせない要素です。『Web情報アーキテクチャ』の著者の1人であるPeter Morvilleは、体験を次の7つの要素に分解し、その相関を「UXのハニカム構造」として図に表しています。

  • accessible(アクセスできる)
  • usable(使える)
  • useful(役に立つ)
  • findable(見つけられる)
  • credible(信頼できる)
  • desirable(望ましい)
  • valuable(価値がある)

またこれらの要素をピラミッド状に配置してレベルを示した「UXの4つのレベル」という図もあります。こちらは『UXハニカム構造』を評価軸として考える場合の構造として、『IAシンキング』の著者、坂本貴史さんが図に起こしたものです。

UXのハニカム構造では図の中心にvaluable(価値がある)が配置され、その周囲に残りの6つの要素であるaccessible(アクセスできる)、usable(使える)、useful(役に立つ)、findable(見つけられる)、credible(信頼できる)、desirable(望ましい)が等しく配置されています。この周囲に配置された6つの要素によって体験が構成され、これらの組み合わせによって中心のvaluable(価値がある)な体験が生まれます。逆に、これらの6つの要素のうちどれかが欠ければ価値を損なう体験となってしまいます。ここではvaluable(価値がある)を中心に残り6つの要素を均等に配置していますが、7つの要素をピラミッド状に配置した図がUXの4つのレベルです。下から順に、アクセスしやすい、利用しやすい、安心しやすい、満足しやすいの4つのレベルに分けて、アクセスしやすいのレベルにaccessible(アクセスできる)、利用しやすいのレベルにusable(使える)とfindable(見つけられる)、安心しやすいのレベルにuseful(役に立つ)とcredible(信頼できる)、満足しやすいのレベルにvaluable(価値がある)とdesirable(望ましい)がそれぞれ配置されています。このピラミッド構造を見ると下部のレベルに配置された要素が上部のレベルの要素の前提となっており、そのすべての前提としてアクセスできることが体験の土台にあることがわかります。 書籍『デザイニングWebアクセシビリティ 』から引用

好ましい体験はまずアクセスできることから生まれ、使えることで体験を成功させることができます。
そして機能的価値があることでユーザーとって役に立つ体験や価値ある体験につながり、さらに外観の美しさが加わり両立することで、ユーザーにポジティブな感情が生まれ、より満足しやすい体験につながっていきます。

どんなUIをデザインすることが求められているのかが見えたところで、UIの役割にも目を向けてみましょう。
ペパボでは、「ペパボのデザイナーがデザインしているもの」の関係を表した「ペパボデザインスキーム」という図が社内のデザイナーで共有されています。その全貌はまた別の機会にお届けしようと思いますが、今回はその中でUIがどのように位置づけられているのかに注目したいと思います。

ペパボデザインスキームはペパボにおけるデザインという仕事の構造図ですが、その中でもプロダクトの部分を拡大して注目します。サービスとして私たちペパボが提供するツールと、そのツールをユーザーが使うという行動によってプロダクトが成り立ち、ツールを使って起きたことをユーザーが知覚・認識し、意識・行動が変化する一連の流れを体験としてこのプロダクト部分の図では表しています。

UIはユーザーとツールの間に境界面として存在し、境界面上に丸で示されているように「ユーザーが使う」「ツールが使われる」というインタラクションが発生しています。このようにUIを通してユーザーがツールを使い、何かが起きたことを知覚・認識し、その結果、意識・行動に変化が起こります。この変化の量がValueです。
そしてこの一連の流れが体験であり、意識や行動変化をおこすために知覚・認識させることがUIの本質的な役割です。

この知覚・認識のために重要なことが、Designer's ModelとUser's Modelを一致させることです。
「こう思わせたい」というデザイナーの意図と、「こう思った」というユーザーの認知の間にUIは存在しています。
UIを通してユーザーがDesigner's Modelを理解し、ツールを使って起きたことを知覚・認識するためには、User's Modelと整合性のあるUIをつくることが重要なのです。そして、その理解の結果がそのプロダクトのメンタルモデルになります。

「システムがどのように動作しているようにみえるか」というメンタルモデルは、「こう思わせたい」というデザイナーの意図(デザイナーズモデル)と、「こう思った」という実際にツールを使ったユーザーの認知(ユーザーズモデル)によって構成されています。この両者のモデルの間にUIが境界面として存在しています。PMがUXするために必要なのは多分IA/IA for PM』から引用

ここまでの話を踏まえて、より良いUXをつくるためにどのようなアプローチが必要なのか。
UIデザインは、ある1つの画面の見た目を作るだけではありません。たとえば、ユーザーが語弊なく理解したりより良い体験に導くためには、言葉のデザイン、マイクロコピーが重要です。また、ユーザーが一連の体験を完了できるように画面同士のつながりをデザインしていく、ナビゲーション設計も求められます。
この2つはUIデザインのスキルの範疇でありながら、マイクロコピーはコミュニケーションデザインのスキルでもあり、ナビゲーション設計はIAのスキルでもあります。つまり、他のエキスパートスキルを向上させ多角的にアプローチすることで、より良い体験につながるUIをデザインするができます。

他のエキスパートスキルから多角的にUIデザインにアプローチする例としては次のようなことが考えられます。たとえば、IAの観点ではユーザーがシステムを理解して使えるためのオブジェクト設計、コミュニケーションデザインの観点ではコンテキストに沿ってユーザーを理解に導くマイクロコピー、エンジニアリングの観点ではシステムモデルを理解したオブジェクト設計と実現可能なUI設計、リサーチの観点では検証に基づく優れたユーザビリティのUI、最後にビジュアルデザインの観点ではユーザーが思わず使ってみたくなる外観のデザインにアプローチすることができます。このようなUIデザイン+αでより良い体験につなげられます。

私たちペパボはユーザーにサービスを提供し、そのタッチポイントの1つとしてWebサイトやアプリといったツールを開発しています。体験がどのようなものであり、UIがどのような役割を持っているのか、そして、より良い体験をつくっていくためにどのようなアプローチをしたらいいのかをここで共有してもらうことで、それぞれの業務での意識づけや実践ポイントを学ぶことができました。

OOUIについて

ここから、Keynoteの発表内容を踏まえて具体的な事例を紹介していただきます。
つばさ (@tsubasa_sris)さんからは、最近「銀の弾丸」で界隈を沸かせた書籍『オブジェクト指向UIデザイン―使いやすいソフトウェアの原理』が出版されてホットワードとなっている、OOUIの概念について話していただきました。

GUIの設計には大きく分けて「タスクベース」と「オブジェクトベース」の2種類があります。
タスクベースは銀行の「お引出し」のようにユーザーがタスクを選んでからオブジェクトを選択し、オブジェクトベースはユーザーがオブジェクトを選んでからそれに対するアクションを選択します。MacOSのFinderのように1つのファイルに対して開く、ゴミ箱に入れるといったアクションを選択するようなものはオブジェクトベースですね。
タスクベースにするとタスクを完了しないと先に進めない場合が多く、ユーザーがアクション完了まで拘束されるモードが生じやすいため、大抵の場合はオブジェクトベースのほうがモーダレスで使いやすさにつながるとされています。

ユーザーがタスクを選んでからオブジェクトを選択するタスクベースのUIは動詞→名詞の構文になっており、ユーザーがオブジェクトを選んでからそれに対するアクションを自由に選ぶオブジェクトベースのUIは名詞→動詞の構文になっていてユーザーがオブジェクトを直接操作できます。

しかしながら、何でもかんでもOOUIにしたらよいのかというと、そういうわけではありません。
たとえばATMのようにオブジェクトが限定されている場合や、リニアな導線でユーザーを誘導したほうがわかりやすいときには、タスクベースのUIのほうが適しています。
また、失敗例として「とっつきやすさだけをとってタスクベースを採用してしまう」という事例に対して、「ユーザーは時間軸によって変化するものであり、長期的に使われたり接触頻度の高いプロダクトの場合は、自由度の高いOOUIのほうが結果的に生産性を高められる」とつばささんは話します。
タスクベースとオブジェクトベース、どちらの考え方も使いやすさを目指しているのは同じで、どちらが適しているのかしっかり見極めてUIを設計することが重要であることを学べました。

見極めをミスっている例として、「タスクベースのほうが道順もあるし説明的だから、多くのユーザーにとってわかりやすそう!」「オブジェクトベースだと自由度が高すぎて使いこなすまで時間がかかるし、ユーザーは不安になるだろう」といった理由から「とっつきやすさだけをとってタスクベースを採用してしまう」ことが挙げられます。しかしユーザーは時間軸によって変化するものです。最初はタスクベースのほうがわかりやすいかもしれませんが、長期的に使われたり接触頻度の高いプロダクトの場合は自由度が高いOOUIのほうが結果的に生産性を高められます。なのでユーザーの状態を見定めるのが大事です。

Kindaichi tool実装におけるOOUIを考えるまで

次に、デザインエンジニアのgyugyu(@gyugyu)さんから、現在開発中の社内校正ツール「Kindaichi tool」の実装について。
前回はIAの観点でどのようにオブジェクトの関係性をとらえ定義・命名していったのかを話していただきましたが、今回はそこで定義したオブジェクトをUIに落とし込んで設計する際の気づきについて話していただきました。

概念を切り分けて名前をつけたものの、その概念をそのままUIに落とし込もうとしても何をしたいのかがまとまっておらず、意図する体験を実現できるUIにはならなかったそうです。
ここで大事になってくるのが、オブジェクトに対してユーザーがどのような操作をするかを定義すること、そしてそのユーザーの操作に対してシステムがどのように応答するかを定義することの2つです。

最初の概念清書図では、最初に切り分けた概念だけを並べてオブジェクトの関係性を示そうとしており、ユーザーの操作やその操作を束ねるオブジェクトが抜けています。アップデートした関係図では、用語集をレベル1(概念)とレベル2(UIとユーザ行動)に分割し、関係図もレベル1(概念)にかぶせる形でレベル2(UIとユーザ行動)を追加しています。

たとえばRaw Textというオブジェクトに対しては、ユーザーの操作は「入力(更新)する」、システムは「Raw Textが更新されたらValidation Resultを表示する」と定義され、ユーザーの操作を束ねるオブジェクトとしてRaw Taxt Editorが新たに作られることになりました。このように、ユーザーの操作とシステムの応答の定義をして体験を整理することで、UIの設計を精査できることを学べました。

UIのワイヤーフレームのBefore/Afterを比較します。Beforeでは左側に検証する文章があり、右側にトーンの名称と校正の提案内容が表示されています。しかし外観では左側はエディターになっているわけではなく、トーンも名称が表示されているだけなので入力できることや選択できることなど、ユーザーの操作が明示されていません。AfterではRaw Text EditorやTone Selectorなど新しく追加されたインタラクションレベルのオブジェクトが反映され、ユーザーの操作とオブジェクトの関係性が明確になり、わかりやすいUIになりました。

minne事例 - 3列表示から2列表示に戻した話 -

てっちゃん(@outskirtsHinode)さんからは、minneの検索結果画面の改修事例から考察したことについて話していただきました。

minneでは「作品をたくさん見てもらいやすくする」という目的のもと、検索結果を2列表示から3列表示にすることを試みていました。

minneの検索結果の2列表示と3列表示を並べて比較してみます。たしかに2列表示では一画面で4点の作品が見えるのに対して、3列表示では一画面で9点の作品が一覧できており、その差は2倍以上です。一方で、3列表示では作品の写真もかなり小さくなり、作品の詳細が2列表示よりも見づらかったり、なかにはお気に入りボタンが作品に被ってしまっているものも見受けられます。

しかし実際にやってみたところ、クリック率は上がったものの、全体の収益やお気に入り経由の購入数・収益は下がるという結果になり、最終的には再びもとの2列表示に戻すこととなりました。
これらの事実に対しては、「サムネイルの縮小にともなってお気に入りボタンが作品にかぶりやすくなり、見えづらいから確認するためにクリック率が上がったが、逆に作品を探す手間が増えた結果購入数が下がったのではないか」と推測できます。

それではなぜ3列表示ではうまくいかなかったのか。ここで前回IAでも登場した探索行動を使って、てっちゃんさんがその理由を紐解いていきます。
前回カラーミーリピートの注文画面の事例では、既知情報探索がアクションのメインであったために一覧性を重視したUIを採用しました。しかしminneの作品検索は、知らない作家さんのオリジナルの作品がたくさんあるなかで自分にとってピンとくる作品、自分のセンスを探求探索する体験でもあります。
そして、自分のセンスとぴったりハマる作家さんや作品を見つけ出会うことが、minneの価値でもあります。
問いも答えも自明でないなかでインタラクションを通して自分の好きに気づいていくプロセスは、前回IAで説明されていたベリーピッキングモデルの話に通じています。

人は情報を知ろうとする時、そもそも何を知ろうとしているかわかっていません。答えは自明ではありませんし、そもそも問いも自明ではありません。探索する中でインタラクティブに問いを確立していき、そしてそのインタラクションを通して物事を理解していく探索行動のプロセスをベリーピッキングモデルと言います。

自分でも知らないあるいは曖昧であるものを探す探求探索であること、そしてお気に入りに出会うことに価値があること。
この2つを考えたときに、大事なのは一覧性よりも作品の魅力を伝えることであり、その場合3列表示よりも2列表示のほうが適しています。
一覧となる画面について考える際には、何でも一覧性が重要なのではなく、サービスの体験と価値に基づいて考えることがまず第一なのだと学べました。

作成したUIの能力を実証する - ムームードメイン事例

かわもと(@keita_kawamoto)さんからは、ムームードメインでUI検証としてユーザビリティテストを行った事例について。

きでりんさんのKeynoteでDesigner's ModelとUser's Modelを一致させることが重要とありましたが、デザイナーの意図と実際にユーザーが思うことは必ず一致するとは限りません。リリースする前にUIを検証し、UIが設計意図通りの能力を持つのかあらかじめ確認することで、リリース後の「全然使えなかった…」という悲劇を回避することができます。
ここではムームードメインのカレンダー連携機能を実装した事例をもとに、簡易的なユーザビリティテストのポイントについて話していただきました。

ユーザビリティテストを行う際には「できるだけリアルで純度の高い情報を入手することが重要」とkawamotoさんは話します。そのために事前に準備しておくことがいくつかあります。

まずは試験内容(シチュエーション)と被験者の操作モチベーションを設定します。
シチュエーションとモチベーションを設定することで被験者に実際にできるだけ近いシチュエーションで操作してもらい、純度の高い情報を入手できるようになります。

今回のムームードメインのカレンダー連携機能を実装した事例でのユーザービリティテストでは、試験内容(シチュエーション)と被験者の操作モチベーションを次のように設定します。試験内容:「カレンダー連携機能がリリースされたと知ったユーザーは、ログイン後、要素の多いトップページの中でその機能を試すことができるか?」というシチュエーション設定で、存在を認知できるのかを検証。被験者の操作モチベーション:被験者は全員ムームードメインでドメインを取得・所持しているユーザーで、「あなたはexample.comというドメインを所持しており、自動更新は設定しないタイプである。そんな中、ドメインの有効期限をカレンダーに登録できる機能がリリースされた、という情報を得たユーザーは、自動更新設定はしないけど継続する・しないの検討はしたいので、検討し忘れを防ぐためにカレンダー機能を試してみようと思った」という設定で操作をしてもらう。

次に必要なのは、被験者のリクルートです。
ターゲットユーザーと同じ条件で、かつ今回の設計の背景・詳細を一切知らない人物を選ぶ必要があります。少しでも事情を知ってしまっていると潜在意識が多少なりとも影響してしまい、純度の高い情報を入手できません。

実際のユーザビリティテストの様子。ターゲットユーザーと同じ条件で、かつ今回の設計の背景・詳細を一切知らない人物であるkotarokさんを被験者に、実装する前にプロトタイピングツール「Prott」でプロトタイプしたUIを実際に操作してもらっています。

このようにテストの条件・環境をしっかり整え、純度の高い情報を入手・解析することで、よりユーザーが使いこなせるUIを設計できることを学べました。

新卒デザイナー自己紹介

UI Designのナレッジシェアはここまでで、ここからは新卒デザイナーの自己紹介。
今年は2名のデザイナーが新しくペパボの仲間に加わってくれました!

新卒デザイナーの自己紹介スライドから一部抜粋。まりりんは大学院で「公園に旗をさすことで居心地の良い空間と新しいコミュニティを作る提案」をしたことがあり、その提案に使用されているイラストからは提案のメッセージやストーリーが伝わってきます。ぐーちーは「特文」というペンネームで漫画家・イラストレーターをしていて、Webサイト「electromonkey」(https://electromonkey.net/)にその活動内容が掲載されています。

絵でメッセージやストーリーを伝えるのが得意なまりりん(@maririn04250)さんと、こちらもなんと漫画家のぐーちー(@tokufumi130238)さん。
今後一緒に働いていけるのが楽しみです。おふたりともよろしくおねがいします〜!

Webアクセシビリティ・ガイドラインについて

最後に、鹿(@shikakun)さんからは、社内リリースしたWebアクセシビリティ・ガイドラインについて共有していただきました。

ペパボデザインプリンシプルでは、ペパボのプロダクトは「アクセシブルであること」と定めており、アクセシビリティを達成するために具体的にどのようなことに気をつけたらよいかは国際規格であるWCAG2.0やその後継であるWCAG2.1を参照することが理想的です。
しかしながらWCAGは特定のWebの技術に依存しないように抽象的に書かれていることから解釈が難しい箇所があり、WCAGを直接参照すると実際の実装で判断に迷う点もいくつかあります。
そこでペパボでは、他社が公開しているアクセシビリティに関するドキュメントを収集し、ペパボのサービスにとって重要な項目を追加・精査し、職種問わず業務に活用できるリンク集のようなガイドラインを作成して社内で共有してみました。

ペパボのWebアクセシビリティ・ガイドラインの位置づけを示すと、WCAGを参照しているAmeba Accessibility Guidelinesやfreeeアクセシビリティー・ガイドラインをさらに参照する形でペパボのWebアクセシビリティ・ガイドラインが成り立っており、ペパボのデザインプリンシプルで規定されている「アクセシブルであること」はこのペパボのWebアクセシビリティ・ガイドラインを参照しています。ペパボデザインプリンシプル→ペパボのWebアクセシビリティ・ガイドライン→Ameba Accessibility Guidelinesやfreeeアクセシビリティー・ガイドライン→WCAGの順に、その内容はシンプルものから複雑なものになっています。

ペパボのWebアクセシビリティ・ガイドラインの内容を一部抜粋した、インタラクションラベルについての記述部分のスクリーンショットです。内容は次のとおりです。見出し:「インタラクションラベル」本文:「インタラクションラベルとは、リンクテキストや、UIの操作を導くボタンのラベルなど、そのラベルを契機にアクションを誘発するような要素、およびそのラベルのことを指します。・インタラクションラベルの予測と期待を合わせる。リンクテキストは、リンク先のページタイトルを使用する。コンテキストによっては、リンク先のタイトルがユーザーの予測に必ずしもマッチしないことがある。その場合はユーザーにとって正しい予測を導くラベルを設定する。・「スクロール」「〜をクリック」「〜ボタンを押してください」のような自己言及的なラベルは避ける。「〜について」「〜はこちら」は書いても情報が増えないので、原則使用しない。・ボタンなどのUIラベルやマイクロコピーについての詳細は、ガイドラインを参照すること。」詳しく学べる資料(それぞれ参照先にリンク):「エー イレブン ワイ[WebA11y.jp]: リンクテキスト[テキストリンク]、Ameba Accessibility Guidelines: 2.4.4 リンクの目的を理解できるようにする、freeeアクセシビリティー・ガイドライン: リンク・テキストの文言、freeeアクセシビリティー・ガイドライン: テキスト情報の文言とアクセシビリティー

まとめ

以上、第10回目デザミの模様をmewmoがお届けしました!
今回は冒頭で「UIデザイン+α」とあったように、今まで以上にエキスパートスキルエリア同士の関連を感じる回でした。
こうしてデザミを通して横断的に知識をインストールすることで、より良いデザインを目指していきたいですね。

さて、次回の開催は8月初旬ごろ、エキスパートスキルエリア「UX Engineering」のデザイナーがナレッジシェアをする予定です。第11回目のレポートもお楽しみに!

それではまた!