「UI/UXデザインの原則」を読んだ

UI/UXデザインの原則

目的はこの記事と一緒。同じタイミングで2冊買った。

hamburger-tech.hatenablog.com

メモ

データ分析で分かるのは結果

GAなどを使って改善するのは一般的だが、得られるデータは操作結果であってユーザニーズとは異なる。それだけに頼った試作では頭打ちになる。定量データを活用し、インタビューなどの定性的なアプローチを通じてユーザニーズを探っていく

時間軸を意識したUX

UXは利用中の「一時的UX」だけでなく、利用早期と行った「予期的UX」、利用後の「エピソード的UX」、利用時間全体の積み重ねである「累積的UX」のステップも存在する。操作中だけでなく前後を意識することで、広い意味でユースケースを捉えることができ、ユーザが積極的に利用してくれる良いサービスへの改善につながるかもしれない。

知りたい情報を知りたいときに見せる

ユーザにとって必要な情報がわからないと、サービスによっては利用をためらわれてしまう。仮に次のページにそれが書いてあったとしても、到達しなければ書いていないのと同じ。

そういう不安を汲み取って、必要に応じてサポートできるようなUXを考えると全体の離脱率の改善につながる

情報設計とビジュアルデザイン

UIデザインは情報設計とビジュアルデザインのステップがある。

自分は情報設計が好きで、仕事でも関わっていきたいと思っている。一方でビジュアルデザインはこだわりが無く、一般的なツボを抑えておけば良いというスタンス。得意領域が中途半端なので、やはり自分がデザイナを本業にするのは厳しそう。

その他の感想

先に読んだUIデザイン必携~と重複する部分を飛ばしながら読んだので、ブックマーク箇所は少なかった。ただ、時間軸で捉えることの重要性を理解できたのが一番の収穫で、業務アプリを利用するエンジニアに必要な観点を身につけられた気がする。前後に存在する実世界の行動にマッチするようなUXを作り続けることで、その流れがシームレスにできそう。

UXが悪い例にチャットボットが挙げられていて、問い合わせサポート用に用意されたチャットボットが全然役に立たなかった過去の経験を思い出した。機能が少なすぎてさんざんたらい回しにされた挙げ句結局電話問い合わせが必要だったことは一度や二度ではなく、最近は試さなくなってしまった。あれも、担当者がUXを意識していたら、ユーザの時間を浪費させるだけで意味がないことに気づけたのではと考えてしまう。今は、一時期流行った機能がゾンビとして生き続けているだけなのかもしれないけど。

情報設計とビジュアルデザインの言語化は、かなり刺さった。自分のやっていることがデザイン全部ではなく情報設計である言えるようになったので、デザイナとのコミュニケーションが捗りそう。

「UIデザイン必携 ユーザーインターフェースの設計と改善を成功させるために」を読んだ

UIデザイン必携 ユーザーインターフェースの設計と改善を成功させるために

本業ではないと思いつつ、最近はFigmaでアプリデザインをする時間が増えてきた。ここ数ヶ月UX領域に絞って学習してきたが、実際のデザイン作業は適切なコンポーネント選択の連続なのでUI領域の経験不足が気になるようになってきた。

その辺をカバーするために、評判が良さそうな書籍を買ってみた。この本が一冊目。

メモ

色数をむやみに増やしてはいけない

グレー要素の中にアクセントカラーの要素を紛れ込ませたとして、その数が増えても増えなくても認知にさほど影響が無い。一方で、色数が増えてもその色同士の区別は難しい。

色数を減らすことで色要素を目立たせることはできるが、色数を増やしてもそれぞれの違いを際立たせることは出来ない。元々知っていた知識だが、具体的な図を見ることで実感出来た。

また、一度色を増やしてリリースすると減らすのは難しい。この不可逆性も色を増やすときの注意点。

詳細画面は、ユースケースにおける当面のゴール

一覧と詳細の画面構成は一般的だが、詳細画面がユーザがサービスを利用する上での最終的なゴールとは限らない。詳細画面で目的を果たすと、その次のゴールを目指すことも考えるべき。まず詳細画面を作りこんでいくのは良いが、それはあくまで当面のゴールでしか無いということは意識すべき。

ユーザが分かっている状態を維持するのが大事

ユーザが「場所」「操作」「状態」を把握していることが、サービス利用において重要。逆に言えば、それが分からない状態になるととたんにサービス利用は難しくなる。

確かに運用中の問い合わせはその3つのどれかであることがほとんどなので、意識しておきたい。

操作が分からない

操作方法だけでなく、操作した結果どうなるか不安なものも利用にハードルがある

状態が分からない

状態と操作を分離することで、わかりやすくなる場合がある。例えば、どちらがアクティブなのか分からないスイッチや、アクティブな状態だとどうなるのか分からないトグルなど。

状態によって色あり・なしを変えたり、状態によってトグルのラベル表記を変えることで、わかりやすくなる

アタマの負荷とカラダの負荷

アタマの負荷は認知負荷、カラダの負荷は操作のしやすさ。これらがトレードオフになる場合においては、その操作の利用頻度をベースに検討する。

利用頻度が少ない場合はアタマの負荷軽減を優先する。遭遇したときに理解しやすいようにしておくべき。

利用頻度が多い場合はカラダの負荷軽減を優先する。数を重ねるとユーザが覚えることが増えるので、楽に操作できるほうが好まれる。

ルールは大きいものを優先して決める

共通ナビゲーションやカラーを後から適用するのは難しい。文字サイズやリンクの色のような小さいルールは適用しやすい。

ただし、ルールを決めたとしても全ての要素で厳格にルールを遵守することが現実的には難しい。一貫性を緩めた結果UXがよくなることもあるため、目的を履き違えないこと。

労力で良し悪しを判断しない

デザインするためにかけたコストをデザインの判断基準に持ち込みたくなるが、それにとらわれないように注意する。提供価値にフォーカスして判断する。

動かさないと分からない部分もある

画面遷移中のアニメーションなどは想像しにくい。動かすことで気づく要素も多分にあるので、実際に開発してみるのもあり。

工業製品に比べてソフトウェアは試作コストが低いので、そのアドバンテージは生かしてみる。ただし早く失敗することがその後の改善につながるので、バランスとか慣れとかそういう話になってきそう

人間の想像力には限界があるので、自分(とチーム)がどこまでイメージできるか把握することが次に繋がりそう

あえて戻るボタンを実装する

iOSもAndroidも、OS側で前の画面に戻る仕組みを提供しています。更に、アプリ上部のAppBarは戻るボタンが置かれていることが一般的です。

たとえば、AndroidのGoogleKeepのメモ画面ではこんな画面デザインです。

課題感

一般的なモバイルアプリは、ユーザが画面上部から下部に向かって注意を払い前提で作られることが多いです。OS側で検知できるアクションが多いものの、画面スクロールとタップが操作の中心になります。

しかしOSあるいはAppBarのアクションのみで戻れるUIは、その流れとは別の操作を強いることになります。画面外からのスワイプジェスチャーは他の操作と異なるし、左上の矢印は右手の親指からは一番遠い位置にあり、タップがしづらいと感じます。個人的にスワイプジェスチャーは慣れると直感的でいいと感じるものの、ユーザリテラシーに依存する操作のような気がするし、スクロールやタップに比べると少しコツが必要です。

アイディア

もしこの課題感を解決するなら、画面の最下部にあえて戻る用のナビゲーションボタンを配置するのが良いと考えています。多少実装コストは必要ですが、単純に戻れる以上のUX的なメリットがあるからです。

1. ユーザ操作にリズムが生まれる
2. コンテンツの終わりが明確になる

ユーザ操作にリズムが生まれる

リズム と表現していますが、アプリ内で操作に統一感を出すとか、そういった話です。事業の成長に伴いアプリの機能が増えて複雑になる、というのは何処の企業でも発生しうる課題です。それをどうにかして緩和して、如何にユーザに受け入れてもらえるか工夫をするのが、UXデザイナーの仕事だと思っています。

画面の最下部に別画面のナビゲーションを追加することで、先程書いた

ユーザが画面上部から下部に向かって注意を払い

という流れがより強化され、ユーザはシームレスに次のステップに移動することが出来ます。

Webでは行き止まりが無くなるように工夫しているプロダクトをよく目にしますが、モバイルアプリに関してはこの考え方が浸透しきっていないように思えます。toC系サービスだとおすすめの〇〇とか関連〇〇のようなものを表示していることがありますが、toB系ではとあるステップの最後の画面が出来た段階で検討が終わり、ユーザが頑張って最初に戻る操作をすることを暗黙的ルールになっていることも多いのではないでしょうか。

このあたりの課題が簡単なコンポーネント一つ追加するだけで解決できるなら、たとえ重複している機能だとしても実装の納得感があります。

また、とあるタスクの実行するモーダル画面では画面最下部に OK キャンセル 的なボタンを配置していることが多いです。画面最下部にアクションボタンを置くことは、こういったUIとの親和性もあり、統一感を出すことに繋がります。

コンテンツの終わりが明確になる

いつ終わるのか分からないコンテンツを見ることは、ユーザにストレスを与えます。一般的にそれを解消するためにスクロールバーを表示することが多いですが、ナビゲーション用のボタンを設置することで、ユーザはページの終わりを認知し、より達成感を感じられるようになります。

追加読込するリスト画面が多いアプリを操作している場合、ユーザは所見の画面の画面下部で追加読み込みの可能性を考えます。その時、明確に終わりを教えてあげることも、ちょっとしたサポートに繋がります。

まとめ

必ずしも必要ではないものの、あったらより良くなりそうなナビゲーションボタンを提案してみました。プロダクトの性質によってページの回遊をどのくらい重視するかは変わると思います。今よりもちょっと回遊を増やしたいときのオプションとして、検討してみてはいかがでしょうか。

通知画面の未読・既読はあまり機能していない説

本当は最初に色々書いたけど、収集つかなくなってしまった。なので箇条書きのメモ

• 通知画面がサービスのタスク一覧の役割を持つことがある
• 通知は既読管理されていることが多く、その殆どが通知をタップしたかどうかである
• 通知のタップとタスク完了がイコールであることが少ない。結果、ユーザが求める振る舞いと期待値とずれる
• 必要なのは通知一覧なのか、それともタスク一覧なのかは立ち止まって考えたほうが良いかもしれない