概要
モバイルアプリ開発におけるデザインチェックのつらみを、Hyperion Androidというデバッグライブラリを実際のプロジェクトで導入して解決した話です。
プロジェクトにおける、デザインをフィックスする際のフロー
自社開発のフローはどうなっているか分かりませんが、自分が現在所属するアイリッジのモバイルアプリの受託開発では下記のようなフローになっています。
- デザイナー：XDでプロトタイプを作成
- マネージャー：プロトタイプのデザインでプロジェクト各関係者の合意を取る
- デザイナー：デザイン素材の切り出しを行う。
- エンジニア：プロトタイプを元にUI部分を作成、モックとしてある程度動作させる
- デザイナー：モックアプリを確認。色やアニメーション、レイアウト等デザイナーのニュアンスと違いが無いか確認
- デザイナー：ニュアンスに違いがある部分のissueを立てる
- エンジニア：6.で立てられたissueの対応を行う。5に戻る。
今回の記事では、4 ~ 7の間にある辛みをどのように解消したかに関して書いていきます。
現状の課題
上に書いたフローでは、デザインを修正していくにあたって下記のような課題がありました。
デザイナーの指摘がニュアンス止まりになってしまう
実際に立てられたissueの例
- 特定の機種だと、ポイント表示欄の単位「P」のサイズが小さい。また、ポイントの数字自体もサイズが小さい。
- ボーダーの色が強いので弱くしたい。それかサイズを0.5にする?
何が問題か？
エンジニア側
- 修正する際の認知負荷量が高い。
- ボーダーの色が強いのは透過度の設定が間違っているから？ カラーコードが違うから？ 調査から始めないといけない。
- 「サイズが小さい」は現時点だと何px? 周りの文字が大きいから相対的に小さい？
デザイナー側
- アプリだと、現在描画されている文字や色の具体的な詳細（カラーコードや文字の大きさなど）が分からない。チェックの工数も限られているので、ニュアンスで判断してissueを立てるしかない。
導入したもの
- Hyperion Androidをdebugビルドに導入しました。
build.gradle
dependencies {
debugImplementation 'com.willowtreeapps.hyperion:hyperion-core:0.9.24'
debugImplementation 'com.willowtreeapps.hyperion:hyperion-attr:0.9.24'
debugImplementation 'com.willowtreeapps.hyperion:hyperion-measurement:0.9.24'
debugImplementation 'com.willowtreeapps.hyperion:hyperion-disk:0.9.24'
debugImplementation 'com.willowtreeapps.hyperion:hyperion-recorder:0.9.24'
debugImplementation 'com.willowtreeapps.hyperion:hyperion-phoenix:0.9.24'
debugImplementation 'com.willowtreeapps.hyperion:hyperion-crash:0.9.24'
debugImplementation 'com.willowtreeapps.hyperion:hyperion-shared-preferences:0.9.24'
debugImplementation 'com.willowtreeapps.hyperion:hyperion-geiger-counter:0.9.24'
debugImplementation 'com.willowtreeapps.hyperion:hyperion-timber:0.9.24'
}
- どのような機能があるか？などは、素晴らしいまとめ記事が参考になると思うので、参照下さい。
今回主に使用したHyperionの機能。
Mesurement Inspector
- 各Viewのwidthやheight,各View間のdpを算出して出力してくれます。
Shared Preference
- Shared Preferenceの中身をアプリ上から閲覧・編集が出来ます。
Attribute Inspector
- 各ViewのAttribute（TextViewならTextColorやSizeなど）を閲覧する事が出来ます。
チームへの導入に際してした事など
- デザイナーに、アプリからの呼び出し方を10分ほどレクチャーしました。直感的になっているのでデザイナーも理解がしやすかったようです。
- プロダクションビルドに入れるものではないので、チームとしての導入障壁も低かったです。
- 導入に使った時間は合計1時間も無いと思います。
改善したこと
デザイナーの指摘が具体的に
実際に立てられたissueの例
- ☓☓の金額のサイズ 32 -> 34に変更して下さい。
- ◯◯のフォント 不透明度80に直して下さい。
- △△と通知バナーの間の間隔を6dp -> 12dpに変更をお願いします。
Happyになったこと
エンジニア側：感想
- 前に比べて、デザイン修正における認知負荷量が圧倒的に低くなった。
- デザイナー側の指示を何かしらの調査、解釈必要なしに修正をするだけでよいので、心理的な負担が少ない。実際にタスクにかかった作業時間も減った。
- 修正作業中も、実際に出力されているdpや色の確認がスムーズになった。
- デザイン修正にかける時間・集中力が減ったため、その分のリソースをコアとなるロジックの設計・バグ修正・テストなどに使えるようになった。
デザイナー側：感想
- デザイン確認の最終の調整がやりやすくなった。
- 以前は実装されている数値を直接エンジニアさんに聞くか、だいたいの数値を伝えてデザイン確認していたものが明確に数値を伝えらるのでデザイン調整でお互いの時間を使うことが減った。
- ワイヤーの数値通りに入れてもらえば最後の調整自体不要なところもあるため、ワイヤー作成時点（アプリ作成前）の連携ミスは別の手法で解決すべきという課題はのことっている。
- ワイヤー作成時点のデザインデータの設定にデザイナーがミスするケース、エンジニア側で違うレイアウトの数値で入れてしまうケースがある。
まとめ
- Hyperionの導入は簡単、かつ適切に運用すればチームの皆が幸せになれる。
- 直感的に扱えるデバッグメニューを扱えるため、導入障壁・学習コストは低い。
- 個人アプリ開発・チーム開発どちらでも便利！
Android側だけ導入していたのですが、iOS側も影響を受けてHyperionのiOS版を導入するほどでした。導入していない方はぜひ使ってみて下さい！