https://gyazo.com/5b013b94a380428230788c97dc4bdb7a
路線／地図のWebサイトの設計・開発を担当
アプリのデザイン・開発担当
乗り換え案内アプリとは
3500万DL
機能
ルート検索
時刻表
運行情報
通勤タイマー
開発体制
デザイナー2名
エンジニア2名
変遷（2014年以前）
Androidは仕様書や実機を見ながら確認
差異があるものは都度確認・修正
画像パーツはiOSベース、必要なものは都度作成
エンジニアで画面を実装
2015年ー現在
より特化したデザインへ
theme
supportLibrary
デザイナーが画面レイアウトの修正
実装はデザイナーがぜんぶやる
具体的な役割
仕様検討
デザイナーのフローと同じ
昔はUIデザインのみ
画面実装
路線独自な作業フロー
Activity（設定） / Fragment（コンテンツ）の使い分け
Backボタンの挙動
通知・Widgetなどの独自挙動
画面デザインしていると忘れがち
UIパーツ
タブやDataPickerのパーツは標準に
オリジナルUIは避ける
将来的なThemeの更新などでデザインをアップデートできる考慮も
UIビジュアル
Toolbarの配色など画面デザインが異なる
画面レイアウト・パーツ実装
xml/styleファイルの作成
Selectorの作成
エンジニアにはロジックの実装に専念してもらう
画像・テキストのアセット管理
xhdpiやxxhdpiの管理はデザイナー管理
色やテキストも管理
エンジニアと同じ環境で開発
自分で実機ビルドしながら微調整
改善結果
エンジニアは開発に集中
デザイナーはUIの磨き込みに集中できる体制
テスト中やリリース前はお互いのタスクが集中するので役割分担ができた
ワークフローの分担
デザイナーが主体で変更
しかしデザイナーすべてをやってもらうのは困難
役割分担はWebサイトの制作手法が参考になった
Webサイトのデザインは誰でも熟知してる
アプリデザインは未知なことが多い
エンジニアがどのような画面実装しているかがわからない
どのようなパーツがあるか使えるのか知らない
自分で触れることができないため知る機械がない
それぞれのロールの歩み寄り
WebDev領域のような画面開発エンジニアがいたら心強い
画面モックだけつくるだけでは駄目
画面の流れや挙動やパーツをしっかり意識
Android エンジニア
ラクマ
これまでの振り返り
発表から４ヶ月後にアプリに準拠
早いタイミングで取り入れてみた
ユーザーエンゲージメントにとどまらない
多面的なメリットを感じていた
開発効率
Design Support Libraryなどの公式アセット
少ない工数でリッチな体験を実現可能
エンジニアのデザイン意識
デザイナーとの共通言語をもてる
実装時の納得感
デメリット・課題について
ブライド表現への制約
これからの展望
2015/05 LaunchScreen
2016/03 BottomNabigation
2017/04 TextField（Box style）
2018/05 ガイドラインが大幅リニューアル
Material Theming
柔軟なブランド表現が可能に
コンポーネントの拡充
毎月アップデート・リリースしていく公約（ガイドライン上にある）
ガイドライン変化の中でエンジニアができること
大きな変更があったとき…
組織統合
プロダクト統合
変化に適応する余裕がない期間が続いた
アプリエンジニアが提案して主導するには？
アプリエンジニア＝変化に強い
「変化に順応する」強みをUIデザインの領域に
単なる情報共有だけでなく
課題解決の目線で提案していく
何を表現できるか？
どういう変更が可能か？
解決できる課題とはなにか？
Material Theme Editor
デザイナーに提案できるツールに
事業KPIへの納得性をもたせる
小さくためせる環境をつくる
ユーザーの行動トラッキング
アクション（Push通知・ポップアップ）を設定する
ユーザーを１人の人と理解して適切なコミュニケーションをとる
アプリ内メッセージ機能
Web上の管理画面から編集してアプリ上にアクションを設定 重要な部分
簡単さ
カスタマイズ性
設計／実装
方針
定形のものを表示する
Native UI
画像＋テキスト＋ボタン、画像など
自由なカスタマイズ
最初からテンプレートを用意している
Tracker
In-app messaging
アプリ内メッセージ
Push Notification
Variables
Firebase Remote Configのような機能
他のコンポーネントに依存しない
アクション表示までの流れ
TrackerからRequest
KARTEよりActionを含んだResponse Pass Track API ResponseをWebViewに
WebViewからKARTEにtracker.jsを渡す
KARTEからtracker.jsでresponseをWebView渡す
WebViewへの追加
addContentView
アクションの表示にActivityに追加
非表示時に破棄
window managerのWebViewも使えそう？
タップでうまく機能しない
まとめ
簡単・柔軟なメッセージの実装としてWebViewへアクションを配信する手法をとった
UI改善に繋がるエンジニアの立ち回り
アプリエンジニア
リサーチ、施策、デザイン
nohana
フォトブックアプリ
UI改善とは？
エンジニア＝実装
実装以外はデザイナーよろしく
実際はそんなことはない
UI改善に必要な知識は分離している？
デザイナーとエンジニアの領域が被っていることが大事
すべて任せず、協力していくことが大事
https://gyazo.com/cff41df6f5a29b0d36c11d2c3761fb34
デザイナーへの情報提供
守備範囲をデザイナー領域に入り込む
開発情報
ProgressDialogがDeprecated
こういう情報はデザイナーはキャッチアップ・理解するのが大変
Material Componentsの情報
AndroidXに対応済み
デザイナーのデザイン戦略も変わる
実装情報
工数見積
Extended FABはButtonで作れる
ダイアログは二重に出せない
コミュニケーションポイント
リリース振り返り（頻度少）
週定例、Winセッション
朝会
雑談（頻度多）
ここに重点をおいてみる
アプリデザインの知見
共通認識
AnimationやComponentで環境と実装の話もしやすい
デメリット … 全ページよむと時間がかかる
週3〜5pペース
全部終わるのは1年
チェックポイント
エッジケース
画面回転
工数少なかったら横画面レイアウトは除く
Empty Status
空のとき
オフライン
キャッシュ対応？動作不能？
マルチウィンドウ／縦長ディスプレイ
アスペクト比が低い端末
デザイナーに要相談
コード
エラー処理
try-catch, onErrorでユーザーFBしてる？
仕様が複雑？
ユーザーが理解できるようにする
ユーザーとして
操作の手数
1画面3操作以下に収める
動作速度
100ms以内に反応
1s以上の待ち時間を作らない
エクストリーム・プログラミング開発におけるUIテスト〜ライブコーディングを添えて
サイエンスチーム
ヤフオク！アプリ開発部
820Labs
ペアプログラミングが特徴
片方がテスト、片方が実装
どういう風に実装するかを常に議論できる
レビューする必要もなくなる
仕様書を書く必要もなくなる
卓球が業務にある
何を作るか？に関わる
プロダクトマネージャー
どうやってつくるか？に関わる
エンジニア側
XP
より安いコスト
より低い欠陥数
より高い生産性
より高い投資効果で開発
習慣・実績（プラクティス）
タイトルに課題
詳細にはPMにもエンジニアにもわかる内容
アクセプタンス条件
Gherkin記法
AS, GIVEN, AND, WHEN, THENの各ストーリー
Android Studio
左画面にテストコード
右画面に実装コード
導入結果
シナリオテストの失敗率がかなり減った
手戻りの減少
プロダクトに対して自信がもてる
残業時間が減った