正直なところこの半年ほどの開発を遡るにあたり、要件やワイヤーをもとにUIを組んでみていざエンジニアに実装お願いします！と依頼してからシュッとそのままOKが出ることはあまりありませんでした(最近はどうだろう)。
transitkixさんの「つよいUI」については知っていたのですが、実際にプロダクトを開発していくとこの「つよいUI」であるための視点だけではちょっと抜け漏れがあったりして、考えるべきこと・着目すべき点はたくさんあるなあと実感する毎日です。
幸い、弊社のエンジニア陣は皆UI/UX的な視点も持っているため実装をお願いする前に必ずレビューしてもらうようにしているのですが、ここで抜け落ちているところが出るわ出るわ。今回は「つよいUI」の視点とも被りますがこれまでの開発でエンジニアにダメ出しされた、UIをデザインしていく上で(主に私が)抜け落ちてしまいがちだったポイントをまとめてみました。
プロダクト開発初期の0→1フェーズでプラットフォームはWEB、まだUI設計はかじりはじめたよ〜というスキル感のデザイナーに特に読んでほしいですね。ベテランプレイヤーの方々はそうだよね〜くらいの感じでさらっと読んでいただけると。
【スポンサーリンク】
UIデザインでおさえておきたいポイント
ボタン編
:hover&:focusとそのtransition
ボタンをとりあえず作ったはいいが:hoverと:focusどうするのか？というフィードバックにたしかに〜となりました。デザインのトーンとしてブラウザのデフォルトのスタイルでは不適切な場合は設定した方が良いでしょう。それぞれ状態を定義したらtransitionをどうするかも忘れずに考えておきましょう。
また、自分はTabキーでボタン等をフォーカスして操作するということをしないので:focusを設定する必要性についてそれまであまり感じていなかったのですが、世の中のひとは意外とするということをここで知りました。
Loadingの挙動
Loadingの挙動はあえてボタン内に入れる必要もない(他の表現方法もある)のですが、弊社の場合はLoadingであることを伝えるべき場面がほとんどフォーム送信なのでボタンに盛り込みました。あるのとないのとでは待機時間のストレスが違いますよね。
LoadingのCSSアニメーションは参考になるコードや動きがググればそこらへんにあるので、こんな感じで〜とリファレンスをエンジニアに投げたらよしなに実装されててすごい...となりました。
:enabled/:disabled
状態として送信できるのかできないのかユーザビリティの観点で設けた方がよいということで設定しました。例えば、フォーム送信に際して必須項目を入力しないで送信するとエラーが出ますが、そもそも必須項目を入力していない状態でボタンをnon-activeであるように設定すれば送信できないのでこの無駄なエラーが出ることもないわけです。
固定or可変
ボタンを実装するときに固定幅なのかボタンの文言に応じて可変にするのかは目からウロコな部分でした。結局弊社では両方コンポーネントとしては持つことになったのですが、ボタンを他の画面でも使いまわすことを考えるとこのあたりはきちんと想定しとくべきですね。
フォーム編
:hover&:focusとそのtransition
ボタンと同じく:hoverと:focusを忘れがち。また、デザインするときのポイントとしてはブラウザのオートフィルのせいで黄色く塗られて(Chromeの場合)背景色をtransitionさせるのが無効になったりするので枠線やbox-shadowでどうにかこうにかするのが良いかと。
placeholder
placeholder自体を忘れるということはなかったのですが、様々な画面にフォームが出現しはじめた際にplaceholderの文言に統一性がなくなってしまい指摘されました。placeholderなどに入る文言はルールを設定しておくと良いです。
Error時の表示
エラーはメッセージだけで出せばいいというわけではなく明示的にどこがエラーだったのか示さなくてはいけないので必然的にフォームにはError時のデザインが必要になりました。何ならこのError時のフォームにも:hoverや:focusを設定する必要があるのですが、色を上手い具合に決めるのが難しかったです。エンジニアと一緒にペアプロしながら決めました。
UI全般編
Emptyな場合の画面があるか
テキストや画像などそこにあるべき情報がない場合のUIは必ず必要です。空白なままなのか、代替するテキスト・画像があるのか。デザイナーはテキストや画像が理想的な状態でUIを組みがちですが、実際にプロダクトを運用してみたらそんなことはないのです。
Errorの場合の画面があるか
ほとんどの画面でエラーは起こりうるのでこちらも必ず必要な画面。どんなエラーが起こりうるかはエンジニアと協力して洗い出すと良いですね(システムが複雑だとエラーを全て洗い出すのはかなり骨が折れますが)。また、ユーザーがリカバリー可能なエラーなのか否か、エラーメッセージは適切かどうかがデザインを考える上で大事なポイントでしょうか。文言もデザインの一部。
以下、エラー表示に関するTipsです。
- 即時に入力エラーをフィードバックする
- エラー箇所を指摘する
- エラー内容を具体的に明示する
- 色だけでエラーを表さず他項目と区別できるようにする
長いテキストは省略するのか折り返すのか
私が割と(今でも)抜けがちなポイント。折り返すのならどのくらいのwidthに達したら折り返すのか、省略するのなら文字数とwidthどちらで省略するのか。テーブル表示のときは特にレイアウトに大きく影響します。
ユーザータイプによる場合分けはしたか
ユーザーがログインしているかしていないか、ユーザーの権限(タイプ)によって表示される内容に変化はないかで場合分けができます。このタイプが複数あるとその分作る画面数が増えてちょっとしんどい...となりますね...。
widthの変化でどう影響があるか定義したか
最初からレスポンシブ対応を考慮していればそこまで気にする必要はないですが、ウィンドウ幅を変更したときにどうレイアウトが変化するかは気にしておくべきです。自分の環境で大丈夫なら平気なんてことはなくデバイスによって解像度は異なります(当たり前)。
他の画面への影響はリサーチしたか
開発が進んでいくうちにやっぱりこの機能必要だった！ということはたまにあるのですが、後から追加することになったその機能のせいで他の画面へも修正・追加が必要になるケースが往々にしてあります。ここのチェックはエンジニア確認の際にも漏れやすいのでしっかりチェックしたい部分です。
途中で離脱した場合はどうなるか
Onboardingをはじめとした数ステップあるプロセスにおいて考慮すべき点ですが、例えばアカウントの情報登録で途中離脱した場合はどうなるのか、どの画面に戻るのか、情報は保持されたままなのか等は論点として上がりました。ここは実装側がどう設計しているかによりそう。
リスト表示等の反復するコンテンツに対して全件表示or無限スクロールorページネーションか
リスト表示に対して全件表示なのか無限スクロールなのかページネーションを設けるのかは、そのコンテンツの量やそもそもどんなコンテンツかによって適切なものが異なります。しかし、こちらの画面ではページネーションなのに別の画面では無限スクロールにしよ〜とか安易なことはしてはいけません(自戒)。
ここらへんはSEOとの兼ね合いもあるので適した手段を取りましょう。
marginが各コンポーネントに対して一定のロジックが定められているか
「なんでこの画面ではボタンとテキスト間が28pxなのに別の画面では24pxなの！？」という自分でもどうしてこうなった...となるフィードバックが割と多くあり、スタイルガイドなりデザインガイドラインなりでちゃんと定められていればいいのですが、そんなものはまだない(あるけど決めてない)場合はありがちなポイントなのかなと思いました。ちゃんと決めたい。
最後に
それなりにきれいにUIは作れても上記で挙げたところにまで考えが及んでいないと、UIデザイナーというよりただの画面作る屋さんだなあという反省をしたので、今後の開発では気をつけていきたいです。目指せ手戻りゼロ！