レビュー相手の決め方
社内ポータルのUIレビューは、実際に日常使いするユーザー代表を必ず含める。情報システム部門の目線だけでは「使う人にとっての使いやすさ」が抜けやすい。部署ごとに1名のユーザー代表を選び、代表者と設計者でURLを共有するコアグループを作ると意見が集約しやすい。
経営層へのレビューは設計の初期段階より方向性が固まった段階で行う。初期モックの段階で経営層の細かいフィードバックを受けると仕様が定まらなくなるため、レビューのタイミングと目的を段階ごとに設計しておく。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
認証方式の選び方
社内の全社員に見せるUIレビューは会社ドメイン認証が適している。導入後の混乱を減らすために幅広い部署から意見を集めたい場合、パスワードを配布する手間なしに全社規模の確認ができる。
外部ベンダーや受託開発会社がモックの作成に関わっており、その担当者にも確認してもらう場合は、メール個別認証で必要最低限のアカウントだけアクセスを許可する。プロジェクト終了後に一括で失効させられるため、権限の棚卸しが容易だ。
- 誰でも見てよい: URL共有のみでもよいが、検索除外は確認する
- 特定の相手だけ: パスワードまたはメール認証を使う
- 会社内だけ: 会社ドメイン認証を検討する
- 短期レビュー: 期限を設定して古いURLを残さない
フィードバック回収
ポータルのUIレビューで回収すべき観点を「主要機能への動線がわかるか」「文言は業務用語として適切か」「使用頻度の高いページがすぐ開けるか」の3点に絞る。この3点に答える形式でフィードバックシートを作成し、URLと一緒に送ることで収集した意見を比較・集計しやすくなる。
フィードバックが口頭で得られる場合は、5〜10名のユーザーと15分ずつのウォークスルーセッションを組む方法も有効だ。URLを画面共有しながら「このボタンを押すと何が起きると思いますか？」のように問いかける形式は、テキストコメントでは気づきにくい直感的な問題を早期に発見できる。
- 確認してほしい観点を3つ以内に絞る
- 期限と返信先を明記する
- 修正後も同じURLで見られるか伝える
- 最終版と途中版が混ざらないようタイトルを付ける
公開終了の処理
試作のレビューが終わりHTMLの役割が終わったら、URLを即座に無効化する。社内でURLが広まっている場合は無効化後のページに「このモックは検討終了です。最新情報は○○にアクセスしてください」というメッセージページを置くと、古いURLにアクセスした人が迷子にならない。
プロジェクトの承認が得られずにモックが破棄になった場合も同様に無効化する。検討中止になったUIデザインが社内に残ったまま参照され続けると、再検討の際に混乱のもとになる。ファイルは社内ストレージにアーカイブし、公開URLだけ終了するのが適切な処理だ。
よくある質問
試作HTMLのレビュー中に設計者がリアルタイムで修正を反映したい場合、どうすれば最速で対応できますか？
修正済みHTMLを上書きアップロードするだけでURLが変わらず即座に反映されます。参加者がブラウザをリロードすれば最新版が表示されるため、画面共有セッション中でもリアルタイムに近い形で修正を確認できます。
試作段階のモックをうっかり検索エンジンにインデックスされてしまわないか心配です。
ギガサイト便では認証付きのURLは検索エンジンにインデックスされない設定を推奨しています。加えてHTMLのheadにnoindexメタタグを記述しておくと、万一URLが外部に流出した場合でも検索結果には表示されにくくなります。
レビュー用のURLと開発チームが使うステージングURLを混同しないようにする方法はありますか？
URLのスラグに「review」や「mock」の接頭辞を付けて命名するルールを決めておくと区別できます。さらに試作HTML内のページタイトルやヘッダーに「[REVIEW版]」と表示するフラグを入れておくと視覚的に判別しやすくなります。