格言：大本あかね / 記事作成：あやぱん、イケダマリカ / イラスト：ナユミ
コンセプトが話題のイベントに行ったところ、思ったよりも楽しめずがっかりしてしまったといった声をSNSで目にすることがあります。「暑い場所で長時間待機するため疲れて諦めて帰ってしまった」「イベントで飲食ができるのにトイレが会場内に無く、係員に聞かないと再入場手続きがわかりづらい」など、コンセプトがよくてもイベント来場者の状況を考慮できていない不備のせいで嫌な思いをしてしまうと、楽しい体験が台無しになってしまいます。
サービス・システムでも、設計やコンセプトがとても話題になったのに、いざローンチしたらユーザーに使われなくなり数ヶ月でクローズ…というケースは少なくありません。設計段階ではユーザーの利用シーンやコンテキストを考えられていても、開発が進むにつれて作ることにばかり意識がいってしまい、ユーザー視点がなくなっていたりはしませんか？理由は様々ですが、設計、コンセプトがいくら良くてもできあがりが悪ければ何の意味もありません。
できあがりの悪い例
反応・読み込みに時間がかかりすぎている
機能やモーションを充実させた結果、レスポンスに時間がかかってしまう…ということはありませんか？また予想以上に多くのユーザーが利用した場合に、アクセスが集中してさらに読み込み時間が長くなったり、アクセスできない自体が発生するかもしれません。
エラーやバグが多く、そもそも使えない
開発期間が短く十分にテスト期間がとれなかった場合など、エラーやバグが多く発生しそもそも使えないというサービスも少なくはありません。
できあがりの悪いものを生まないために
ユーザー視点を持ち続ける
冒頭にも述べたように開発フェーズに入ると、どうしても作ることに集中するあまりユーザー視点を見失いがちです。設計フェーズにしっかりユーザー理解を行って全プロジェクトメンバーが共通認識を持ち、開発の合間でも「週に1回はペルソナやカスタマージャーニーマップを見返す」など、認識の再確認するタイミングを意識的に設けることで改善されるかもしれません。
開発チームのマインド・コミュニケーションを改善する
開発チームが「頼まれた通りに作ればそれで良い」「設計の不備に気づいても、関係性的に言えない」といったマインドに陥っていませんか？
設計の段階で考慮が漏れている課題が、実装段階で明らかになることもあります。開発チームが「ユーザーがどのような状況（コンテキスト）なのか」を理解し、「そのために最適な実装になっているか」をオープンに話せる、実行できるという状態を作ることが大切です。UXerは開発チームからの意見を尊重し、ときには意思決定者への決裁を橋渡しするといったチームコミュニケーションを円滑にする役割ができるかもしれません。
テストの重要性
前述の悪い例は、テストを行うことで未然に防ぐことができます。「テストはお金や工数がかかるから」と思われるかもしれませんが、テストをせずにローンチしても、結果としてユーザーに受け入れられなければ本末転倒です。
また、「誰でも当たり前に使えるか」という操作性やユーザビリティに関しては社内メンバーに被験者になってもらう「セルフユーザビリティテスト」を行うなど、比較的安価に・簡易に行う手法もあります。まずは自分たちのできる小さな範囲からテストを習慣化させていくことが重要です。
