前回までのおさらい
- ユーザーを調査・定義して、プロジェクトメンバーの認識を合わせてユーザーを理解しよう
- プロセスは「見える化」して共有しよう
- サービスの目的をもとに「仮説」を立てよう
引き続き架空のアプリ「おさかな王国」のアプリ制作を題材にお話ししていきます。前回はジャーニーマップを使ってターゲットユーザーの行動を定義し、新しいアイディアを考えてみました。
どんな画面にしていくか考える
さっそく情報を整理し、プロダクトの形に表現していきます。
デザインをする際、この手順でやらなければならないというルールはありません。いきなり画面イメージを作っても良いですし、要素の整理をしてから組み合わせても構いません。自由に行き来しながら試行錯誤してみてください。
では、今回の詳細な要件を定義しましょう。今回追加する機能は、
「簡単に買いたいけれど、見つけるまでの過程も楽しみたい」と思っているねこちゃんに向け、美味しいお魚が買える店の情報を提供し、自分の足で探せるマップ機能
でした。
ではここで、おさかな天国のアプリで現状できることを整理してみます。
- マップを開く
- 周辺マップからスポット（お店）を探す
- 距離 / 料理からスポットを選択する
- スポットの詳細情報みる
- スポットへのルートをみる
ここから、どんな画面なら上記の内容を実現することができそうか、ざっくばらんに考えてみます。
おさかな天国のアプリの場合、実現するためのUIはいくつか考えられると思います。
マップ画面からスポットを選択するUIや、料理のリストから選択してお店の位置を見るUI。リストタイプであれば、文字の情報が大きく、写真を大きく見せるものや、カードタイプで気になったものをストックするようなUIも良いかもしれません。
どんなUIにするべきかの検討
さまざまな案があるなかでどのUIを採⽤するかというのは、アプリ自体のコンセプト、ユーザーの利用状況、ビジネス的な優先度、技術的な実現性をから仮説を立てて決めていきます。
このアプリでのユーザーのメインミッションは「おいしいお魚を買うこと」なので、「写真を見て判断したいのではないか」「写真がいくつか並んで見えるビューがいいのでは」という仮説を立て、写真がメインとなるUIに決めました。
イメージがついてきたところで、こんな新しい課題が見えてきました。
写真で良いと思ってもそのお店が遠すぎたら嫌なので、距離感がある程度わかるようにマップも表示したいかも…
この課題を解決するために、たとえば「『徒歩3分以内』というようなソートがかけられる」、「セミモーダルビューでマップでもリストでも見られるようにする」などのアイディアを形にしてみます。
また、このタイミングでチームでの議論やユーザーテストのようなレビューを通して機能改善をしていくといった手法もあります。このUIにかかる期間や人員、技術的な難易度などコストに見合った中で最適なものに仕上げていくことが大切です。
