ボタンのラベルやダイアログのテキストを決めるとき、
「日本語としてどの表現が正しいのか？」
「UIとしてはどの表現が分かりやすいのか？」
…等々が気になります。
あとで読み返せるように、調べたものをピックアップしました👇

動詞を使う

• OK例：「消去」「保存」

• 分かりにくいボタン例：「はい」「OK」

• 考察：ダイアログ内のテキストをすっ飛ばしてしまうユーザーがいると仮定した時に、「消去」「保存」のような動詞がボタンのラベルになっていたほうが、ユーザー目線では素早くタスクを完了出来るなと思いました。

専門用語ではなく、ユーザーの言葉を使う

• OK例：「シカゴ - オヘア空港（ORD）」「ロサンゼルス - ロサンゼルス空港（LAX）」

• 分かりにくいボタン例：「ORD」「LAX」

• コメント：前職では専門用語ばかり飛び交う職場にいながら、クライアントには平易な言葉で報告をする、ということが日常茶飯事でした。なので「これは当たり前じゃん！」と思った一方で、「何が専門用語なのか（何がユーザーにとって平易な言葉になりうるのか）」は常に考えなければならないな、とも思いました。（みんなに伝わると思っていた単語が、実は伝わらない、ということも度々ありましたので…。）

選択肢の文言は肯定文にする

• OK例：「新幹線（チェック）」「飛行機（チェック）」

• 分かりにくいボタン例：「新幹線を利用しない（チェック）」「飛行機を利用しない（チェック）」

• 考察：中学校で英語を習っていた時、「否定の否定（肯定）」みたいな表現が苦手でした。There was no one but thought he was dead.みたいなやつ。一瞬頭がこんがらがるというか。なので肯定文でラベルを作る、はそりゃそうよね、と思いました。

エラーが発生したときは①何が起きた？②何をすれば解決する？を伝えよう

• OK例：このページはありません！

• 分かりにくいボタン例：エラーコードxxxxx

• 考察：やはりこれも「ユーザーはタスクを完了させたい」という前提に立つと、ネクストアクションを提示することは必要だと考えます。

• 関連：Empty Stateで何を表示するか？といった話にも関連するかと思いましたので、ページ最下部でEmpty State についても補足的にまとめてあります✌

言語による文字数変動を考慮してラベルとボタンの大きさを検討する

• 日本語や中国語などの漢字が含まれる言語、ハングルなどの言語は文字数が短くなる傾向。ボタンの横幅を文字数に合わせている場合、極端に小さくなりすぎないよう（押しにくいサイズ感にならないよう）注意が必要。

👇以下からは、直接ボタンのラベリングやダイアログのテキストには影響しないものの、画面設計する上で参考になりそうなものを集めました！

そもそもそのダイアログ、表示させる必要ありますか？

• データ消去など、操作が不可逆の場合に確認ダイアログを表示させる。（前提として、UIは可逆性があったほうがより望ましい）

肯定／否定ボタンの配置はプラットフォームのルールに従う

• 個人的な感覚としては、

  • 左右に並ぶボタンの場合：「左が戻る」「右が進む」という印象です。

  • 上下に並ぶボタンの場合：「ユーザーが完了したいタスクの優先順位次第で配置が変動する（優先順位が高いものが上とか、4原則の整列になどを考慮）」という印象です。

• …という前提に立った時、Windowsだけがこの感覚とズレているボタン配置になっていて、その他のプラットフォームは概ね上記の左右のボタンの感覚にあっていました（上下配置については言及なしのため、上記はあくまで推測の域を出ません）

可能性と確率を区分する

• このガイドラインだけ若干読解が難しかったので、まずは言葉の定義から整理しようと思います。

  • 可能性：ある事象が発生できる見込み。

  • 確率：ある事象が発生すると思われる度合い。可能性を数字で表したもの。

  • エッジケース：ユーザーが遭遇する可能性がある、稀なバグ。

• 発生しうる（可能性のある）ユーザーの操作に対して機能を実装すると、UIは複雑で使いにくくなってしまう。そのため、可能性ではなく確率に注目する。確率の低いものは（可能性として優先順位が低いと想定されるものは）オプション機能として取り扱おう、という話でした。

その他、参考URL

おまけ：Empty State 

こちらでは、主に下記の2点をまとめてみました。
1．Empty State が使われるケース
2．各ケースにおいてユーザーに伝えるべき内容

• データがないケース（そもそもデータが1件も存在しない、プロダクトの初回利用時など）

  • 「システムエラーではなくデータがないこと」を伝える

  • 別条件で検索することなどを促す

• データがなかったケース（検索結果など）

  • 検索結果に問題があったことを伝える

  • 別条件で検索することを促す
    ※空白画面はNG。検索途中であると誤認される可能性があるため。

• データがなくなったケース（データ削除時、タスク完了時など）

  • 可能であればEmpty Stateを表示するのが好ましいが、このケースは表示しなくても大きな問題はない。

  • データが無くなったことがポジティブな場合（タスク完了時等）は、ねぎらいの言葉があるとベター

• その他、参考URL

  • Empty Stateの活用事：https://hikarina.co.jp/blog/emptystate_mokuteki/

  • マテリアルデザインガイドライン（M2）：https://m2.material.io/design/communication/empty-states.html