概要

新機能を実装したり、既存機能をマイナーチェンジしたりするときに拾うUIのバグというか考慮漏れ？にある程度パターンがある気がするので注意して確認するようにしている箇所について書く。

現職で主に扱うのがAndroidアプリなのでAndroidアプリベースで書いているけどtoC/toBのWebでもあ〜あったな〜こういうの〜みたいな気分で書いているのですごくRTLサポートの話以外は特殊な話はしていないと思う。

前提

f:id:wifeofvillon:20190527153117j:plain

という仕様を想定して動作確認するときに、個人的にどこを注視しているかを書く。なお、数値、文字列、画像など表示に用いるデータ自体は正しいものとする。

特にカードやリストの一部などコレクションにアイテムを追加したとき、既存部品とレイアウトは揃っているか。

1)と2)についてはRTL向けレイアウトをサポートしている場合はそこも見る。
3)についてはカラーテーマをユーザが変更出来る場合、それも考慮する。
4)についてはタップ・スワイプにリアクション音をがっつりつけているアプリだと、耳が慣れすぎて気づかないことがあるので注意しないとなーと最近思った。

f:id:wifeofvillon:20190527162052p:plain

最近あった例でいうと、上のカウンターが実装されたときに「km」「mi」が「キロ」「マイル」のように翻訳されてレイアウトが崩れた。

このケースはユーザーがどちらの単位を使うか選ぶことができるので気がついたけど、そうでなかったら「km」表記で決め打ちになっていると思い込んでいたかもしれない。「users」と「人」のように短くなるケースも文字揃えが指定されていなくてズレることがありそう。

戻る・閉じる・メニューを開くといったグローバルなボタンの位置や向きは他の画面と揃っていて欲しい。最近あった例でいうと戻るボタンをLTRで「←」のアイコンで表しているとき、RTLでは逆向きにしてあげないといけない。

あんまり起こらないケースだけど、デザインを他の画面とは違うテイストで新しく作ったときには要件レビューの時点で気づけるとみんな幸せに過ごせると思う。

画面部品のレイアウトの話に加えて、いわゆるトンマナ¹に沿ったデザインであるかも確認したい。

カラールールをどこまで厳格にするかはプロジェクトや企業によると思うけど、今の職場は割と決まった色の中でやろうとする傾向がある。特にデザイナーに画像を作ってもらわないといけない箇所は手戻りが大きいので、これも要件レビューの時点で気づいておきたい。

f:id:wifeofvillon:20190527165825j:plain

既存画面Aからも新画面Cからも画面Eに行ける場合、「戻る」ボタンの戻り先はどこなのか。ありそうなケースは

みたいなやつ²。この例えの場合「新機能！」をタップしてきた人が「戻る」を押した場合遷移先は設定画面なのかホーム画面なのかが明文化されていないケースはエンジニアやデザイナーに確認する。

仕様書の粒度はプラットフォームにもよるしデザイン体制にもよると思うけど、部品の追加だけならともかく、画面追加や画面遷移の変更を伴うアップデートの考慮漏れは先に確認しておいた方がテスト担当は安心できる。

仕様書が文書じゃなくてAdobe XDとかSketchとかで作ったプロトタイプの場合も戻り先がわかるようになっているとありがたい。

トンマナとは - Webマーケティング用語｜ferret [フェレット]↩
先に思いついたのが某スマホゲームでキャラクターのレベルが上がってプロフィールが解放された後、ダイアログのボタンから直接プロフィール画面を開いて「戻る」を押すと開きっぱなしの「解放されました」ダイアログに戻るっていうやつだったんだけど、例として不適切な気がしたのでやめた。↩