0→1受託開発と事業会社のUIライブラリー構築・デザインシステム構築を比較してみた
こんにちは、プロダクトデザイナーのほっしーです。
7月に入社してから、はや6ヶ月が経ちあっという間に年の瀬です。
はじめに
最近はhacomonoプロダクトのデザインシステムの構築・整備に携わっています。 前職では受託案件で0→1のデザイン上のUIライブラリーの構築に携わることが多く、今回初めて事業の中の人としてSaaSのデザインシステム構築・整備を行いました。
そこで今回は私が感じた違いについて述べていきたいと思います。
転職を考えている方や2つの体制どちらかに似たプロジェクトに初めて参画される方の参考になれば幸いです。
0→1のデザイン上のUIライブラリーの構築の場合【受託開発】
クライアント側から外注している性質上サービスにも共通して将来の運用体制に向けて、属人化を防ぐ＋効率化のためにUIライブラリーの構築を行なっていました。
また、ビジネスヒアリングも行い、走り出し向けの簡易的なブランディングの役割も含めて構築を行う場合もありました。
参画体制
サービスの規模・アサイン状況によりますが、デザイナーが1名で入ることもあれば、チームで参画していることもありました。後者の場合の内訳は下記です。
メインデザイナー（1人）
サブデザイナー（1-2人）
構築範囲
開発体制や今後の運用に適した構築を行いますが、1stリリースを優先した対応になることが多く、引き継ぎ後も機能の拡充が積極的に行われることが多いです。
そのため、方針や運用体制によってFigmaと運用チーム全体に向けた資料の作成を行います。
Figma(資料+マスターコンポーネント)
運用チームに向けた資料
上記の構築はデザイナー側のみが行ないます。（そのためデザインシステムではなくUIライブラリーの構築としています）
構築の目的
運用時の引き継ぎを円滑にする(運用時はクライアントが行う場合など)
React・Vue.js等 基本の開発体制を元にUI基盤を整備しておきたい
簡易的なサービスブランディングも兼ねたい
hacomonoのデザインシステムの構築・整備の場合【自社開発】
現状抱えている課題の解決のため、コンポーネント構築・整備を行っています。
課題解決を根本とする点は共通ではないかと思います。
参画体制
hacomonoではUIデザインシステム委員会というチームにエンジニアリングマネージャー・エンジニア・デザイナーが所属し、プロダクト品質改善とデザインシステム構築の旗振りを行っています。
こちらのUI改善委員会から分岐してできたチームとなります。
私は今回、Buttonコンポーネントの整備を担当。レビューをデザインチームとUIデザインシステム委員会に依頼しながら整備を行っております。
構築範囲
Figma(資料+マスターコンポーネント)
hacomonoはstorybookを導入しています。レビュー時からエンジニア確認を行い方針を調整しながら、Figmaにてドキュメント構築。その後エンジニアへstorybookへの反映をお願いしています。
構築の目的
プロダクトが抱える課題を洗いだし、下記を共通の目的としています。
プロダクトの品質担保
開発者の負担軽減
私が思う2つの違いについて
0→1デザイン上のUIライブラリーの構築は
「将来の運用体制・サービス方針に備えた構築」
hacomonoのデザインシステムの構築・整備は
「現状課題を解決するための構築・整備」
2つとも運用中へのアプローチになりますが、着目する部分や重要とするポイントが全く違いそれぞれに合った構築・整備の方法を踏む必要があります。
hacomonoの構築・整備例を詳しく知りたい方はこちら。課題の洗い出しに比重を置いています。
かくいう私も、整備体制の違いについては漠然としかわかっておらず、整備・構築の最適解に戸惑っておりました。ですが、双方に携わりそれぞれの目的を理解することで、整備・構築の進め方を考えやすくなりました。
この経験が誰かの考え方の手助けになれば幸いです！
さいごに
株式会社hacomonoでは一緒に働く仲間を募集しています。
採用情報やhacomonoプロダクトデザインチームの詳細もぜひご覧ください！