フロントエンドエンジニアのshioriです。
テックタッチでは、約1年前からアプリケーションを丸ごと作り直す再設計プロジェクトを進めており、そのタイミングでデザインシステムを導入しました。 この記事では Material-UI を使ったデザインシステム導入の経緯や導入して良かったことなどを紹介したいと思います。
なぜデザインシステムを導入することにしたのか
テックタッチのプロダクトはデザインファーストで開発を行なっています。デザイナーが Figma で UI/UX をデザインし、それをエンジニアが実装するという流れです。 また、テックタッチは Material Design 等のデザインパターンをそのまま利用するのではなく、独自にデザインを行なっています。そのため、再設計前のプロダクトでは UI ライブラリを利用せずに、1から UI コンポーネントの作成をしてきました。
しかし、UI コンポーネントを自前で作成したことやUI コンポーネントのコードを継ぎ接ぎしてきたことが原因で、以下の問題に悩まされていました。
- 自前実装の UI コンポーネントの機能不全による度重なるバグ修正
- デザインの再現ミス
また、Figma 上でルール化されているものや共通化されているコンポーネントが、コード上では共通化されておらず、冗長なコードが多発。その結果、機能追加・変更のコストが増大し、思わぬバグを引き起こしたりしていました。
様々な UI ライブラリを調査したところ、Material-UI は高いカスタマイズ性があり、またマテリアルデザインに準拠したデザインシステムも整備されていました。 テックタッチのデザインは独自ではありますが、Material Design に比較的近かったため、Material-UI の導入ハードルは高くないのではないかという結論になり、導入するに至りました。
Material-UI の導入がうまくいけば、UI コンポーネントの機能面の品質は自前のコンポーネントよりも高くなるし、レイアウトやカラー、タイポグラフィーを始めとするデザインのエコシステムを利用することで、ハイレベルなデザインシステムを構築できるだろうという確信がありました。
デザインシステムができあがるまでの流れ
こちらの記事を参考にデザインシステムを作成していきました。 uxmilk.jp
スタイルの共通化
デザイナーと協力して、まずは Figma 上でスタイルの共通化を行いました。 カラーや余白など基本となるスタイルのルールはほぼ定まっていましたが、フォントには明確なルールがありませんでした。そのため、当初はMaterial-UI の Typography の variant (https://material-ui.com/ja/components/typography/) にならってルール化しました。（後述しますが後にパターンが増えすぎて見直すことになります）
Button や TextField 、Table などのコンポーネントも一貫性のあるデザインになっていましたが、Figma には表現されていない暗黙的なパターンや、ルールが曖昧な部分がいくつかありました。そういった明文化されていない部分を、デザイナーと見直しを行いました。
例えば、テックタッチのサービス内で使われている以下のボタン、見直し前は場所によって32pxだったり36pxだったり40pxだったりとバラつきがありました。相談の結果、サイズを統一したほうが一貫性があって良いということで36pxに統一。
スタイルの共通化を行う上で大切にしたことは、そのデザインにした背景を必ず確認することです。 デザインには、その形・配置にした意図や想いが込められています。一見、統一できそうなものでも、実はユーザーの視認性や操作性を向上させるために敢えてずらしていることもあります。 そういった隠された想いを必ず確認し、無理にまとめすぎないようにしました。
コンポーネントの実装
テックタッチのコンポーネントを Material-UI で実現できるよう、スタイルや機能の調整を行いました。 カラーパターンは独自に定義して ThemeProvider でカラーを設定。各コンポーネントはテックタッチのデザインになるようスタイルを上書きし、必要に応じて Material-UI のコンポーネントをラップして機能拡張しました。
例えば、テックタッチの TextField はサイズが3種類あるため、props でサイズ指定できるようにしたり、maxLength を超えた文字数が入力されたら「○文字オーバーしています」というメッセージが表示されるよう、Material-UI の TextField を拡張しています。
コンポーネントを設計・実装する上で意識したのが、単一責任の原則です。 コンポーネントの役割は1つとし、複数の役割を持たせないように分割していきました。複数の役割をもたせてしまうと実装が複雑になり、保守性や品質の低下に繋がるためです。 設計の際、Material-UI のコンポーネントの設計はとても参考になり、勉強にもなりました。
エンジニアがデザイン通りに実装できるよう、デザイナーに協力してもらったケースを紹介します。 こちらのアイコン内の SVG の位置は、中央配置に見えますが実は中央から1px上にずれています。
中央配置にすると、目の錯覚でずれているように見えるためです。しかし、おそらく大半のエンジニアがこの調整に気づかず、中央配置で実装してしまうことが予想できます。 そこで、あらかじめ内部のオブジェクトを1px上にずらした状態にした SVG をデザイナーに用意してもらうことで、エンジニアの実装ミスを回避できるよう調整しました。
できあがったコンポーネントは storybook で管理しています。どんなコンポーネントがあって、どんな動きをするのかを、誰でも簡単に確認できるため便利です。
Material-UI を使う上で苦労したこと
Material-UI のコンポーネントがそのまま使えることもありますが、大半はテックタッチ独自のルールを Material-UI にうまく適用させる必要があります。その中で最も難しかったのが Typography でした。
上述したとおり、当初は「見出し・本文・ラベル」といった分類分けをしていました。 しかし、テックタッチでは分類当初からフォントパターンが多く、さらに機能が増えるに伴いパターンも増えることが度々ありました。その結果、パターンが増えすぎて探す方が大変な状態になってしまいました。
改めてデザイナーと話し合ったところ、
- フォントは line-height ベースでデザインしている
- サービス内のそれぞれの場所で最も見やすいフォントサイズに調整している
ということで、「見出し・本文・ラベル」のような分類がテックタッチには合っていないことが分かりました。
最終的に、フォントサイズのパターン化は取りやめ、利用する場所でフォントサイズや line-height を指定する方法に落ち着きました。
導入して良かったこと
デザイン・実装ともに統一感が出た
デザインは元々ある程度整理されていましたが、改めて曖昧だった部分を明確にしたことで、より一貫性のあるデザインになりました。実装についても共通化したコンポーネントを使い回すことで、実装漏れやメンテナンスコストを削減することができました。
コンポーネントの品質向上
Material-UI のコンポーネントの品質が高いため、Material-UI ベースでコンポーネントを作ることで安定性が高まりました。自前で作ると考慮漏れしそうな部分にも、しっかりと対応してくれているので安心です。
また、コンポーネントの機能が充実しているので、Material-UI を使うことでこれまでになかった機能が自動的に追加され操作性がアップしました。（例えばキー操作が可能になったりなど）
コード量の削減
Material-UI ベースなのでコンポーネント自体のコード量が減りました。 また、これまで共通化されていなかった部分が共通化できたため、冗長なコードを大幅に減らせました。
さいごに
Material-UI を使うことでスピーディにUIコンポーネントの質を高めることができ、デザインシステムの導入によりデザインもコードも品質が向上したと感じています。
今回の取り組みの中でデザイナーとデザインの整理を行うことで、各デザインの意図を改めて知ることができました。そのため、各コンポーネントはその想いを汲んだ形で実装されています。 プロダクトの品質を維持しつつ機能拡張していくには、デザインシステムも随時アップデートしていく必要があり、そのためにはデザイナーとエンジニア間の連携は必要不可欠だと考えています。
今後もお互いに協力しあいながら、プロダクトをより良いものにブラッシュアップしていきたいと思います。
