スマホUI考(番外編) 顧客やユーザーの要望に全て対応すると、アプリは99%破綻する | fladdict
まだ解決編が本家で出てないのですが、最終的には意思決定の勝負になると思うので、そのアプローチの例。
命題:クソアプリのUI上の問題をどうにかしてマシにしたい
さて、問題点は次のとおりです。
- ユーザから使いにくいというレビューが書き込まれる
- 継続率が悪く、ダウンロードしてもすぐアンインストールされる
- メンテコストの増大で開発スピードが落ちる
- コードベースが膨れ上がりバグの見落としが増える
ということで、なんとなくUIもコードもスッキリさせたいというのが正解っぽい感じします。それでも、ユーザの声や偉い人の言いなりで追加していったようなチームが果たして自信満々に「機能を削りましょう」と信じて進めるでしょうか。なにか武器がほしいところです。
そこで出てくるのが外部コンサルタントです。権威ある人の言葉にみんな納得するものです。fladdictさんに発注しましょう。実作業を除くコンサルのみであれば100万円くらいから受けてくれるかもしれません(※実際の氏のコンサル料は知りません。妄想です。)
@ku_suke これで「最高のソリューションは、弊社にお仕事を頼む事です!」とかやったら、ぶっ殺されそうですねぇ
— 深津 貴之 (@fladdict) August 9, 2013
代わりに言ってあげたよ!ww
fladdictさんの仕事っていわば大改造ビフォワーアフターの匠みたいに、当初の思想と合わない状態で増改築を繰り返しどうしようもなった物件をリフォームしますよってことですよね。
データで納得させるという武器
さて、ネタは早々に置いといて、もうひとつチームを納得させるのに有効なのがデータです。レビューに出ている「使いにくい」と言ったユーザの声はざっくりしすぎているので、どのボタンが利用されているか回数を取得すればよいのです。
アプリの利用解析はいろいろありますが、迷ったら日本語で結果が見れるGoogle Analyticsが良いでしょう。アプリ用の開発キットがこちらにあります。これをつかって下図のボタンが押されたときのコードにイベントカウントコードを入れましょう。ちょっと面倒ですがコピペなので誰でもできる作業です。
こんなかんじに。そんで再提出して数日待ちます。するとだいたいこういう結果だとしましょう。
※数値は適当です。
さて、なにはともあれ結果が出ましたねー。以下の様な結果となりました。
- 更新ボタンが押されまくっている
- ついで検索、ホーム画面が多い
- フォロー、アカウント、リスト、DM、TwitterMusicは押されていない。追加メニューも微妙。
- Mention / RT / お気に入りは意外と使われているが、つぶやくは思った程ではなかった
ここからUI再編成の同意を得てすすめるのですが、その際に過去を否定するような表現を避ける事が重要です。これからやることは決して間違った道を引き返すのではなく、「フィジビリチェック期*1を終えていよいよ本質的な実装に進みます」といった前向きな言葉を使いましょう。
出来れば要らない機能はスパっと消してしまいたいのですが、消すにしても大義名分が必要です。以下の様なルールを作りつつ段階的に消し去りましょう。
- 下位50%の機能は、ファーストビューから見えなくする。その他ボタンなど下層メニューにまとめる。
- その他ボタンにまとめたあとも利用度が低いものは削除、高いものはメインメニューと入れ替えで1軍昇格
ほら、これだとUIの専門家がいなくても何とかギリギリ自力でできるでしょ。
しかし、利用が低いところは利用度を上げるべきではないのかね
おっしゃるとおりですね。ここから先はUI・UXの専門家がほしいところですが、たとえばTwitter Musicに関しては「新機能の利用を促進するために表示せよ」だったわけです。
これはつまり「ビジネスゴール」側の要件でありこれはこれで満たす必要があります。しかし利用ニーズがないものをでかでかと表示するには「ユーザーゴール」に反します。
このバランスをとってどっちも解決するのがUIデザイナーのお仕事だと思うのですが、頼れない場合もデータを見ながら、多少は調整出来ます。
- トップページの重要度>>>>利用回数なのでトップページからはできるだけ排除する。しかし訴求したいのでやや特別扱い。
- 例えば再生と停止ボタンのみのアイコンに面積縮小する、しかしTweetをタップして詳細表示になったときはフルコントロールを表示する。もっと考え用はあるけどそもそも架空の話だからマジレスはこのへんで。
このように細部は個別検討になってしまいますが、大前提として
- 見やすい位置に置くかは「ビジネス上の優先度」「ユーザの利用度」を足して上位の○割のみにする。
- それ以外はどんどんタップ数が必要な後ろに追いやって、最後には消す。
というのが、末期になった場合のリカバリプランその2じゃないでしょうかね。もちろん、ボタンのタップ回数とったくらいでデータドリブンなんて言ってんじゃないよという声も聞こえてきますが、直感でエイヤよりは進歩してるでしょ;-)
ま、可能であればお金の力でfladdictさんにまるなげして解決したいところですね。私からは以上です。
----
[PR]
っていう話を、先日書いた本にちょびっとだけ書きました、合わせてご覧いただければ幸いです。
例えば、写真アプリでのアップロード機能を検討してみましょう。写真をアップロードする機能として、下記のユーザーインターフェイスを考えてみましょう。
A.[写真]を押すと、メニューが表示され[カメラ]か[ライブラリ]を選択できる
B.[写真]を押すと、[カメラ]が立ち上がり、そこから[ライブラリ]に切り替え可能
C.[写真]を押すと、[ライブラリ]が立ち上がり、そこから[カメラ]に切り替え可能
ユーザー層の iPhoneへの習熟度や提供するサービスコンセプトで大きく違うため、一般的な正解はありません。しかし、次のようなアクセス解析のデータがあった場合はどうでしょうか。
・ [カメラ]で撮影した画像をアップした回数の集計結果:1,025 回
・ [ライブラリ]から選択した画像をアップした回数の集計結果:52,628 回
この場合、[ライブラリ]から画像を選択するユーザーが 98% にも及ぶため、(C)の[写真] ボタンで[ライブラリ]が立ち上がるユーザーインターフェイスが適していると判断できます 。
Amazon.co.jp: ヒットするiPhoneアプリの作り方・売り方・育て方: 川畑 雄補, 丸山 弘詩: 本
*1:要するにお試し期間。横文字を多用して煙にまこう。