どうも上かるびです。
先日「インターフェースデザインのお約束 優れたUXを実現するための101のルール」という本を興味本位で購入したのですが、実装者にとっても勉強になることが多く書かれていたのでまとめてみました。
ためになったね～。ためになったよ～
買うきっかけとなった衝撃的なページ
- 概要
- コーダー・エンジニアも知っておきたい「インターフェースデザインのお約束」リスト
- 006 まだ先があることは省略記号で表せ
- 008 文字色と背景色のコントラストの黄金比は4.5 : 1
- 013 動詞は受動態よりも能動態で
- 022 ボタンにはボタンらしい体裁を
- 024 ボタン全体をクリック可能にせよ
- 027 デバイスにもともと備わっている入力方法を利用せよ
- 028 年月日の選択用のコントロールは？
- 032 選択肢が2、3個しかない時にドロップダウンメニューを使うな
- 034 リンクはリンクらしい体裁にせよ
- 035 タップ可能な領域は指先サイズに
- 039 フォームへの入力データは極力その場で検証せよ
- 058 無限スクロールはフィード型コンテンツ限定に
- 069 ハンバーガーメニューなんて使うな
- 071 言葉で説明するのではなく、見せろ
- 081 アプリの評価依頼のポップアップなんてやめろ
- 087 色覚障碍者に配慮して色情報は補助情報と見なせ
- 088 画面表示の拡大・縮小は常に可能にせよ
- 092 デフォルト設定を過小評価するな
- 097 「それ、モバイルでも動く？」はもはや過去の質問
- 100 ダークサイドには加担するな
- まとめ
概要
本書は101のルール＋訳者が考える10のルールで構成されています。
全部はご紹介できないので個人的に実装者として勉強になった項目や「これってどうなの？」と疑問に思った項目などをピックアップしました。
著者について
Will Grandt（ウィル・グラント）
UI/UXエキスパートならびにデジタルプロダクト・デザイナー。
コーダー・エンジニアも知っておきたい「インターフェースデザインのお約束」リスト
※見出し番号は本書に書かれているもので、特に意味はありません。
ここから基本的な文章は引用になるため、常体で書かせていただきます。
本書はオライリー本のため、英語の命令文とかを訳すときに言葉が強くなってしまうせいか、わりと攻撃的な言葉遣いが見られます💦その辺はご理解ください。
006 まだ先があることは省略記号で表せ
ボタンをクリック（タップ）したらどういうことが起きるのか（たとえば次のようなことが考えられるが）、それをユーザーにどう伝えればよいだろうか。
- 今ユーザーの目の前に表示されている「対象」が削除される
- 削除する必要があるのはどの「対象」なのか尋ねられる
- その「対象」を本当に削除したいのか確認される
- すべてが直ちに削除される
このような場合、そのボタンに「削除…」というラベルを添えておけば、ユーザーはすべてが直ちに削除されてしまうわけではなく、削除の前にもう１ステップあると察するはずだ。
Adobe XD のメニュー内の例
20年くらいパソコン使ってますがこの認識ずっと知らなかったです…。義務教育で教えた方がよいのでは。
008 文字色と背景色のコントラストの黄金比は4.5 : 1
テキストおよび文字画像と、その背景との間には、少なくとも4.5 : 1のコントラスト比を確保する。
（中略）
マーケティングチームから「コントロールに添えるテキストやアプリ内のキャッチフレーズは、コントラストの低い色の組み合わせにせざるを得ない。ブランディング効果を出すだめだから仕方ないのだ」と言われたら、「ブランディング効果うんぬんの基準を押しつける相手を間違ってるんじゃないのか」と言ってやれ！
基本的にはツールなどを活用してコントラスト比をチェックするのがよいかと。少し前にTwitterのお知り合いの方に便利なツールを教えていただいたので共有します！
013 動詞は受動態よりも能動態で
言葉もユーザビリティを大きく左右する。
受動態より能動態の方が迅速に理解、利用される。
(NG)：検索キーワードを入力したら、「検索」ボタンがクリックされる必要があります。
(Good)：検索キーワードを入力して「検索」ボタンをクリックしてください。
日本のサイトは比較的大丈夫な気がする。
022 ボタンにはボタンらしい体裁を
人間の目は奥行（立体感）を知覚するようにできているから、実生活の例に基づいたUIボタンの方が直感的にわかりやすい。（実生活のボタンは出っ張っていたり、押せば作動するということが明白な形で示されている。）
現実世界でシグニファイア※を生み出した着想を活用すれば新来のユーザーにもボタンの働きを直感的に理解してもらえる（クリック可能だと察知してもらえる）。
最後にもう１点。「逆もまたしかり」で、ボタンでない要素はボタンみたいな外見にするな。
これは本当にそう。以前に某案件でデザイナーさんに「これってボタンですか？」って聞いたことあったけど、そう感じさせた時点でNGってことなんですね。
024 ボタン全体をクリック可能にせよ
（中略）具体的には、ボタンの色が変わる、1ピクセル分ほど沈み込む、かすかな音がする、など。デスクトップアプリでマウスポインタをボタンの上にもっていくと「指差しポインタ」に変わるようにしたのならボーナスポイントを差し上げたい。
この辺も日本のサイトはちゃんとしてる気がしますね。
027 デバイスにもともと備わっている入力方法を利用せよ
iOSのピッカーコントロールなど、システムにもともと備わっているUIコントロールは、AppleやGoogleが多大な時間と金を投じて作り上げたものだ。それを活用せず、わざわざ手間暇かけて我流のコントロールを生み出すなんて、どんな凄腕プログラマーだろうが気がしれない。
iOSのピッカーコントロール
028 年月日の選択用のコントロールは？
一番のお勧めは
|
1 |
<input type="date"> |
を用いてブラウザに任せることだ。
- 「月」と「日」の選択にはドロップダウンリストを使え
- 「年」には数値入力用フィールドを使え
- 少なくともモバイルデバイスではシステムにもともと備わっている日付ピッカーを使え
032 選択肢が2、3個しかない時にドロップダウンメニューを使うな
ラジオボタンやスライダーなど別種のコントロールの方が選択肢をより良く提示できないか、検討するべきだ。
034 リンクはリンクらしい体裁にせよ
（中略）この「ホバー時のハイライト表示」は理想的とは言えない。タッチデバイスにはホバー機能がない。いや、マウスを使うデスクトップのユーザーであっても、テキストのあちこちをマウスでポイントしてリンクを探さなければならず、結局リンクが見つからずじまいという事態さえあり得る。
どんな具合に機能するのか（あるいはそもそも機能するのか否か）を確かめるためにユーザーがクリックしてみなければならないUI要素なんて信じがたい。
035 タップ可能な領域は指先サイズに
タッチインターフェースでは要素同士の間隔を程よく取ることも大切だ。
（中略）
何ピクセルに当たるかはディスプレイによって異なるが、この間隔の目安は「2mm」だ。
ボタンなどの幅に関してはAppleやGoogleでガイドラインとか出してるから一度目を通してみることをおすすめします。
039 フォームへの入力データは極力その場で検証せよ
クライアント側での検証が技術的に不可能な場合もあるが、入力エラーがあるとサーバー間との行き来するやり取りがまだるっこしいから、あくまでもクライアント側での検証を目指すべきだ。
（中略）
ユーザーが入力ミスをしたからといって、既に入力してあるデータを削除するようなことは絶対にしてはならない。
WordPressのフォームとか悪しき例になるのか…。実装方法考えなおそうと思います。
058 無限スクロールはフィード型コンテンツ限定に
コンテンツがインスタグラムの写真やツイッターのつぶやきなどのフィード型なら相性抜群だ。
（中略）
たとえば有限のリスト（メッセージやメール、ToDoリストなど）に対して無限スクロールを適用するとわかりにくくなってしまうので、フィード型限定にした方がよい。
おしゃれに見せるための無限スクロールとかは考え物ってことですね。
069 ハンバーガーメニューなんて使うな
（中略）だがハンバーガーメニューには次のような悪影響があることが調査で明らかになった。
- ユーザーの「見つけやすさ」がおよそ半分に
- タスクがより難しく感じられる
- タスク完了までの所要時間が増える
これは現実的に改善するのは難しい気がする…
071 言葉で説明するのではなく、見せろ
（中略）その第一の理由は、テキストだとユーザーが読んでくれないから、だ。本当に読んでくれない。これは私自身がこれまで数々のユーザーテストでたびたび目撃してきた現象だ。画面のテキストを、ユーザーは読んでくれない。だから使用法を言葉で説明するのではなく、実際に見せなければならない。
そういう意味でアプリやゲームのチュートリアルなどは参考になりますよね。
081 アプリの評価依頼のポップアップなんてやめろ
こんな画面、見たいやつなんているものか
「見つけやすさ」は今も昔もApp Storについて回る問題のひとつなのだ。ソフトウェアの提供元は、ランキングを上げ、検索結果で少しでも上位に食い込むためなら何でもやる。
087 色覚障碍者に配慮して色情報は補助情報と見なせ
（中略）最善の対処法は「色はあくまで追加情報とし、色情報を単独では使わない」というものだ。
（中略）
この項を書いたのは「色の区別がしにくい人々もいる（現時点で米国だけでも何らかのい色覚生涯を抱えた人が2,700万人いる）。したがってメッセージを伝える際に色情報だけに頼るべきではない」という点を読者の皆さんに認識してもらいたかったからだ。
アクセシビリティってやつですかね。この辺は実装者も気をつけなきゃいけない部分ですよね。
088 画面表示の拡大・縮小は常に可能にせよ
|
1 |
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no" /> |
このメタタグをHTMLのhead部に加えると、Androidユーザーは文字の拡大・縮小ができなくなる。視覚障害を抱えたユーザーも例外ではない。
こういうアプリやソフトは稀にはなったが、完全に姿を消したわけではない。こんなことをするデザイナーは次のどれかだ。
- レスポンシブ対応ができていない。その手法がわからないせいかもしれない
- アクセシビリティがどういうことなのか、理解できていない
- おバカ
こんなデザイナーになるな。画面の表示や操作のしかたはユーザーに任せろ。
（中略）
あらゆるサイズのデバイスで１ピクセルもずれることなく完璧に表示できるデザインなんて土台不可能なのだから、たとえばページの拡大・縮小をできなくするといった類の小細工は墓穴を掘る行為に等しい。
拡大縮小の記述だけでなく、headタグの内容に関しては実装者としてちゃんと知識としてもっておきたいです。
092 デフォルト設定を過小評価するな
（中略）大多数のユーザーはわざわざ設定メニューを開いたりせず、当初のデフォルト設定のまま使うものだ。つまり大抵のユーザーにとってはデフォルトが唯一の設定と見なしてよい。だからデフォルト値の選定はしくじれない。
パソコンのスペックもそうですが、Web業界で働いていると、自分たちの設備や知識などをゼロ地点として考えがちになりやすいと思うので気を付けたいですね。
097 「それ、モバイルでも動く？」はもはや過去の質問
今や何でもかんでもレスポンシブでモバイルファーストであって当然、「モバイルで動かないこと」は致命的な「バグ」、ましてやSEOの点では「死刑判決」と見なされる。
死刑て。
100 ダークサイドには加担するな
企業やブランドがユーザーを意のままに操るべく巧みに仕掛けたUIやUXのパターンのことだ。
（中略）
いくつか実例をあげてみるが、まず間違いなく皆さんも見かけたことがあるはずだ。
- 保険や補償のサービスへの申し込みなど、追加した覚えのない項目を、チェックアウト前に（ユーザーが削除しないことを期待しつつ）勝手に追加してしまうショッピングカート
- 検索結果を関連性の高い順に表示せず、アプリ（サイト）の制作者側がユーザーに売り込みたいものをトップに表示してしまう検索機能
楽●やYa●ooとかAmazon以外のショッピングサイト使うと99.9%の確率でショップのメルマガに勝手に登録されるよね。。。あれがダークサイドってやつか。
まとめ
実装者としてどう感じたでしょうか。自分がやらかしていなくても、会社や所属するデザイナーさんがやらかしてしまっている項目もあったのではないでしょうか。
基本的にデザイナーさんもプロとしてやっている（はず）なので、デザインに口出しはできませんが、あまりにもひどいUI/UXがあった場合は実装者目線で指摘してもよいのかなと思います。建設的に。
こちらの書籍は初版が2019年なので2022年のUI/UX事情とは少し異なる部分もあるかと思いますが、”ユーザーにとって使いやすいものを提供する”という根っこの部分は変わらないと思います。
いちクリエイターとして、恥ずかしい真似はしたくないですね。
ぜひ気になる方は読んでみてください。
コメント