「使ってもらえるアプリの考え方」スマホデザイン会議 2012...

使ってもらえるアプリの考え方深津貴之

12年12月25日火曜日

自己紹介


• 深津貴之

• Art & Mobile

• Flash / iPhone


ToyCamera QuadCamera TiltShiGen


iPhoneアプリ設計の極意思わずタップしたくなるアプリのデザイン

監訳


モバイルデザインパターンユーザーインターフェースのためのパターン集

監訳


artandmobile.com

twitter.com/fladdict


ATMアプリを考えてみる


いままでのまとめとして、ATMアプリを作るとすればどうするか？


簡単な架空事例を考えてみる


課題

iPhoneに最適化されたATMアプリを提案する


全体の流れコアコンセプト

機能の絞り込み

バリエーション列挙

プロトタイピング


コアコンセプト



誰が？いつ何をどう


コアコンセプト誰が？

いつ

何を

どう

フリーランス、個人事業主、主婦

銀行での支払い振込を

空いた時間に

わざわざ外出せずにできる



1行で説明できる、ステートメントを作る

フリーランスや主婦が、わざわざ銀行にいかなくても、いつでも手軽にATMのかわりに使える。


•既存のATMの機能は？•既存のATMの不便は？•どういうときに使う？

リサーチ


機能の絞り込み


•残高確認•引き出し•入金•送金•設定変更•利用案内

既存のATMの機能



既存のオンラインバンキングの機能

•ニュース•外貨預金•口座開設•ローン•保険•税、各種料金の支払い


•通販などでの振込•通常の送金•支払い忘れへの緊急対応•残高確認•入金確認

シナリオ


何を入れて、何を入れないか？


全ての機能は必要ない複雑なことは銀行かコンビニでやればいい


90%のユーザーが必要な機能だけを入れる



機能

•ニュース•外貨預金•口座開設•ローン•保険•税、各種料金の支払い


•簡単に残高を確認•簡単に送金できる•複雑なことは銀行かコンビニで

コア機能


4つのタイプのどれを選ぶか？


ユーティリティ型ナビゲーション型タブ型没入型


ユーティリティ型

• 天気、時計等• 遷移が少ない• 表に機能、裏に設定• 単機能、単目的


ナビゲーション型

• メール• 階層がスタックする• 遷移構造がツリー状


タブ型

• App Store• 主機能が並列する• 複雑なものは、ナビゲーションと併用

• 大規模なアプリ用


没入型

• ゲーム• オリジナルUI• 表に機能、裏に設定• 体験が重要な場合


ユーティリティ型の場合


•最低限の機能のみを実装•残高履歴のみ•送金のみ



ナビゲーション型の場合


• 4つの機能を、それぞれ掘り進んで行く•階層化、拡張しやすい。



タブ型の場合


•ナビゲーション型の上位拡張•複数の機能を平行に移動できる

タブ型


タブ型


没入型の場合


没入型 ATM メタファー


没入型エージェントメタファー


•現実メタファーが必要な場合に•工数、コストが跳ね上がる

没入型


ナビゲーション型 or タブ型


ナビゲーション vs タブ


ナビゲーション vs タブ

• 拡張しやすい

• 単純

• メニューをまっすぐ掘り進む

• 追加できる項目に限界

• 複雑

• メニュー間を平行移動できる

ナビゲーションタブ


今回のケースでは、ナビゲーション型だと問題が


機能を切り替えるときに、階層の深さが問題に！


検証ケース


検証ケース

•送金を中止し、残高やニュースを見る場合•ニュースから送金に移動する場合


階層が深い場合、作業を切り替えるのに何度も階層を戻る必要がある


今回はタブ型を採用


フィッシュボーン図特性要因図


問題と原因を網羅するツール


使いにくい

機能が多すぎる

フィッシュボーン図

画面が多すぎる

説明がない視認性が悪い

チュートリアル

メタファー

機能を減らす

低頻度の機能を隠蔽

Tabの導入

機能を減らす

工数が足りない

デザイナ追加

顧客要件が多すぎる

説得プレゼン

グルーピング

ルールがない

カラールールを決める

フォントを統一

階層が深い


ミスタップが多い

問題を書く



小原因の対策を列挙

隣りのボタンを押すボタンに見えない

機能がわからない押したかわからない






色が地味

フラットだから

距離が近い

ボタンが小さすぎる

反映に時間がかかる

Noフィードバック

文字のないボタン

アイコンが普遍的でない






色が地味

フラットだから

距離が近い

ボタンが小さすぎる

反映に時間がかかる

Noフィードバック

文字のないボタン

アイコンが普遍的でない

ボタンを44px以上に

ボタンの数を減らす

間隔を広げる

レイアウトを再考コントラストをあげる

ボタン専用色を作る

立体にする

物理メタファー

アニメーションで誤摩化す

レスポンスだけ先に返す

押せないボタンをグレーアウト

押した画像を作る

iOSの標準アイコンを使う

自作せずに購入する

ラベルをつける

ボタンの数を減らす


フィッシュボーンの利点

あいまいな問題

問題問題

問題問題

漠然とした問題を、複数の具体的な問題と対策に分割


メニューの優先順位を定める


重要なもの、よく使うもの等から左から右に配置する


•ニュース•残高／履歴•送金•設定

メニュー順の候補

•送金•残高／履歴•ニュース•設定

•残高／履歴•送金•ニュース•設定


可能であれば、調査に従って定める


•ニュース•残高／履歴•送金•設定

メニュー順の候補


一番使わないものを右に置き、残りは行動の流れを考えて配置。


残高


残高表示


通帳ほど横にスペースがない


入金と出金はあわせていいのか？


通帳と完全に同じUIにする必要はない


入金と出金を色分け


日付ごとにサブヘッダを入れる


スペースが足りない

デバイスの限界

スペース不足へのフィッシュボーン図

通帳ににせすぎ

要素が多すぎる

横モードを採用する

アイコンや色を導入

セグメンテッドを導入

サブ階層を導入

通帳メタファーをやめる内容を削る

日付をテーブルヘッダーに

クライアントを説得

残高を隠す

文字を小さく


残高表示


送金


金額入力のミスをなくす


入力ミスが起こる

桁がわかりずらい

入力ミスのフィッシュボーン分析

確認がない

ミスタッチ

ボタンを大きく

ピッカーを採用

桁を色分け

「万」や「千」という時を出す。

1タップ毎に音をいれる

0.05秒ほどタッチ無効時間をいれる

確認画面

音声よみあげ？

50万以上の場合警告


金額入力のミスをなくす


計算機方式だと、桁のミスが発生する


送金


「送金」ボタンのミスタッチを無くす


送金

送金ボタンがOKボタンに変化スライドアラート


誤送金

確認ミス

誤送金のフィッシュボーン図

確認を連打

ミスタッチわかりずらい

確認画面を挟む

ボタンを2回タップさせる

背景色などを大きく変える

重要でないものを目立たなく

ボタンや遷移にタップ無効時間を設ける

ガイドヘルプを入れる

不要な要素を減らす

要素を大きくアラートを出す

確認機能をシンプルに

音をいれる

スライド式？

チェックリスト式


パスロックを入れる


パスロック


拡張性


•初期バージョンで、ボタンを詰め込みすぎない•将来、機能がいくつか追加されることを前提に•機能を増やして、使いにくくなったら意味が無い

拡張性


•銀行に電話できるようにする•マルチアカウント•タブに「税、公共料金」を追加•振込先の登録、ブックマーク機能•振込元の検索、情報入力

アイデア候補


PDCAサイクル


PDCAサイクルPlan (計画)

Do (実行)

Check (評価)

Action (改善)


まとめ


コアコンセプトを決める


初期に可能性をしらみつぶす


プロトタイピングを何度も繰り返す


実装は機械作業


質問


[email protected]

twitter.com/fladdict

質問、お仕事のご相談などはお気軽に


mailto:[email protected]

mailto:[email protected]

「使ってもらえるアプリの考え方」スマホデザイン会議 2012...

Design