UI/UX ここだけの話 大放出 - スマホデザイン忘年会議 #sdkaigi [seminar]

第5回目を迎えた，スマホデザイン会議に参加してきました．今回は，「UI/UX ここだけの話 大放出」というテーマです．

スマホデザイン忘年会議2012 on everevo

そこで今回は、年末ということもあり「スマホデザイン忘年会議」と題して、今まで皆様より質問の多かった下記のような疑問について、ここだけでしかできない、施策・失敗例・成功例・数字などの実例を交えながらトコトン掘り下げていきます！

KPIってどの数字を取ってるの？
UIってどう設計して、どう改善してるの？
UXの評価ってどうするの？デザインvs機能 どっちが大切？
どうしたらワクワクするデザインにできるの？
ユーザーの声はどういった基準でデザインに反映するの？
UCDの実施は具体的にどうするの？
PCとの違いって？スマホだからできることって？

以下，メモです．

---

【fladdict 流の UI デザイン】
by Art & Mobile 深津貴之氏 (@fladdict)
発表資料

iPhoneアプリ設計の極意 の巻末付録に寄稿した，「fladdict 流の UI デザイン」の内容をブレイクダウンして説明．

- コアコンセプトを最初に決める
　- 誰が
　- 何を
　- いつ
　- どう

- 複雑な機能を全てスマホに盛り込むことはできない
　- 何を取って何を捨てるか，が重要
　- 90%のユーザーが必要なことを考える
　→ コア機能を抽出する

- 4つの UI パターンから選ぶ
　- ユーティリティ型
　- ナビゲーション型
　- タブ型
　- 没入型
　→ ペーパープロトで全パターン試して，問題を予見する
　→ 最初に間違えると，その後ブラッシュアップしても使いやすくならない

- ここまでは広く浅く，パターンが決まったら狭く深く
　- 問題と原因を網羅するには，フィッシュボーン図を使う
　- 曖昧な問題を，複数の具体的な問題に分割する

- プロトを繰り返し，フィッシュボーンで洗練させてから，ビジュアルデザイン

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

- PDCA サイクル
　- Plan
　- Do
　- Check
　- Action
　→ これをきちんと回さないと，誰も使わない，あるいはクライアントしか喜ばないアプリになる

- まとめ
　- 常に立ち返る所 (コアコンセプト) を最初に決める
　- 初期に可能性をしらみ潰す
　- プロトタイピングを何度も繰り返す
　- ここまでやれば，実装は機械作業

所感:
数々のヒットアプリを手掛ける fladdict さんだけあって，説得力があり，内容も具体的．とにかく，この一言に尽きます．

これは1万回ぐらい繰り返し言いたい RT @toshiya: 機能を増やして，使いにくくなったら意味がない #sdkaigi

— Toshiya HASEGAWA (@toshiya) December 21, 2012

【これからの Lean UX の話をしよう】
by 利用品質ラボ 樽本徹也氏　　
発表資料

- もしせっかく作った製品が売れなかったら?
　- 「企画や営業，開発などを強化しなければ」という流れになる
　- 組織がどんどん太っていく
　→ そこで Lean (贅肉・無駄がない)

- 製品開発における最大の「無駄」とは?
　- 誰も使わないものを作ること

- 良い製品は良いアイデアから生まれる?
　- アイデアは仮説に過ぎない
　- 検証していない仮説は単なる「思い込み」に過ぎない

- 検証のプロセス
　- 課題検証
　- ソリューション検証
　- 製品検証
　- 市場検証

- Problem Interview
　- Early adapter の把握
　- Must-have problem の把握
　- 既存代替策・既存製品の把握

- Solution Interview
　- MVP (Minimum Viable Product) の要件定義
　- ユーザーは MVP をいくらで買ってくれるか，という価格
　- 持続可能なビジネスモデル

- 「設計・開発」は，ここからの作業
→ 以上のことは，企画レベルで終えてなければならない

- MVP Interview
→ ユーザーテスト

- メトリクス
　- 総ユーザー数
　- アクティベート数
　- 再利用ユーザー数
　- 有料会員ユーザー数
　- バイラルしてくれたユーザー数

- 会議室で議論しててもダメ，実際のユーザーに触れよ

所感:
アプリ開発に対する「心構え」みたいなものが聞けました．経営陣にも聞かせたい内容．

特にこの一言は心に響きました．

「商売をするんですから，私達は．売れないといけない!」 #sdkaigi

— Toshiya HASEGAWA (@toshiya) December 21, 2012

【Android における UI/UX】
by AKQA 佐藤伸哉氏
発表資料

- UI パターンを知り，Android らしい UI を作る

- Android Design で定義された，アプリの階層構造
　- Top level views
　- Category views
　- Detail/edit view
　→ 極力シンプルに，深い構造を作らない

- 階層構造のより分かり易い考え方
　- 第1階層 (Action Bar = トップレベルの選択階層)
　- 第2階層 (Tab など，カテゴリレベルの選択 = 選択された情報の階層)
　- コンテンツ

- 具体的に実装した例
　- Google Maps, Gmail
　→ 一番参考にすると良いアプリ

- 階層構造を使い易くするコツは Action Bar

- トップレベルの定番パターン
　- Tab Nav. (Scrollable Tab)
　- Pull-down Nav. (Spinners)
　- Drawer Nav. (Drawer)

- コンテンツレベル，情報の表示の定番パターン
　- Visual View
　- Content View
　- Content detail View
　- Thumb-Nail List View
　- Simple List View
　- Split View

- コンテンツレベル，情報のアクションの定番パターン
　- Bottom Action
　- Pull-down Action

- コンテンツレベル，情報の編集の定番パターン
　- Edit First
　- Edit Last

- 以上13パターンを組み合わせて作るのが Android アプリの基本

所感:
基本的な内容に終始したのが残念ですね．佐藤氏にしかできない話をしてほしかった．


【トークセッション】
by TechWave 副編集長 増田真樹氏 x ゲストスピーカー3名

(増田)
ステートメントのまとめ方は?
使われるものを見出し，市場に受け入れられる企画に落とす際に必要な，情報やプロセスは?

(深津)
Amazon は最初にプレスリリースから書き，それが魅力的だと思えたら開発に着手するのだとか．それはアプリ開発にも使える．自分の場合は，100字以内にまとめる．100字にまとまらないなら，要件がまだ曖昧なのでアプリを作る段階ではないと考えている．

(佐藤)
他との差別要因を明確にする．競合と何が違うのか，ユーザーにどんなメリットがあるのか，を考える．「最終的にこれは何なの?」というのを，最初に考える．

(樽本)
逆に，ステートメントを定義しないで，どうやって作るの?

アイデアは，自分やユーザーをよく観察して，なにを不便に感じているかを捉えるところから出てくる (ジョブズみたいに「降りてくる」人もいるだろうけどｗ)．ユーザー調査やグループインタビューからは，アイデアは出てこない．実際にユーザーを見ないとダメ．

(増田)
ステートメントがまとまったとして，それの交渉の仕方は? クライアントの落とし方，妥協の仕方．

(深津)
僕のやり方はかなりイレギュラーですけど…

初回に，全画面遷移を書いて見せてしまう．その時点で企画書は無力化し，自分が主導権を取れる．それで最後にはこっそり画面遷移が変わってるｗ

(佐藤)
企画が通せないということは，相手が理解できていないということ．イコール，自分も分かっていないのでは? 努力が足りないだけだと思う．

(樽本)
「チームをまとめる一番良い方法は」と質問を置きかえて答えると，全員ユーザーに会わせること．エンジニアもデザイナーもマネージャーも．

(増田)
ユーザーテストはどのようにやっている?

(深津)
僕は1人でやっているので…予算やリソースがある時はちゃんとやるけど，そうじゃない時は以下の2つの方法．

バーで酒を飲みながら自分のアプリを最後まで説明できるか．自分のオカンが使えるか．

(樽本)
会社内だったら，開発部門以外の人間にちょっと使ってもらう，ぐらいでもかなりのことが分かるはず．

カメラでテスターを撮影するような，ちゃんとしたテストをする時は，必ずテスターの指を撮ること．指は口ほどにモノを言う．

(増田)
機能の削り方，改善の仕方は?

(深津)
機能の向上と利便性は比例しない．それをいかに自分で肌感覚で持ち，相手に肌感覚として持ってもらうか．自分で作っているアプリなら，1週間使わない機能は削っていく．クライアントがいる場合は，プレゼン芸などで無理矢理納得してもらう．「iPhone も最初はコピペがなかった」と言ったり「100徳ナイフ」の画像を見せたり．

意思決定もコスト．選択肢が多いということは，それだけコストがかかる．それを意識しないといけない．

(増田)
素敵なスマホ UI デザインについては，どう考える?

(佐藤)
HTML5 か Native か，で言えば，Native．
Native じゃないとハードウェアが持っている性能を発揮できない．

(深津)
素敵な UI とは，使っている時に，状況とか世界とかを，自分がコントロールしている感覚があるもの．因果関係がしっかりしているというか．

押したいところにボタンがある，消したい時に消せる，みたいな．

(樽本)
まずアプリは役に立たないとダメ．実用性ではなく，その人を喜ばせる，という意味で．

(会場)
アプリのアクセス解析ツールについてはどう考えているか?

(佐藤)
必要ないと思う．

(深津)
アプリに埋め込んだことはあるが，ユーザーの顔を見なくなってしまう．10万ダウンロード以下のアプリには必要ないと思う．

(樽本)
監視するのもいいが，数字が悪化したした時に行動が取れるようにしておく (実ユーザーにアクセスできるとか) の方が大切．

(会場)
お3方が，自分のアプリ以外で，一番好きなアプリは?

(深津)
Paper．
似たようなアプリを作っていたが，Paper で満足して開発をやめてしまった．

(佐藤)
Gmail と Simeji．

(樽本)
MUJI NOTE とか iBooks とか．

---

発表者，及びスタッフの皆さん，素晴らしいセッションをありがとうございました．