第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 とか．
発表者，及びスタッフの皆さん，素晴らしいセッションをありがとうございました．
0 件のコメント:
コメントを投稿