エンジニアがデザインチェックするようになって気づいたこと

記事概要

こんにちは、ネットオン開発Sec.のサイトーさんです。

今回はエンジニアチームで行っている画面実装後のデザインチェックの取り組みと課題についてまとめてみます。

デザインチェックについて

最近の採用係長の開発では画面の修正を行う際に軽微なデザイン崩れなどがないかレビュー時に確認するようにしています。レビューではデザイナーチームが作成したガイドラインをもとに修正内容がガイドラインに違反しているか、あるいは修正の影響によって既存のデザインが崩れていないかチェックしています。ただ、この作業を通じて以下の課題が見えてきました。

• 確認項目が多いため、エンジニアのチェックで見落としが発生する
• レスポンシブなデザインのため、特定の画面のみ崩れることがある
• 画面ごとにパーツのデザインが異なっているケースがあり、再利用しづらい

これらの課題に対して現状の整理と対策として以下のような施策を行っています。

デザインガイドラインを意識するようにする

デザインガイドラインはデザイナーチーム主導で作成を進めて頂いているのですが、それらの認識を深めるため以下のことを実施しています。

• githubのプルリクエストテンプレート内にデザインガイドラインを設置する
  プルリクエストテンプレート内にガイドラインのURLを配置することで、実装者とレビュアー双方にガイドラインを意識させ、実装漏れや確認漏れをなくすようにした。
• デザインガイドライン変更時にデザイナーチームから共有会を実施してもらう
  ガイドライン変更時にデザイナーチーム主催で共有会を開いてもらい、ガイドラインの意図などを説明して頂くことで、エンジニアの理解促進と認識漏れをなくすようにしました。

インターフェースインベントリを実施し現状を確認してみる

エンジニアチームではデザインガイドラインをもとに新規画面作成や修正などがあった際にチェックするのみとなっていますが、現在の実装でどれほどのガイドライン違反があるかを確認するためにインターフェースインベントリというワークショップを行ってみました。このワークショップではアプリ上にコンポーネントやパーツをカテゴリーごとに分類することで古くなっているデザインの洗い出しや共通化できていないパーツを見つけ出すことができるものです。今回はすべての画面ではなく実装が複雑ないくつかの画面をピックアップし実施してみました。

このワークショップを通して特定の役割を持つパーツのデザインが他と異なっていることや画面ごとにガイドライン違反がどれだけあるのかを俯瞰的に確認することができました。今回ワークショップは時間の都合で一人で実施していたのですが、デザイナー・エンジニア両チームで行うことで、デザインに対する疑問の解消や意図などを理解することに役立つのではと感じました。

ガイドラインに準拠した環境を作る

デザイナーチームが作成しているガイドラインをもとにデザイン修正を行っているのですが、共通化しているコンポーネントの中にはガイドラインに準拠していないものがあったり、tailwindなどで設定しているカラーコードの中にもガイドラインに準拠していないものが現状のシステムにあることが分かったので、それらを刷新すべく実装環境の整備や共通コンポーネント作成などを行っています。これにより、デザインチェック時に細かな差分が出ないようにし、エンジニアが目視でチェックする内容量を減らす活動を進めています。

まとめ

エンジニア側でデザインをチェックするようになって私自身デザインについて興味を持つようになってきました。現状見えている課題に対しては完璧な解決法がなく、環境づくりやワークショップ実施などでデザインについて学んでいます。これからも継続的に学ぶことでデザインチェックがなくとも正しく実装ができるようになるのではと思っています。