「Google Developers LaunchPad Build Tokyo 2016」に参加してきたので、議事録を残す。
https://developers-jp.googleblog.com/2016/09/google-developers-launchpad-build.html
-
はじめに
-
現実空間にある面をz軸で表す
-
100万アプリがマテリアルデザインのフレームワークを使っている
-
-
アプリデザインで守るべき25のルール ミドリカワタツオ
-
アプリの広告周りの仕事をしている
-
インストールのきっかけ
-
レーティングが大きい
-
-
25%のアプリしか使われていない
-
34%のアプリしか12回以上使われない
-
アンインストールの理由
-
不要。よくなかった。使わないアプリだった。
-
期待するほど便利ではなかったが一番多い
-
インストールしてみないと使い心地はわからない
-
-
36アプリくらいがスマホに入っている
-
インストール、アンインストールを繰り返している
-
アンインストールされないようにするのが大事
-
-
高評価のアプリほど高収益
-
目標Cコンバージョ単価 x 予測CTR x 予測CVR
-
CTR、CVR
-
評判やレーティング
-
-
-
Answer Lab x Google
-
ニューヨーク、シカゴ、サンフランシスコで調査
-
やってみた
-
日本主要ECアプリ6つ
-
-
-
App Navigation and Exploration 迷子にならない！
-
自分たちがユーザにとってほしいものではなく、ユーザが何をしたいかを見せる
-
アプリで何ができるのかを最初に見せるのが大事
-
アプリを立ち上げて5分以内にわからせないとダメ
-
-
カテゴリが何を指しているかをMECEにする
-
適切な戻り方を。ブラウザのようにステップごとに戻れるようにする。
-
アプリとwebの横断
-
決済はwebでー、アプリからwebが立ち上がる
-
ユーザはストレス。見た目が異なるケースもイライラする。
-
trakingとかでもオススメしない。
-
アプリはアプリで完結させたい
-
-
どうしてもwebに飛ばす場合。
-
chrome custom tab。自然にwebを開ける。早いし。
-
-
アプリ内検索 In-App
-
検索機能は目立つところに
-
androidユーザはホーム画面の一番上に検索フォーむがある。だからアプリでも一番上に置く。
-
アプリ内での情報収集がすぐできるように
-
何かをしたいと思う瞬間は検索したいと思う
-
-
-
検索 In-App-Search 優しい
-
googleと同じように検索の使い心地を良くする
-
スペルミスの修正、予測変換、サジェスト、
-
filterやsortをできるようにする
-
ショッピングなら在庫情報とかあるといいね
-
-
コマース イライラしない
-
支払い方法の管理を簡単に
-
ステップの途中でも支払い方法の変更ができるようにする
-
クレカのスキャニング
-
いろいろなユーザがいるのでスキャニングの方法もしっかり伝えないと、違う方法でスキャンしようと試みるユーザもいる
-
カメラで撮らず、携帯に置いた人もいる
-
-
ここのステップを軽減することに重きをおくこと
-
-
登録とフォーム 引かれないように
-
いきなり会員登録、連携。ブランド力が高いサービスならまあ許容できるが、新サービスでやると信頼性が薄れる。
-
必要な時だけ情報を取ること。コンバージョンの直前とか。納得感がある時だけにする。
-
最初から会員登録してくれればいろいろデータも見れていいってのはわかるけどね。
-
sign upより、registerが最近の主流。英語。
-
パスワード認証
-
すぐ忘れちゃう。CSに電話、いろいろたらい回し、再発行に1週間かかっちゃたとかね。
-
-
カーソルの移動は最小限、キーボードでかすぎ
-
リアルタイムでバリデーション
-
クレカ番号なのに、英数字のキーボード、日本語入力とかうざい。テンキーにしようね
-
結構大手のECでもここのミスは多い
-
-
入力がしやすい表示
-
日付ならカレンダー。打たせることはしてはいけない
-
-
-
ユーザビリティ 納得感
-
アイコンだけで完結させずにはテキストをつけてあげましょう。こっちのが確実。
-
アイコンによっては全ての人が同じ解釈をするとは限らない
-
大事なアクションをした時（申し込み、購入など）しっかりとユーザにフィードバックしてあげる。undoとかしてあげるとなお良い。
-
アクセス許可を色々要求するけど、その理由や価値を明確に伝えること。なんでそんな情報とるの？となり拒否される。さらに必要な時に伝える。
-
-
-
マテリアルデザイン
-
ライブラリを使ってください
-
Drag surface
-
scrollcontent
-
fling
-
-
アイコンアニメーションボタン
-
フォロー、アンフォローの変更
-
vectorコードを変更する
-
-
-
-
マテリアルデザイン課長事例
-
Famm
-
なぜリニューアルをしたのか。きっかけは。
-
デザイン先行ではなく、作り直すって話題があった。なのでその時期に発表されたマテリアルデザインを取り入れた。
-
ユーザインタビューを実施して、マテリアルデザインに改良していった。本当にこれでいいのかってのもあったので。
-
作っていく過程で見直す箇所はまだまだたくさん・・・
-
アプリの構造を見直すために、sletch画像を全印刷して確認した
-
あえて印刷した理由は？
-
サイズが半端なく重くなったから
-
-
サイトマップの再構成
-
進捗管理も含んで、ここ足りてないとかの判断材料にも使っていた
-
エンジニア、デザイナー、ディレクター全員で確認に使った
-
-
-
導入してどうだったのか
-
SupportLibraryを使った部分
-
ここにあるものは全部ここ
-
-
他のLibraryを使ったもの
-
フローティングアクションボタン。サブメニューを出したかった。
-
-
自作した部分
-
Design Suport Libraryに対して
-
標準的なものは楽。でも柔軟性はないので、差別化は難しい。
-
TextInputLayoutのエラー機能とテキストカウント機能だけ使いたいって思ってた。
-
-
なるべく標準のアイコンを利用
-
-
なんかマテリアルデザインの資料の不満をつらつらと
-
探しづらい
-
タブレット用が参考にならない
-
-
リニューアル後の数値
-
インストール数、レビュー評価が上がった。
-
デザイナーには数値は最後に報告される感じだった。上がらなかったらどうしようって感じだった。
-
googleplayの段階的リリースを使った
-
ABテスト？ユーザヒアリング？
-
リニューアル前後はインタビュー中心
-
リニューアル後はABテストを主にやってる
-
-
-
QA
-
android2.3を選んだ時に痛い目見た。4.3を選んでいる理由は？
-
ユーザ数が少なかったのでapiレベル15にしている
-
-
iOSはどうする予定？工夫とかは？
-
iOSはそっちのガイドラインで作っている。でもUIの差が出るので機能の差が出るので悩んでいる。
-
インタビューや数値を見ながらやるって感じ・・・
-
OSごとの工夫は？
-
別々に作る。しかない。細かい見せ方はプラットフォームを利用する。構成は同じにして統一していく。
-
見た目はプラットフォームに沿うのがいい？
-
ボトムナビゲーションにしようかな〜って話はよく聞くよね。最近androidのガイドラインにもやっと出てきたやっとwww
-
A：タブ、ボトムナビゲーション、ナビゲーションドロワー、どれなの？どれが優先順位が高いの？ってとこが大事
-
ボトムナビゲーションはどのページでも残るものだよ
-
-
-
-
-
タブレット対応は、最後に始めた？しにくい場合に画面構成を変えた？
-
初めからタブレット対応がある前提で作っている
-
-
-
-
Material Design Fireside Chat
-
「C」C CHANNEL 斎藤さん
-
原宿にあるLINEの森川さんが作った会社
-
縦型のこだわり
-
スマホは基本たて画面なのでたての動画にした
-
-
-
「F」FRIL 山口
-
「M」マネーフォワード 黒田
-
BtoC、CtoCのサービスもいろいろあるが全体的にマテリアルデザインに統一した
-
-
ビジネスとデザイン
-
C
-
タブレットユーザが多くマテリアルデザイン採用がやりやすかった
-
-
F
-
デザインをよくして使い勝手をよくしていくことが収益につながっている。なので、ビジネスとデザインが戦わなくて大丈夫。
-
デザイナーもちゃんと数値を見ているので共存できている
-
売上、出品などチームごとに数値を持っている
-
-
M
-
工数が難しいところ。複雑なアニメーション。デザインはユーザビリティをあげることなので、どう言ったKPI貢献があるのかを伝えるしかない（どうやって・・）
-
-
-
社内でマテリアルデザインを導入したきっかけ
-
C
-
みんな関心があった。googleから指摘が入って（お願い）より意識するようになった。
-
今ではガチガチマテリアルデザイン
-
-
F
-
androidは後出しな雰囲気があった。マテリアルデザインが発足された時に、考え直し、取り入れた。スムーズだった
-
-
M
-
IOで発表されて数ヶ月後って。今まではエンジニアがデザインしていて、ぐちゃぐちゃしていた。
-
iOSはグッドパッチさんにサポートしてもらった
-
マテリアルデザインのガイドラインを読んでいいものだと感じた
-
これからどんどん変わっていくはずなので、乗らない手はないだろうと
-
-
-
iOSとの整合性は？
-
C
-
構成は同じ、プラットフォームは分ける
-
工数が足りなければどっちかは外注にしている
-
-
F
-
OSごとにチームが分かれていた。なので別れたUIになっている
-
今は同じデザイナーが見たりしている。あとwebもやっている。使うきっかけが違い、プラットフォームによってUIが違うのは仕方ないのではないかと思っている。
-
-
M
-
全然UIを変えて作っている。いろんなアプリの中の１つのアプリなので、そこで全然違う体験をさせるのではなく、OSの動きにあったものにする。
-
-
-
ガイドラインに沿ってうまくいったこと、正直違うって思ったこと、その理由
-
C
-
ボトムナビゲーション。女性向けサービスは画面の右下が大事。女性は手が小さいので、右下にコントロールがないと使いづらくなってしまう。
-
ガイドラインには沿わないがやっていた。
-
-
F
-
ガイドラインで骨組み。文字のガイドラインが英語用しかなかったので変えた。
-
ボトムナビゲーションがもともとあった。マテリアルデザインでは許されてなかった。でもそれだと使いづらいと感じ、ユーザインタビューでも困っていたのでガイドラインよりもユーザを信じた。
-
-
M
-
全部守れているわけではないw
-
エンジニアが実装するとキーラインが曖昧になる
-
アニメーションコストがーってのも。なのでそこは実装していないとか。
-
-
-
社内で啓蒙する仕方
-
C
-
啓蒙してないw
-
普段から仕様や設計段階で話題が出てきて、そこでみんなが覚えていく。
-
-
F
-
啓蒙してないw
-
Androidアプリに精通してるエンジニアさんがいて、結構そっちの人のが詳しかったした。啓蒙いらづ。
-
-
M
-
うちもやってないw
-
googleが頑張ってるので。個人個人が意識して情報を取りに行っている。エンジニアもデザイナーも。
-
-
-
マテリアルデザイン正直どうですか？
-
C
-
Androidって昔はバグとか許される、iOSを移植するってイメージだった。
-
世界的にはAndroidが多く、グローバルなので、もっと頑張ってgoogleさん
-
-
F
-
ガイドラインがコロコロ変わってて大変だった。
-
でもガイドラインがきっちりあるのですごく楽。自分たちでそれを全部準備するのって大変。
-
-
M
-
ガイドラインしっかりしている。さらにsuportlibraryもあり、簡単に適応できる環境を用意してくれている。なので余計なコミュニケーションコストが減った。
-
アニメーションもっと簡単に作れるとうれしいなー
-
-
-
社内でやるためのアドバイス
-
C
-
他の方と同意見。デフォルトの物でまかなえるのはいい。デフォルトなので話を通しやすい。
-
日本のアプリは情報が整理されていない。情報整理の切り口で説得できるかなと。
-
-
F
-
数値より、メンテコスト。MFの方と同じ。
-
-
M
-
デザイン導入したからKPIが達成できるとかって、信頼性が低い。ってよりもメンテコストが下がるとかその後のことが説得材料
-
-
-
QA
-
ありふれたデザインにならないか
-
C
-
サービスがちょっと特別なのでちょっと違うかなー
-
-
F
-
以前は女性専用アプリだった。今はオール。コンテンツが大事で、UIを主張しすぎないようにしている。
-
-
M
-
似てくるってのはしょうがないかなと思っている。
-
androidの世界で違う世界を作るのはユーザは戸惑う。
-
差別化は見た目だけではない、ユーザの体験で価値を出せればいいのではないかなと思っている。
-
-
-
デザインがパターン化し、デザイン工数もへる？それによってXMLいじってくれる？
-
C
-
もともと初めから導入してたので・・・
-
-
F
-
導入にあたってデザイナーがXMLをいじってやってった。このXMLを使ってくださいーって感じ。工数削減できた
-
-
M
-
今まで実際に絵を描いてパーツ切り出して〜ってのがなくなった。デザインの指示ってより目的を共有するだけで、エンジニアがモックを作っても平気になった。
-
マテリアルデザインを介して、みんな興味を持ってくれた。エンジニアもデザイナーも勉強してくれている。
-
-
-
-
-
-
transition
-
何が変わったのか
-