未経験者から見たデザインシステム

「エンジニアリングに興味があるデザイナー、デザインに興味があるエンジニア Advent Calendar」3日目の記事です。

はじめまして！株式会社iCAREでフロントエンドエンジニアをしている武井と申します。2021年の8月中頃に実務未経験でエンジニアとして入社をさせていただきました。iCAREではCarelyという健康管理システムのSaaSを作っています。Carelyの開発において、デザインシステムを採用しているので、エンジニアになりたての自分から見た、デザインシステムについて書きたいと思います。

※この記事ではデザインシステムが何かについては記載はしておりません。

Carelyでのデザインシステム

本題とは逸れてしまうのでざっくりとした説明になりますが、design tokenの規定/コンポーネントの名称や機能をドキュメント化をしてStorybookで確認ができるようしています。また、頻繁に使用されているUIコンポーネントの共通化も進めています。詳しくは弊社デザイナーが書いた👇のnoteをご覧ください！

具体的にどのようなことをやったか

実際に私もデザインシステムに携わらせていただいています。

少し前まではテーブルを共通のコンポーネントに置き換えをしていました。Carelyには数多くのテーブルが存在し、画面ごとに各々で実装していたので、統一感にかけていました。そこで共通のcarely-tableというコンポーネントを作成して、carely-tableを既存のテーブルを置き換えていきました。

他にはモーダルを共通化するために、carely-modalというコンポーネントの実装を行ったり、design tokenを未使用箇所に適用させたりしています。

👆の赤枠内がcarely-table適用前で👇が適用後（テーブルがすっきりとして一目でより多くの情報を見ることができるようになりました）※デモデータです。

👇はdesign token

デザインシステムを進めてみて

デザインシステムを進めてみて感じたことは、開発者側にもユーザーの方々にも良いことが多いことです。先程、書きましたcarely-tableを例に取りたいと思います。

開発者にとっての良い面ドキュメントに沿ってcarely-tableを適用させていくことが出来るので、誰でも実装することができる。また、コンポーネントが共通化されているので、保守性の向上にも繋がる。

ユーザーの方々にとっての良い面は、可視範囲が狭かったり等のUXペインの解消による使い勝手の向上や各テーブルのUIが共通化しているので、迷うことなく利用することが出来るなどあります。

Carelyのデザインシステムはジュニアエンジニアである私でも迷わずに実装でき、高いユーザー体験を提供できる素晴らしいシステムだなと思います。

一方でデザインシステムを適用することでルールが厳格化して融通か効かなくなり、画面によっては共通コンポーネントを適用することが難しいこともあります。ルールをある程度厳格に保ちつつ、どのような画面にも適用していくには、コンポーネントの設計や実装時に色々なシチュエーションを想定して進めていく必要があるので、高い実装能力が求められるなと思います。

最後に

デザインシステムはデザイナーとエンジニ間の齟齬の発生を少なくし、開発体験の向上につなげる事ができます。また、ユーザーにとっても迷わずにプロダクトを利用できるなど良い面が多いです。プロダクトが大きくなれば大きくなるほど、必要性がます大切なシステムだと思います。なので、これからのCarelyの開発をさらに早く進めていくためにも、私自身も高い実装能力を身につけてデザインシステムやCarelyに貢献していきます💪

こちらのアドベントカレンダーの4日目も弊社エンジニアの方が記事を書いているので、是非見てみてください！

4日目: フロントエンドエンジニアのデザイナーとの向き合い方