エンジニアが武器にする
Material Design
DroidKaigi 2017
株式会社ノハナ 瀬戸優之
@seto_hi

自己紹介
● 瀬戸優之 せとひろゆき @seto_hi
● Android開発歴 6年半くらい
● コンシューマー向けAndroidアプリ開発一筋 5年
● 株式会社ノハナ
○ 唯一のAndroidエンジニア
○ 絶賛採用中
● 好きなAPIはCanvas#saveとViewGroup#layout

なぜエンジニアがデザイン?
● 大学の研究分野がHCI
○ コンピュータを使いやすくするUI研究
● 前職ではUIデザインも担当
○ デザイナーはアイコン作るだけ
● 現職では新卒デザイナーとチーム
○ Androidアプリデザイナーとして教育

僕と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化完了

ノハナノハナシ [検索]

デザインエンジニア推進派
● 「デザインはデザイナーに任せるには重要すぎる」
○ アプリデザイン ≠ Webデザイン、グラフィックデザイン
○ アプリデザイン=UIデザイン＋ユーザー体験のデザイン
■ 必要な知識が多い
● アプリエンジニアもユーザー体験に責任を持つべき
○ 理解していないデザインを実装してない？

今日言いたいこと
● エンジニアがアプリデザインに関わると捗る
○ 工数削減、アプリの質の向上、体験の改善
● アプリデザインの勉強としてMateiral Designは良い
○ 知識と実装が繋がると武器になる
● エンジニアから社内にMateiral Designを広めよう
○ 社内勉強会をやろう
● ガイドライン通りでは他社に勝てない
○ 深読みしてMateiral Design力をつけよう

目次
● エンジニアとアプリデザイン
● Mateiral Designを武器にする
● ノハナ社でのMaterial Design導入方法紹介
● 深読みガイドライン

エンジニア
と
アプリデザイン

エンジニアがアプリデザイン関わる利点
● デザイナー負荷削減
○ 巻き戻りの幅が小さくなる
○ デザイナーがAndroidにとっつきやすくなる
● 開発の時短
○ デザイン待ち時間削減
● アプリの質の向上
○ 巻き戻りしやすい
○ 多視点で判断できる

エンジニアがアプリデザイン関わる欠点
● エンジニアに負荷がかかる
○ コーディングにフルコミットできない
● デザイナーはデザインチームとエンジニアの板挟み(かも)
● 論理的な反論に慣れていないデザイナーはつらい(かも)
● 理論的に正しいが微妙なUIができる可能性
○ 時には直感を信じることも必要
● 一部デザイナーから反発がある

アプリデザインとどう関わるか
● やりすぎない
○ 協力してお互いをカバーする
● デザイン領域には口を出さない
● 最終決定権の所在を明らかにする
○ デザイナーが持つと幸せ
● アプリデザイナーを育てる
○ OSの世界観とアプリデザインを教える

Material Design
を
武器にする

Material Designで学ぶアプリデザイン
● 現実世界がベースなので理解しやすい
● リファレンスを読むことに抵抗がない
● 学習と実装が同一人物
○ イメージ通り作れる
● エンジニアでもそこそこのUIが作れる
○ UIを理論で組み立てられる
○ そこそこ以上はデザイナーが必要

どう学ぶべきか
とにかくガイドラインを読む
1. Mateiral Design
○ Introduction、Environment、Material Properties、
Elevation & shadows
2. Components、 Patterns
3. Layout、Style、Motion
4. Growth & communications、Usability

どう武器にしていくか
● 工数削減
○ デザイナーと協力して工数を減らす
● 知識と実装を繋げる
● エンジニアだからこそできる改善をする

知識と実装を繋げる
繋げるために必要な勉強
● 用意されているViewコンポーネントを知る
● Themeを理解する
● Viewの実装を学ぶ
○ View#measure、ViewGroup#layout、Canvas
● アニメーションの実装を学ぶ
○ Animator、Transition、Drawable

エンジニアだからこそできる改善
● UIだけでない「体験」の改善
○ ≒高速化、爆速化
● RAILパフォーマンスモデル
○ ノハナ社ではアプリ向けに修正
■ 遷移開始はユーザーアクションから100ms以下
■ アニメーションは1フレーム16ms以下
■ ユーザーを待たせる処理は1000ms以下
■ 1000ms以上のタスクは完全バックグラウンド
ユーザー操作を妨げない

エンジニアだからこそできる改善
例：プレビュー画面
● Activity起動から表示までの中央値が1800ms
●
LogとSystraceで徹底分析
● 分割・遅延読み込み、レイアウト最適化
● 結果：160msまで改善

ノハナ社での
Material Design
導入方法紹介

ノハナ社Androidチームの仕事
● 期初に数値目標を渡される
● 現場で施策を考える
● 目標に向かってPDCAを回す

ノハナ社のAndroidチーム
● アプリエンジニア1人、アプリデザイナー1人、QA1人
○ 基本的にはエンジニア＋デザイナーで仕様検討
○ QAがコアユーザー層と被るので意見をもらう
● サーバーエンジニア、マーケ、CS(各1人)
○ みんなスペシャリスト

エンジニア
デザイナー
QA
課題の洗い出し
施策決定
レビュー
プロト
実装
指示書作成
デザイン確認
QA
リリース
振り返り

エンジニアがデザイン関わる利点
● デザイナー負荷削減
○ 巻き戻りの幅が小さくなる
○ デザイナーがAndroidにとっつきやすくなる
● 開発の時短
○ デザイン待ち時間削減
● アプリの質の向上
○ 巻き戻りしやすい
○ 多視点で判断できる

社内へのMaterial Design導入
導入 ~デザイナーへの周知~
● 社内Mateiral Design勉強会
○ 概念、世界、Viewコンポーネント
● 社内アニメーション勉強会
○ 何ができる、どのくらい工数がかかる
■ ドキュメントにして共有
○ 「何ができる」を共通言語化

社内へのMaterial Design導入
発展 ~デザイナーの教育~
● 読んで欲しいガイドラインを明示
○ 次版で必要な部分を先読み
● 根拠のある話し合い
○ なぜそのデザインになったか聞く
○ なぜそう思うのか根拠を言う

アップロード画面のリストの区切り線が結構目に付いています。
多分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のようなレイアウトで
も良いと思います。

アップロード画面のリストの区切り線が結構目に付いています。
多分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のようなレイアウトで
も良いと思います。

before
after

深読み
ガイドライン

ガイドラインを深読みする
● Material Design力を鍛える
● 「なぜその仕様なのか」を考える
○ 答えはない
● ガイドラインに書いていない仕様を想像できる
● ガイドライン外のことをやりやすくなる

例1：Bottom navigation
> On Android, the Back button does not navigate between
bottom navigation bar views.
BackボタンでBottom navigationのview(content)を操作するな

Bottom Navigation
Back可
● Activityを閉じるとき
● Dialogを閉じるとき
● Navigation Drawerを閉じるとき
● Bottom Sheetを閉じるとき
Back不可
● Bottom Navigationのview(content)の戻り

BottomNavigation 結論
● Backボタンは画面の一番上のelevationの
View全体を隠す(消す)際に使うべき
● BottomNavigationのcontentは
画面の一番上のelevationのViewではない
○ Backできるべきではない

例2：Progress Dialog
● ガイドラインに載っていない
● support libraryにもない
● なぜ？

Dialogs
● > Use dialogs sparingly because they are interruptive.
● ユーザーの操作を強制的に止めるもの
○ 特にcancel不可なProgress Dialog
● elevationは24dp
○ Pickerと並んで最大

Progress Dialog 結論
● 待たせる際もユーザーの操作を止めるなという意図
○ Googleのアプリでは完全バックグラウンドが多い
○ 待たせる場合でもユーザ操作可能なUI
● そもそも1秒以上待たせない

まとめ

まとめ
● エンジニアがアプリデザインに関わると捗る
○ 工数削減、アプリの質の向上、体験の改善
● アプリデザインの勉強としてMateiral Designは良い
○ 知識と実装が繋がると武器になる
● エンジニアから社内にMateiral Designを広めよう
○ 社内勉強会をやろう
● ガイドライン通りでは他社に勝てない
○ 深読みしてMateiral Design力をつけよう