エンジニアが武器にするMaterial Design

2017/3/10
DroidKaigi 2017 DAY02 room3 16:00~

Transcript

1. エンジニアが武器にする Material Design DroidKaigi 2017 株式会社ノハナ 瀬戸優之 @seto_hi
2. 自己紹介 • 瀬戸優之 せとひろゆき @seto_hi • Android開発歴 6年半くらい • コンシューマー向けAndroidアプリ開発一筋 5年 • 株式会社ノハナ ◦ 唯一のAndroidエンジニア ◦ 絶賛採用中 • 好きなAPIはCanvas#saveとViewGroup#layout
3. なぜエンジニアがデザイン? • 大学の研究分野がHCI ◦ コンピュータを使いやすくするUI研究 • 前職ではUIデザインも担当 ◦ デザイナーはアイコン作るだけ • 現職では新卒デザイナーとチーム ◦ Androidアプリデザイナーとして教育
4. 僕とMaterial Design 2014/06 　I/Oで発表されて知る 2015/11 　アプリの主担当になる 2015/12 　 「今のデザイン全部捨てようぜ！」 2015年末 　 ガイドラインを読み始める 　年末年始休暇でひたすら読み込む 2016/01 　社内Material Design勉強会 2016/01/26　新規登録画面をMaterial Design化してリリース 　1年かけて全画面フルリニューアル 2017/1/17 　全画面のMaterial Design化完了
5. ノハナノハナシ [検索]
6. デザインエンジニア推進派 • 「デザインはデザイナーに任せるには重要すぎる」 ◦ アプリデザイン ≠ Webデザイン、グラフィックデザイン ◦ アプリデザイン=UIデザイン＋ユーザー体験のデザイン ▪ 必要な知識が多い • アプリエンジニアもユーザー体験に責任を持つべき ◦ 理解していないデザインを実装してない？
7. 今日言いたいこと • エンジニアがアプリデザインに関わると捗る ◦ 工数削減、アプリの質の向上、体験の改善 • アプリデザインの勉強としてMateiral Designは良い ◦ 知識と実装が繋がると武器になる • エンジニアから社内にMateiral Designを広めよう ◦ 社内勉強会をやろう • ガイドライン通りでは他社に勝てない ◦ 深読みしてMateiral Design力をつけよう
8. 目次 • エンジニアとアプリデザイン • Mateiral Designを武器にする • ノハナ社でのMaterial Design導入方法紹介 • 深読みガイドライン
9. エンジニア と アプリデザイン
10. エンジニアがアプリデザイン関わる利点 • デザイナー負荷削減 ◦ 巻き戻りの幅が小さくなる ◦ デザイナーがAndroidにとっつきやすくなる • 開発の時短 ◦ デザイン待ち時間削減 • アプリの質の向上 ◦ 巻き戻りしやすい ◦ 多視点で判断できる
11. エンジニアがアプリデザイン関わる欠点 • エンジニアに負荷がかかる ◦ コーディングにフルコミットできない • デザイナーはデザインチームとエンジニアの板挟み(かも) • 論理的な反論に慣れていないデザイナーはつらい(かも) • 理論的に正しいが微妙なUIができる可能性 ◦ 時には直感を信じることも必要 • 一部デザイナーから反発がある
12. アプリデザインとどう関わるか • やりすぎない ◦ 協力してお互いをカバーする • デザイン領域には口を出さない • 最終決定権の所在を明らかにする ◦ デザイナーが持つと幸せ • アプリデザイナーを育てる ◦ OSの世界観とアプリデザインを教える
13. Material Design を 武器にする
14. Material Designで学ぶアプリデザイン • 現実世界がベースなので理解しやすい • リファレンスを読むことに抵抗がない • 学習と実装が同一人物 ◦ イメージ通り作れる • エンジニアでもそこそこのUIが作れる ◦ UIを理論で組み立てられる ◦ そこそこ以上はデザイナーが必要
15. どう学ぶべきか とにかくガイドラインを読む 1. Mateiral Design ◦ Introduction、Environment、Material Properties、 Elevation & shadows 2. Components、 Patterns 3. Layout、Style、Motion 4. Growth & communications、Usability
16. どう武器にしていくか • 工数削減 ◦ デザイナーと協力して工数を減らす • 知識と実装を繋げる • エンジニアだからこそできる改善をする
17. 知識と実装を繋げる 繋げるために必要な勉強 • 用意されているViewコンポーネントを知る • Themeを理解する • Viewの実装を学ぶ ◦ View#measure、ViewGroup#layout、Canvas • アニメーションの実装を学ぶ ◦ Animator、Transition、Drawable
18. エンジニアだからこそできる改善 • UIだけでない「体験」の改善 ◦ ≒高速化、爆速化 • RAILパフォーマンスモデル ◦ ノハナ社ではアプリ向けに修正 ▪ 遷移開始はユーザーアクションから100ms以下 ▪ アニメーションは1フレーム16ms以下 ▪ ユーザーを待たせる処理は1000ms以下 ▪ 1000ms以上のタスクは完全バックグラウンド ユーザー操作を妨げない
19. エンジニアだからこそできる改善 例：プレビュー画面 • Activity起動から表示までの中央値が1800ms • LogとSystraceで徹底分析 • 分割・遅延読み込み、レイアウト最適化 • 結果：160msまで改善
20. ノハナ社での Material Design 導入方法紹介
21. ノハナ社Androidチームの仕事 • 期初に数値目標を渡される • 現場で施策を考える • 目標に向かってPDCAを回す
22. ノハナ社のAndroidチーム • アプリエンジニア1人、アプリデザイナー1人、QA1人 ◦ 基本的にはエンジニア＋デザイナーで仕様検討 ◦ QAがコアユーザー層と被るので意見をもらう • サーバーエンジニア、マーケ、CS(各1人) ◦ みんなスペシャリスト
23. 課題の洗い出し 施策決定 プロト レビュー QA デザイン確認 リリース 振り返り 実装 指示書作成 エンジニア デザイナー QA
24. エンジニアがデザイン関わる利点 • デザイナー負荷削減 ◦ 巻き戻りの幅が小さくなる ◦ デザイナーがAndroidにとっつきやすくなる • 開発の時短 ◦ デザイン待ち時間削減 • アプリの質の向上 ◦ 巻き戻りしやすい ◦ 多視点で判断できる
25. 社内へのMaterial Design導入 導入 ~デザイナーへの周知~ • 社内Mateiral Design勉強会 ◦ 概念、世界、Viewコンポーネント • 社内アニメーション勉強会 ◦ 何ができる、どのくらい工数がかかる ▪ ドキュメントにして共有 ◦ 「何ができる」を共通言語化
26. 社内へのMaterial Design導入 発展 ~デザイナーの教育~ • 読んで欲しいガイドラインを明示 ◦ 次版で必要な部分を先読み • 根拠のある話し合い ◦ なぜそのデザインになったか聞く ◦ なぜそう思うのか根拠を言う
28. アップロード画面のリストの区切り線が結構目に付いています。 多分2dpになっている(本来は1dp)のもあると思いますが、TextFieldの 線とリストの区切り線で二重になっていることが主原因かと思います。 二重になっている意図がないならばどちらかをとってしまいたいと思いま した。 • Material Designではあまりリストの区切り線を描画しないので、 取ってしまってもよいかと思います。 • 逆にTextFieldの線を取るのもアリで、 https://material.google.com/components/text-fields.html#text-fiel ds-character-counter のFull-width text field with character counterのようなレイアウトで も良いと思います。
29. アップロード画面のリストの区切り線が結構目に付いています。 多分2dpになっている(本来は1dp)のもあると思いますが、TextFieldの 線とリストの区切り線で二重になっていることが主原因かと思います。 二重になっている意図がないならばどちらかをとってしまいたいと思いま した。 • Material Designではあまりリストの区切り線を描画しないので、 取ってしまってもよいかと思います。 • 逆にTextFieldの線を取るのもアリで、 https://material.google.com/components/text-fields.html#text-fiel ds-character-counter のFull-width text field with character counterのようなレイアウトで も良いと思います。
30. before after
31. 深読み ガイドライン
32. ガイドラインを深読みする • Material Design力を鍛える • 「なぜその仕様なのか」を考える ◦ 答えはない • ガイドラインに書いていない仕様を想像できる • ガイドライン外のことをやりやすくなる
33. 例1：Bottom navigation > On Android, the Back button does not navigate between bottom navigation bar views. BackボタンでBottom navigationのview(content)を操作するな
34. Bottom Navigation Back可 • Activityを閉じるとき • Dialogを閉じるとき • Navigation Drawerを閉じるとき • Bottom Sheetを閉じるとき Back不可 • Bottom Navigationのview(content)の戻り
36. BottomNavigation 結論 • Backボタンは画面の一番上のelevationの View全体を隠す(消す)際に使うべき • BottomNavigationのcontentは 画面の一番上のelevationのViewではない ◦ Backできるべきではない
37. 例2：Progress Dialog • ガイドラインに載っていない • support libraryにもない • なぜ？
38. Dialogs • > Use dialogs sparingly because they are interruptive. • ユーザーの操作を強制的に止めるもの ◦ 特にcancel不可なProgress Dialog • elevationは24dp ◦ Pickerと並んで最大
39. Progress Dialog 結論 • 待たせる際もユーザーの操作を止めるなという意図 ◦ Googleのアプリでは完全バックグラウンドが多い ◦ 待たせる場合でもユーザ操作可能なUI • そもそも1秒以上待たせない
40. まとめ
41. まとめ • エンジニアがアプリデザインに関わると捗る ◦ 工数削減、アプリの質の向上、体験の改善 • アプリデザインの勉強としてMateiral Designは良い ◦ 知識と実装が繋がると武器になる • エンジニアから社内にMateiral Designを広めよう ◦ 社内勉強会をやろう • ガイドライン通りでは他社に勝てない ◦ 深読みしてMateiral Design力をつけよう