なぜあなたのアプリは使いにくいのか
弊社TRAPEでは、ユーザーエクスペリエンス（UX）を改善するために、これまで何度もデザインの修正を行ってきました。その過程で得られた知見を、アプリ開発に携わるすべての方々（デザイナーだけでなく、開発者、プロダクトマネージャーなど）に向けて共有したいと思います。
なぜなら、本当に分かりやすいUXは、UIデザインだけでは達成できません。「ビジネスフロー」や「データベースのモデリング」といった、より根本的な部分まで深く考え抜かれて初めて実現できるからです。
今回紹介するプラクティスです。
- 短期記憶に負荷をかけない
- 長期記憶を利用する
- 機能を増やさない
- データ作成時にオプションを提供せず、閲覧時にオプションを提供する
- デフォルトがベストの状態にする
- UIをデータベースクライアントに寄せてはいけない
- アプリの根底にあるビジネスの本質的難しさはデザインでは軽減はできてもなくすことはできない
短期記憶に負荷をかけない
ユーザーが情報を処理する際、一度に多くのことを覚えておく必要があると、使いにくさを感じてしまいます。
例：アンケートにおける凡例の位置
アンケートの凡例を、最初にまとめて配置するべきか、それとも各質問ごとに配置するべきか。ユーザビリティテストを行った結果、最初にまとめて配置した場合、ユーザーは凡例を確認するために何度もスクロールする行動が頻発しました。これは、短期記憶に負荷がかかっている証拠です。
短期記憶への負荷を軽減するポイント
- 関連する要素どうしの空間的距離: 関連性の高い情報は、視覚的に近くに配置する。
- 関連する要素どうしの時間的距離: 関連する操作や情報は、時間的に連続して提示する。
- 関連する要素の数: 一度にユーザーに記憶させようとする情報の数を絞る。
もし、あなたがプログラマーであれば、変数のスコープをなるべく短くするプラクティスと、共通性を感じるかもしれませんね。
長期記憶を利用する
ユーザーが既に持っている知識や経験（長期記憶）を活用することで、直感的で分かりやすい操作感を提供できます。
長期記憶を活かすデザインのポイント
- デザインの一貫性: アプリ内でボタンの形や色、挙動などを統一する。
- アイコンの有効活用: 一般的に認知されているアイコン(例：家のアイコン＝ホーム)を適切に使う。
- メタファーの導入: 現実世界のメタファーをUIに取り入れることでビジネスフローの複雑さを軽減する。
- 一般的な操作パターンへの準拠: 多くのユーザーが期待するであろう動作を裏切らない(例：ロゴをクリックするとトップ画面に戻る)。
機能を増やさない
アプリの機能が増えるにつれて、UIは複雑化する傾向にあります。
例:FigmaのUI変遷
Figmaは機能拡張に伴い、UIも進化してきました（UI1→UI2→UI3）。初期のUI1のシンプルさと比較すると、UI3は多機能ゆえに複雑さが増していることが見て取れます。
参照: https://mastodon.online/@nikitonsky/114229744697448687
機能が増えることによる複雑さの増加は、線形的ならまだしも、指数関数的になることも少なくありません。この増加を対数関数的な増加に抑えることができれば理想的です。とはいえ、機能数が少ない初期段階（x=1付近）では、どの関数であっても複雑さはそれほど問題になりません。
増加関数の種類:線形増加とは限らない
どんな増加関数であっても機能数がすくなければ複雑ではない
重要なのはアプリのポジショニングです。
- 入門向けか、玄人向けか？
- 入門向けと位置づけるなら、徹底して機能を絞り込むべきです。
- 入門から玄人への橋渡しを目指すなら、デフォルトは入門向けUIとし、隠し機能や設定で玄人向けUIを提供するなどの工夫が考えられます。
- 玄人向けなら機能は増える傾向にあります。そのため、複雑さを対数関数的に抑える努力が必要です。
機能を「増やす」のは比較的容易ですが、「減らす」のは非常に困難です。なぜなら、アプリ全体の最適化を理解し、実行できる知識、経験、そして能力が求められるからです。そのため、「減らす」マインドを持ったマネジメント層の存在が不可欠です。
データ作成時にオプションを提供せず、閲覧時にオプションを提供する(できれば)
ユーザーがデータを入力・作成する段階で多くの選択肢を提示すると、混乱を招きやすくなります。
例:アンケート結果分析サービス
かつて、私たちのアンケート結果分析サービスでは、アンケート作成時に将来的なデータ構造の汎用性を見越して、ユーザーに2つの分岐（オプション）を選ばせていました。しかし、「どちらを選べばよいのか」という問い合わせが相次ぎました。
当初アンケート作成時にユーザーに選択をさせていたが、ユーザーからの問い合わせが相次いだ。
これを問題と捉え、データ構造を組み直しました。具体的には、アンケート作成時の分岐をなくし、結果を分析する際に分岐（オプションの選択）ができるように変更しました。結果として、ユーザーからの問い合わせはなくなりました。
データ作成は、データのライフサイクルにおける最初のステップです。ここでユーザーを悩ませてしまうと、その後のフローに進んでもらえません。ユーザーに過度な事前知識を要求するべきではないのです。
この考え方を発展させると、ビジネスフロー全体において、分岐の数を減らしたり、分岐のタイミングをできるだけ後ろ倒しにしたりする努力が重要になります。可能な限り、ピラミッド型のシンプルなツリー構造を目指し、逆ピラミッド型のような複雑なツリー構造は避けるべきです。
デフォルトがベストの状態
便利な機能は、ユーザーが何もしなくても最初から使える状態になっているのが理想です。
例:VimとVSCode
Vimは多くのプラグインを導入しカスタマイズすることで、VSCodeのような、あるいはそれ以上の書き心地を提供できます。一方、VSCodeはデフォルトの状態でも十分に使いやすく設計されています。
もし本当に便利な機能なのであれば、それはデフォルトで有効にしておくべきです。Sentry(エラーキャッチツール)の画面録画機能が良い例で、デフォルトで提供されることで多くのユーザーがその便利さに気づくことができます。
UIをデータベースクライアントに寄せてはいけない
実は、この記事を書くきっかけともなったのが、このプラクティスです。
ただし、このプラクティスは「必ずこうしなければならない」と強く主張するものではありません。むしろ、UIを改善しようと考える際の重要なヒントの一つとして、頭の片隅に置いていただけると幸いです。
さて、本題に入りましょう。
アプリケーションができることは、基本的にデータベースができることに依存します。しかし、だからといってデータベースクライアントをそのままユーザーに提供すれば良いかというと、そうではありません。なぜなら、データベースの知識は専門的で難しいからです。
わかりやすいアプリを目指すなら、UIをデータベースクライアントに寄せてはいけません。
これは単に「表形式の表示をやめればよい」という話ではありません。たとえカード形式のUIであっても、それが単にデータベースのテーブル情報を表示しているだけなら、表示方法を変えただけのデータベースクライアントに過ぎないのです。
例：従業員名簿機能における課題とUIの工夫
ここで一つ、私たちが直面した課題と、それをUIの工夫で解決した例をご紹介します。「従業員名簿機能」を開発していた時のことです。
当初、私たちは以下の点で悩んでいました。
- 登録フローのジレンマ: 従業員情報とオフィス情報は、どちらを先にユーザーに入力させるべきか。従業員ページとオフィスページはデータ構造上、別々になっていました。
- 必須依存関係: 従業員を作成するには、その従業員が所属するオフィス情報が必須でした。
- ユーザー体験の一貫性: しかし、アプリのフローとして、まずオフィス一覧を完全に作成し終えてからでないと従業員を登録できない、というのはユーザー体験の一貫性を損なうように感じられました。
- UIの複雑化懸念: かといって、従業員作成画面内でオフィスも新規作成できるようにすることも考えましたが、入力フォームのバリデーション制御などが複雑になり、UIが煩雑になる懸念がありました。
従業員を登録する際にオフィス(必須情報)を選ぶ必要があるが、オフィスをどのタイミングで登録してもらうか悩んだ。
データベースの構造上はオフィスと従業員が別々のテーブルで管理されていても、ユーザーにとっては「従業員とオフィスは密接に関連している」というメンタルモデルがあります。この直感をUIに素直に反映できないかと考えました。
そんな試行錯誤の中で考案したのが 「スタックテーブル」 というUIです。このUIを採用することで、「まずオフィスが存在し、そのオフィスに従業員が所属する」というデータの依存関係や業務の流れを直感的に表現できました。結果として 「オフィスがなければ従業員を登録できない」というルールをユーザーが自然に理解し、操作できるUI を実現できたのです。これは、単純なテーブル表示や個別の入力フォームの組み合わせだけでは実現が難しかった体験です。
スタックテーブルを使い、直感的にオフィスがなければ従業員を登録できなくした
このように、ユーザーの入力ユースケースやメンタルモデルに合わせて、データを複合的に、かつ分かりやすく表現することが、使いやすいUIの鍵となります。
アプリの根底にあるビジネスの本質的難しさは、デザインでは軽減できても無くすことはできない
アプリが扱うビジネス領域そのものが本質的に複雑である場合、どれだけUIデザインを工夫しても、その根本的な難しさを完全に取り除くことはできません。この場合、ビジネス領域を根本的に改善したほうがよいでしょう。
例：freeeの確定申告
会計ソフトのfreeeは、非常に分かりやすく作られていると評判です。しかし、確定申告で「単発の副業収入をどう扱えばよいか（雑所得か事業所得か）」といった問題に直面した際、freeeの説明文を読んでも最終的な判断が難しいことがあります。これは、freeeのUIの問題ではなく、税のシステムそのものが本質的に複雑であることに起因します。
こちらのTogetterのまとめも参考になります： https://togetter.com/li/2526292
税のシステムのような、いち企業ではコントロール不可能な外部要因による複雑さは、デザインの力だけで解消することは困難なのです。デザインはあくまで難しさを「軽減」する助けとなりますが、その限界も理解しておく必要があります。
ちょこっと宣伝、TRAPEでは共に働く仲間を募集しております~~
株式会社TRAPE(トラピ)のテックブログです。株式会社TRAPEは、高齢者福祉で人材開発に取り組む企業で、「trapezoid」から名前が来ています。高齢者のwell-being実現のため、「NoRole NoLife」をミッションに、ケアワーカー育成や介護施設の生産性向上に努め、国や自治体事業にも関与しています。
Discussion