概要
基本的に、Webサービスなどの開発フローには主に3つの役割が関わってきます。
- 機能を考える
- 機能をデザインする
- 機能を実装・検証する
流れとして、サービスを運営する事業部やサービスの企画担当が、機能のアウトラインとなる要件を整理して、画面仕様として言語化、図示で表現します。
その資料より、デザイナーがデザインツールでページの見た目やパーツUIを作り、エンジニアがそういった画面仕様やデザインを元に実装、QAで動作検証を行います。
これは、会社の規模や組織体制によって変わる場合があります。
デザインフィードバック(デザインチェック)は、デザイナーが作ったアウトプットに対して、第一に要件通りの機能がUIで表現されているか、第二にそのデザインが開発するエンジニアから見て考慮漏れや認識齟齬がないことを確認するステップです。
筆者はフロントエンドエンジニアをしている関係上、デザインから実装する時に、「これは〇〇で懸念がありませんか？」「ここは〇〇ではなく××では？」といったやりとりをしています。
そこで出てきたフィードバックは、過去のプロジェクトでも指摘にあがったことがあり、今後のプロジェクトでも活用できるよう、フィードバックを整理し言語化することにしました。
本記事の対象
- デザイナー
- サービス企画・事業部
- フロントエンド・アプリ・バックエンドエンジニア
- QA
Webサービス前提でまとめましたが、アプリでも活用できるところがあります。
デザインアウトプットをレビューする機会のあるサービス企画やエンジニア、QAがどこに気をつけるかの参考になれたらと思います。
デザイナーにも、いちエンジニア視点としてこういうところをチェックしているという共有として知ってもらえるとうれしいです。
また上記に限らず、これからデザイナーやエンジニアになりたいと考えている人にとっても、ちょっとしたヒントになれたらと考えています。
背景
これまでデザインレビューしてきた中で、主なフィードバックの共通項として 「表示パターンの網羅性」 があります。
フィードバックが出てくる背景の一つとして、仕様を決めるサービス企画にとって、要求された機能が使える見た目になっているかどうかの観点でチェックするため、他に表示しうるパターンがあることを考慮に入れていない、あるいは重視していないのかもしれません。
それと、エンジニア視点から見て、画面内の要素は大きく以下の2つで構成されています。
- 静的要素
- ユーザーのアカウント環境や入力情報に左右されない、ハードコーディングされたデータ
- 動的要素
- アカウント環境やユーザー入力情報、時間経過によって切り替わるデータ
- 投稿内容
- タイムライン (プロフィールの公開設定、フォロー関係、アクセスした時間によって変化)
- 外部データ (株価、天気情報など)
- 多言語テキスト ※英語、中国語などの多言語切り替えサイト
- アカウント環境やユーザー入力情報、時間経過によって切り替わるデータ
この静的・動的要素が、画面仕様作成時で明確に切り分けされず、その情報からデザイナーで見た目やUIを調整して、レビュー時に開発サイドで考慮するべき動的要素のパターンが見つかってしまうのではと考えています。
それから、デザインFIX後にサービス企画とエンジニアで機能ベースの細部でやりとりする機会が増えていき、その過程で考慮すべき表示パターンの漏れ抜けが発覚する場合もあります。
フィードバックポイント
それではデザインを見て確認しているポイントを、以下紹介していきます。
1. 動的要素に対する表示パターンの洗い出し
実は、前述の動的要素も状態ベースで見ていくと、2通りに分類されると着目しています。
- データ取得状態 … データ取得段階の状態
- データ表示状態 … データを表示する時点の状態
データ取得状態は、APIで必要なデータを取得しようとしている、あるいは取得できなかった時の状態を指します。一方、データ表示状態は、データ取得に成功してそこから表示する時のバリエーションを意味します。
例えば、バックエンドAPIや外部サービスのAPIを使って表示するリストがあるとすると、先の状態ベースを元に以下のような表示パターンが想定されます。
| 状態別タイプ | 想定ケース | 表示パターン(想定) |
|---|---|---|
| データ取得状態 | リストの読み込み中 |
|
| 読み込みエラー |
|
|
| データ表示状態 | リストが0件 |
|
| リストが100,200件以上(*) |
|
データ取得段階は、APIよりデータを取得中(読み込み中の状態)のケースもあれば、その後接続エラーや認証エラーなど何らかの理由で失敗するケースが考えられ、そうしたステータスがわかる表示にする必要があります。
データ表示状態の場合、データ取得に成功したものの、登録データが0件であったり、逆に登録件数が何百件もあることが想定されます。
0件ならデータがない旨の表示をしたり、何百件もあるなら無限スクロールで少しずつ見せるのか、「もっと見る」ボタンで一部を先に見せるなどの手法が考えられます。
なお、(*)のケースは、画面仕様やデザインで想定されていない件数を指しています。登録数が増えると、表示制御をかけないとリストもその数の分だけ表示されますが、その点が考慮されず、画面設計やデザインで数件だけ表示する表現になってしまいます。
どのような見せ方をするかは、参考にしている他社サービスの事例やUX、サービスの種類、現状の実装に左右されますが、見せ方の方針を決めたら、デザインもその表示パターンを追加で用意することになります。
ただ、似たようなUIが画面上に使われて、その度にバリエーションを用意するのはデザイナー・エンジニアにとってやや煩雑になります。そこは相互にコミュニケーションをとって、リストなら全てのリスト(一部例外あるものは除く)に適用できるパターンを定義しておくと、UIルールも一貫性が取れるし、実装サイドも流用が効きます。
2. 動的要素内の表示パターン洗い出し
前項では、動的要素に対する「取得過程の状態や表示の有無やその数」についてフォーカスしましたが、その動的要素がより粒度の小さい動的要素で構成されていたりします。
先ほど例にあげたリストの中身が、仮にユーザー投稿型の質問とすると、
- 質問タイトル
- 説明文
- 添付画像
- カテゴリ
- タグ
- いいね数
- ブックマーク数
サービスにもよりますが、このような要素が含まれたりします。
その場合、それぞれの要素で以下の表示パターンが考えられます。
- 全ての要素が揃っている
- 最低限の要素しか表示されない
サービス企画担当は、前者の要素が全て揃った1パターンで画面仕様を作成する傾向があり、添付画像やタグがなかったりと一部しか表示されないパターンがデザインに反映されないことがあります。
表示パターンを考えるヒントとして、画面を構成する投稿作成画面があれば、その画面で任意項目となっている箇所は、登録後に一覧や詳細画面で表示されないことが想定されます。
一方、株価や外部サイトの情報を取得して表示するタイプは、何が表示されないのか判断しづらいため、担当のエンジニアが該当箇所を洗い出しデザイナーに共有する必要があります。
3. 動的テキスト要素の表示パターン
前項の「動的要素内の表示パターン洗い出し」に関連して、タイトルや説明文はユーザーが入力するため、文字数が可変になることが想定されます。
例えば、DBに保存できる説明文の文字数が500字や1,000字あると、一覧画面のリストで全て表示するには1件1件が見づらくなってしまいます。
デザインでは表示するテキスト文字数を決めていない見た目になっていることがあり、それを考慮した対策をデザイナーと考える必要があります。
一例として、詳細画面では全文表示するとして、一覧画面では一定の文字数まで表示して、それ以降は「...」で表示して、「詳細を見る」ボタンで詳細画面に誘導するアプローチがあげられます。
4. UIコンポーネントの整合性
デザイナーがページのデザインに着手する前に、汎用的に使われる共通のUIコンポーネントを用意することがあります。
ただ、表示バリエーションはデザインツールで可視化されていても、そのコンポーネントのUIルールが明示・共有されていなかったり、ページデザインを作るにつれて、当初のUIルールから想定していないケースが出てくることがあります。
ボタンを例に取ると、共通コンポーネントのデザインでは、ボタン内部のラベルから固定値の余白(padding)をとったものをボタン幅として表示しているものがあるとします。その後、上下左右固定の余白の他に、幅を広げたタイプのボタンが必要になることがあります。
また、ボタン内部のラベルに応じてボタン幅も変わるルールの場合、極端な例ですと、ラベルの文字数が少ないと一見想定しないボタンの形状になることも考えられます。
デザイナーのアウトプットと並べられたバリエーションだけでコンポーネントを開発する際に、どういったUIルールで作られているのかデザイナーと細部にわたって確認し、すり合わせすることが大切です。
それと、デザイナーやエンジニアともに、UIコンポーネント作成時点では想定し得なかったバリエーションが開発・運用フェーズで出てくることは予め許容しておく必要があります。
ただし、バリエーションが乱立してそのまま全て取り込もうとすると、コンポーネント内部の制御が複雑化する懸念があります。デザイン観点では「UIルールを拡張しつつも汎用的な用途として縛りを一定度に保つ」ことを留意し、コンポーネントを開発するエンジニア観点では「さまざまな表示バリエーションをデザイナーと認識合わせしつつ、整理・抽象化する」ことが必要になると考えます。
先のボタンバリエーションでは、一例として以下のような対応が考えられます。
- ボタン内に固定値余白をとる表示をデフォルトにして、オプションで幅一杯に広げるバリエーションを親コンポーネントから制御できるようインターフェースとして追加する(どちらがメインに使われるかによってデフォルト・オプションを入れ替える)
- 文字数が少ない場合を考慮して、ボタンの最低幅を決めておく
5. アクセシビリティに配慮したUI
ボタンやリンクといったクリック可能な要素も、見せ方次第で使いづらくなります。
- 一定以下のサイズになっていてクリックしづらい
- クリック要素が間隔狭く並んでいるため、誤タップされやすい
- ボタンやリンクと判別しづらい (リンクに下線がついていない、ボタンと認識しづらい外形と、周囲に溶け込みやすい見た目になっている)
このようなUIは、アクセシビリティ、ユーザビリティにおいて好ましくなく、ユーザーが使いづらさを感じる要因にもなります。
それに、リンクに下線がない代わりに文字色だけ変えているものもありますが、これは色が識別しづらいユーザーにとって、リンクと認識しづらく見える可能性があります。
クリックできるUIのサイズや余白が適切か、はじめて使うユーザー目線で見た目がボタンやリンクとして認識しやすいかをチェックすると良いと思います。
クリック要素だけでなく、使われる色のコントラスト、使うユーザーの身体的状況(色覚障害や高齢者など)や動画や音声などの要素と、アクセシビリティで考慮するところは多くあります。
そうしたアクセシビリティに関するガイドラインをいくつかの会社で公開しており、サイバーエージェントが公開している Ameba Accessibility Guidelines がわかりやすい表現で具体例を示しているので、参考にしてみると良いでしょう。
6. チャートやグラフデザインのカスタマイズ
ユーザーステータスの推移を表示する上で、チャートやグラフで表現することがあります。
ただ、チャートやグラフの見せ方もサービス独自にしようとすると、フィジビリティ調査や実装期間が別途かかり、リリースに影響する可能性があります。
チャートやグラフをカスタマイズして相当以上の効果が見込めるのなら、ある程度時間をとって調査や実装を進めるのも良いです。そうでない場合は、フロントエンドで使えるUIライブラリをベースに、色や形のカスタマイズを範疇内で行えると望ましいと考えます。
こうしたビジュアル表現について、デザイナーと相談して代替的な手段を選択肢として用意しておくと良いでしょう。
7. ユーザーステータスに応じた表示切り替え
SNSサービスでは、ユーザーのプロフィール公開設定や、閲覧するユーザーとの関係によって、ユーザーごとに表示される情報も異なってきます。Facebookを例にすると、イベントやグループといった機能もあり、ユーザーの参加状況によっても変わってきます。
SNSに限らず、使うアカウントによって使える機能が制限されたり、アクセス自体不可になることはWebサービスで往々にしてあります。
他社事例をベンチマークしたり、ビジネスサイドやデザイナーと対象ユーザーの状態遷移を共有した上で、表示切り替えのパターンを整理するのが良いと考えます。
8. UI細部の確認、テキスト表現
最後、これまでと比べて重要度は高くなく細かい部分になりますが、フィードバックの段階で押さえておくと後々楽になるポイントです。
UIで左右の余白が違ったり、共通で定義しているカラーパターンと微妙に違う色が使われていたら、それが意図したものなのかをデザイナーに確認してみましょう。細部で意図していない箇所があったら調整してくれることがあります。
それから、エンジニアにとって担当外なところですが、画面仕様から落とし込まれたデザインの中に、見出しや説明文で誤字脱字や表記揺れ、伝わりづらく誤解を招く表現などを見つけたら、サービス企画やデザイナーと適切な言い回しにできないか相談してみると良いでしょう。
細かいところですが、早いうちに気づいて関係者に確認しておくと、見過ごして後々見つかり修正する手間が省けたりします。
対策
こうしたフィードバックのナレッジは、組織内で蓄積しているところもあるかもしれませんが、共有されない限り個々人の経験に基づいたものになりがちです。それは、フィードバックに関わる人が限定的なのも一因としてあげられます。
私自身、そうしたフィードバックのポイントをまとめたドキュメントや資料を会社で見たことがありませんでしたが、やはりデザインをチェックする立場として、こうした観点を言語化しておくと、フィードバック基準が明示化され、今後新しい人がチェックする時の判断材料にもなります。
なので、こういったチェックシートを用意して、担当サービスででた懸念点を今後チェック項目として追加更新していくのが良いと考えています。
| No. | チェック項目 | 説明 | 結果(OK/NG) |
|---|---|---|---|
| 1 | 動的要素に対する表示パターンの洗い出し | データ取得状態・データ表示状態(APIでデータ取得中・成功・失敗)の表示パターンが網羅されている | |
| 2 | 動的要素内の表示パターン洗い出し | 全要素が揃っている・一部要素のみ表示のパターンが網羅されている | |
| 3 | 動的テキスト要素の表示パターン | テキスト文字数が可変になることを想定したデザインになってい | |
| 4 | UIコンポーネントの整合性 | デザイナーと、コンポーネントに対するUIルールの共通認識が取れていて、表示バリエーションが網羅されている | |
| 5 | アクセシビリティに配慮したUI | クリック要素を例に取ると、サイズや距離が適切であること、クリックしやすい見た目になっていること | |
| 6 | チャートやグラフデザインのカスタマイズ | チャートやグラフなどどこまでカスタマイズが必要になるか、実装が難しい場合代替手段を提示、合意をとっていること | |
| 7 | ユーザーステータスに応じた表示切り替え | アカウントのステータスに応じて、サービスが提供する機能が制限された場合の見え方のルール、表示パターンが定義されている | |
| 8 | UI細部の確認、テキスト表現 | デザインの色やサイズ、マージンに統一性がある、見出し・説明が誤字脱字なく伝わりやすいこと |
まとめ
デザインフィードバックは見た目なんとなく揃っているからとそのままOKを出すと、そのままうまくいく場合もありますが、デザイナーとエンジニアで認識が違っていたとか、この表示も考慮しないといけなくなったりと、デザイナーとエンジニアでお互い追加作業が発生することになり得ます。画面仕様やデザインで想定されていない点を拾い上げていく工程は、大変ですがあらかじめ設計に落とし込む材料になるので、時間をとって「こういう場合はどうなるだろう」と想像しながら、チェックすることをおすすめします。
そうした積み重ねで、仕様を作る側と見た目を作る側にも知見として貯まり、お互いに気をつけていけたら、フィードバック確認の負荷も少なくなるでしょうし、部署間のコミュニケーションも活性していくことだろうと思います。