見出し画像

サービスの負債を解消する!エンジニアとデザイナーの共創プロセス

家計簿サービス Zaim のデザイナーの今泉です。

今回はエンジニアとデザイナーが協力して UI デザインの負債を解消するために「UI 改善会」に取り組んだお話をご紹介します。

UI 改善会って何?

一言でいうと、エンジニアとデザイナーのペアプロ・ペアデザのような会です。

エンジニアとデザイナーが同じ時間に集まり、サービスの負債の解消に取り組みます。
デザイナーはデザイン作業を、エンジニアは実装作業を画面共有し、お互いの作業画面を見て、相談しながら修正していきます。
Zaim はリモート勤務がメインなので、この改善会も同じ時間に oVice と Google Meet で繋がりながら開催しました。

ここでいう負債は、

・デザインデータと実装されている画面に差異があるページ
・優先順位が高くなく、古いデザインのままのページ
・OS ごとや画面ごとによる意図していないデザインの差異

といった、発見していて直したいと思っているけど、他の優先度が高いタスクに追われてなかなか手が付けられない課題のことを指しています。

UI 改善会の目的

UI デザインの負債解消の他に、今回は三つの目的をもってプロセスを設計しました。

1.UI の負債を解消する
・優先度は低いが修正したい UI のあれこれを少しずつ整える

2.エンジニアとデザイナーの業務の理解を深める
・お互いどんなことを考えて開発しているのかを知る
・エンジニアもデザインについて意見できるようになる
・デザイナーは実装時のことを考慮してレイアウトを考えられるようになる
・施策の検討やレビュー時の意見交換をより活発にする

3.デザインシステムをより使いやすく更新する
・システムの課題を発見する
・コミュニケーションコストがかかっているシーンを見つけ、仕組みで解決できる方法を考える(例えば、余白これでいいの?→余白のルールをシステムに組み込む、のようなもの)

実施方法

今回の参加メンバーはデザイナー 1 名、iOS エンジニア 1 名、Android エンジニア 1名の計 3 名です。
日程は三日間で、次のようなスケジュールで開催しました。

一日目 課題を発見する(1 時間)
二日目 開発(3 時間)
三日目 ふりかえり(30 分)

一日目:課題を発見

3 人で集まりそれぞれの手元に iOS と Android の端末を並べ、同時に同じ画面を見ながら気になった点をピックアップしていきました。
見つけた課題はその場で FigJam のボードに付箋を貼り付けました。
付箋には対象の画面のキャプチャも貼り付けて、後から見ても分かりやすくしました。

付箋をたくさん貼り付けた後、OS ごとや「色」「余白」など、関連する課題をグルーピングしています。

画像4

課題はたくさん見つかりますが、意外と難しかったのが対応範囲を決めることでした。
解消したいと思っても時間内に終わらなそうな課題や、単純に直すだけの課題ならみんなで相談しながら修正する必要がないので、除外していきました。

今回は Zaim アプリのホーム画面の UI 改善に取り組むことに決めました。
選定した理由は以下の通りです。

・iOS / Android 両方に改善ポイントがある
・修正する箇所と方法を、エンジニアとデザイナー間でコミュニケーション取る必要がある
・ユーザーへの印象が変わる(見て分かる修正)
・半日で実装可能で、全部終わらなくても区切りがつけられる

二日目:開発

いよいよ開発当日です。
oVice というバーチャルオフィスでオープンにしながら開催しました。
ミーティングをオープンにしたのは、今回の改善メンバー以外の人にも開発風景を見てもらったり、その場で議論に飛び入り参加してもらったりできるようにしておくのが狙いです。

まず最初に、ホーム画面の負債や課題をどう解消するか 3 人で段取りを決めました。
デザイン修正しながら同時に開発していきます。
随時、誰かの作業画面を公開しながらお互いやっていることも観察しています。
デザイナーの作業画面を見せている時は Figma を操作しながら、時折エンジニアにデザインも相談しながら進めました。
単純なデザイン相談についてだけではなく、「こういう修正をしたいと思うんだけど実装するの大変?」と問いかけると、実装の難易度を教えてもらえるので、「こういうのは時間がかかる修正になるんだな」と学びになりました。

逆にエンジニアが開発している様子を見ながら、デザイン修正の細かい詰めを自分が口頭で伝えながら、ペアプロのようなやり方で修正していきました。

画像3

気がつくと oVice で自分たちのまわりにたくさんの人が集まっていました。
集まった人に「ここの修正どうしたらいいと思います?」と問いかけると、職域を超えてたくさんの意見をもらえたのが楽しかったです。

今回は 3 時間の開発時間で、表記の修正や余白の統一など細かな改善や、フォントシステムの定義を見直したほか、全体的にデザインを整えるような修正を実施しました。
Pull Request を作成し、この日は完了としました。
開発のレビューは他のメンバーの協力も必要なため、改めて後日、実施しています。

三日目:ふりかえり

KPT(Keep, Problem, Try)方式でふりかえりました。
UI 改善会の目的は以下のように達成できました。

1. UI の負債を解消する
→ 表記の修正や余白の統一など細かな改善ができた

2.エンジニアとデザイナーの業務の理解を深める
→ 今回ラベルが揃っていないなどの軽微な修正を実施することで、今後のレビューでも同じように揃える認識ができた

3.デザインシステムをより使いやすく更新する
→ フォントのスタイル定義を見直し、デザインシステムをアップデートできた

画像4

また、本来の目的を達成した以外でも良かったことがありました。
アクセシビリティの配慮など、改善以外の余談から知識を共有できたことや、オープンスペースで実施したことで賑わいがあって楽しかったことです。

次回への改善点もあります。
改善方法の相談が発散しすぎて脱線してしまったので、改善会で取り組むテーマの基準やルールを作ったほうが良さそうだなと感じました。

まとめ

今回はエンジニアとデザイナーが協力して負債に取り組む UI 改善会について、ご紹介しました。
UI デザインの負債の解消が目的ではありましたが、リモートワークで離れて作業していると、お互いがどんなことを考えて作業しているかが見えづらいことも、ひょっとしたらサービス開発の「コミュニケーションの負債」になっているかもしれないなと思いました。
そして UI 改善会を実施してみて、離れていてもその負債は解消できると実感しました。


こういった機会を今後も設け、UI 改善会の取り組み自体もどんどん改善していきたいです。
似たような負債を解消するための取り組みや、エンジニアとデザイナーのコミュニケーション方法について、気になる方がいたらぜひ情報交換させてください。

Zaim の開発チームは職域ごとの専門性はありつつ、デザインに対してエンジニアがレビューをしたり、職域を超えて施策を一緒に議論したり、サービスをより良くするための積極的な意見交換ができるチームだと思っています。
私はチームでサービスを作ることが好きなので、この環境を楽しんでいます。
同じように一緒に開発したいと思ってくださったら、ぜひお話させてください!


いいなと思ったら応援しよう!

この記事が参加している募集