スマホコンテンツ市場が成長期、そして成熟期に向かうなかで、競合他社と差別化を図るための要素として、デザインの重要性が高まっているのではないだろうか？ ユーザーに心地よく使ってもらうためのデザイン、ユーザーがワクワクするようなデザインなど、スマホという独特のインタラクティブ性を持ったプラットフォームでは、今まで以上にUI、UCD、UXといった要素が大切になってきた。
そこで今回は、iPhoneアプリ「TiltShift Generator」や「SuperPopCam」など、先進的なデザインのアプリを企画、開発、設計まですべてひとりで担当し、生み出しつづける深津貴之氏から、fladdict流のUIデザインについて共有していただく。
fladdict流・使ってもらえるアプリのUIデザイン
例えば…ATMアプリを考えてみよう。
課題：iPhoneに最適化されたATMアプリを提案
全体の流れは下記の通りだろう。
・コアコンセプト
・機能の絞り込み
・バリエーション列挙
・プロトタイピング
・コアコンセプト
コアコンセプトとは、「誰が・何を・いつ・どう」が定められているもの。
今回のATMアプリを一言で言うと、「フリーランスや主婦が、わざわざ銀行にいかなくても、いつでも手軽にATMの代わりに使うことが出来るアプリ」である。このように、一行で説明できるステートメントを作ることが重要だ。
そして、それに伴ってリサーチが必要となるだろう。例えば、既存のATMの機能や既存のATMの不便はなんなのか？ またどういう時に使うのかなどだろう。
・機能の絞り込み
例として、既存のオンラインバンキングの機能を思い浮かべてみよう。そうすると、「残高確認・引き出し・振込・送金・設定変更・ 利用案内・保険・ローン・外貨預金」など、沢山でてくるが、ここはシナリオに沿って絞り込んでいくべきだろう。
シナリオとしては、下記のものが考えられる。
・通販などでの振込
・通常の送金
・支払い忘れへの緊急対応
・残高確認
・入金確認
ここで、機能の絞り込みについての考え方として、深津氏が一言。「キャンプに行くのと同じで、家のものを全部は持って行かない」（深津）
色々機能性を拡充することで、ユーザーへのベネフィットが増えると考えがちだが、そのアプリがコアコンセプトに対して明確なものであるためには、シナリオに沿って、必要な機能を絞り込んで実装すべきだという。
・バリエーション列挙
なにを入れて、なにを入れないかという選択が重要になるが、そもそもATMアプリは「90％のユーザーのニーズを満たせるもの」であればいい。本当に色々な機能が使いたいユーザーは、最初から銀行やコンビニのATMに行けばいいのだ。そう考えると、コア機能は下記に絞られる。
・残高確認
・送金
・設定変更
・ニュース
・プロトタイピング
そして、ここからは実際の形を作っていくプロトタイピングだ。あなたは、これらの4つのタイプのうち、どれを選ぶか？
①ユーティリティ型
- 天気・時計など
- 遷移が少ない
- 表に機能、裏に設定
- 単機能・単目的
②ナビゲーション型
- メール
- 階層がスタックする
- 繊維構造がツリー型
③タブ型
- App Store
-主機能が並列する
-複雑なものは、ナビゲーションと併用
-大規模なアプリ用
④没入型
- ゲーム
-オリジナルUI
-表に機能、裏に設定
-体験が重要な場合
①ユーティリティ型の場合…
・最低限の機能のみを実装
・残高履歴のみ
・送金のみ
②ナビゲーション型の場合…
・4つの機能を、それぞれ掘り進んで行く
・階層化、拡張しやすい。
③タブ型の場合…
・ナビゲーション型の上位拡張
・複数の機能を平行に移動できる
④没入型の場合…
・現実メタファーが必要な場合に
・工数、コストが跳ね上がる
今回の場合は、「ナビゲーション型」か「タブ型」ではないか？
・ナビゲーション型
- 拡張しやすい
- 単純
- メニューを掘り進む
・タブ型
- 追加項目に限界あり
- 複雑
- メニュー間を平行移動できる
ただ、ナビゲーション型には欠陥がある。残高確認を掘り進めていった際に、送金したい！となるといちいち戻らなくてはいけない。よって、今回はタブ型を採用することにしよう。これは、ペーパープロトタイピングをしたからこそ気づいた欠陥である。
「フィッシュボーン図」（特性要因図）
フィッシュボーン図は、問題と原因を俯瞰することができる。
フィッシュボーン図を書くための手順
１．問題を書く（例：ミスタップが多い）
２．小原因の対策を列挙（例：隣のボタンを押す）
３．それぞれ再帰的に分解（例：距離が近い・ボタンが小さい）
・フィッシュボーン図の利点
漠然とした問題を、複数の具体的な問題と原因に分解できることだ。一番使わないものをタブの右に置き、他は利用の流れに従って配置。よって、「ニュース→残高・履歴→送金→設定」となる。
・「残高/履歴（通帳のようなUI）」について検討
問題は、通帳ほどスペースがないこと。また、入金と出金の両方とも必要なの？ そこで「スペース不足」でのフィッシュボーン図を作成してみよう。
解決策としては、入金と出金をタブで切り替えたり、入金と出金を色分け・アイコン分けなどだろう。また日付ごとにまとめることもいいかもしれない。
・「送金」
について検討
問題は、金額でのミスが起こること。これらの問題が起こる原因は、ミスタッチや確認がないこと、桁がわかりにくいことなどだ。それぞれの問題をフィッシュボーン図で作成してみよう。
解決策としては、ミスタッチを取り消すためのアラートや送金ボタンがOKボタンに変化。またロック解除のようなスライド式ボタンや計算機方式だと桁のミスが発生するので、注意。そして、これらが終わった後に、モックアップやPhotoshopでの作成に移る。
拡張性
・初期バージョンで、ボタンを詰め込みすぎない
・将来、機能がいくつか追加されることを前提に
・機能を増やして、使いにくくなったら意味が無い
アイデア候補
・銀行に電話できるようにする
・マルチアカウント
・タブに「税、公共料金」を追加
・振込先の登録、ブックマーク機能
・振込元の検索、情報入力
PDCAサイクル
Plan（計画）→Do（実行）→Check（評価）→Action（改善）→…
「クライアントが喜ぶものではなく、ユーザーが喜ぶものを」つくろう。
まとめ
・コアコンセプトを決める
・初期に可能性をしらみつぶす
・プロトタイピングを何度も繰り返す
・実装は機械作業
はてブU-NOTEをフォローしておすすめ記事を購読しよう