はじめに:
ウェブやアプリケーション設計において、GUIというのは切っても切りはなせない存在です。
しかし、本来のユーザー視点に立った際に、GUIが正解でないと言う事もあります。
雑誌のアプリケーションにおいてあった話です。
アプリを設計する際により雑誌に近づける為に、ページをめくるといった動きを追加しました。
ページをめくると、めくられているページがたわんで表示される様な形になっているものです。
アプリをリリース直前に出版社はアンケートをとりました。
出版社は、このページのたわみのリアルっぽさが評価されると予測しました。
しかし、ユーザーからはその点に対して何も触れられていません。
むしろユーザーが求めているのは、ページをめくるという動作性よりも電子版であるが故の利便性でした。
アンケートの要望には、
・自動ページおくりが欲しい
・ページをめくるエフェクトがいらいない
・もっとサクサク動いて欲しい
・携帯だと画像が小さいので、拡大機能が欲しい
と言った事が書かれていました。
上記の要望は、ページをめくる為のエフェクトでかかった工数を当てれば十二分に対応できる要望でした。
しかし、今から再作成していたら間に合わない・・・。
結果アプリのリリースは延期されました。
(しかも、正式版ではページのエフェクト機能はデフォルトOFFとなっていました。)
さて、これらの例から本来行うべきだった対応に関して考えてみましょう。
1:既定路線は必ずしも正解ではない
雑誌社の要件定義において、雑誌と同じ様な体験をという文言が入っていたのかは不明ですが、現在あるものをそのまま再現すると言う路線は必ずしも正解に繋がりません。
今回のページをめくると言う動作は、アナログな紙をめくる為に必要な動作ではありました。
しかし、デジタルにおいては必ずしも必須の機能ではなかった訳です。
ユーザーがアプリケーションを使った結果何を得るのかに対して主眼を置いて検討をするべきだったと言えます。
そうした時に必要なのは、ワイヤーフレームと同時にユーザーの利用シナリオの作成です。
スタート地点を、アプリを知るとして
ゴール地点は、雑誌内の情報を得る
これらの中でシンプルにユーザーの動作遷移をシナリオとして作る。
そうすると機能が実はプロセスの追加となり足枷となっているのに気がつくのではないでしょうか?
2:無意識に大するの壁の大きさ
①ページの右端を指でこする。
②端をつかみページの反対側にもってくる。
③指をはなしページがしっかりと次に移った事を確認する。
④目線を右上に移す。
上記の様な動作を意識していますか?
雑誌におけるページをめくるという動作は無意識に実施されます。
これは、雑誌に限らず本やノート等を無数にめくっていき訓練されて来た結果と言えます。
対して、アプリケーションでのページをめくるという動作、フリック動作。
アプリケーションごとに微妙に動きややり方が異なります。
自分のアプリが無意識に本当にできるのかどうか再度検討してみてはいかがでしょうか?
3:ユーザーヒアリングを先にしなかった
グロースハック以前の問題として、ユーザーヒアリングが悪いといった状況は良く発生します。
今回のページめくりの問題に関しても、機能を作り込む前にユーザーに機能をヒアリングする事はできたはずです。
雑誌アプリに関しては、ほかにも多数出ているため、それらを例にとればわざわざプレゼンテーションシートや動画化を行わなくてもヒアリングする事はできると言えます。
もちろん、ユーザーヒアリングばかりしてしまっていてはいつまでたっても制作には繋がりません。
しかし、いらない機能を追加して手戻りをするリスクに比べれば、ユーザーに対して調査をおこなったりヒアリングやアンケートを行う事はコストじゃないのではなでしょうか?
まとめ:
今回の雑誌アプリ設計においては、
幸いだったのがリリース前にアンケートを取りユーザーの声を集めたという点です。
これを実施していなければ、リアルの雑誌をトレースしただけの使えないアプリケーションがストアに並ぶところでした。
1:規定路線通りでいいのかどうか
2:無意識に利用できるか
3:ユーザーヒアリングの徹底が行えているかどうか?
これらを行って、初めてUIの設計に入れるといえるのではないでしょうか。
是非ともリリースやアップデートの際にご参考頂けたらと思います。