見出し画像

半熟デザインシステム vol.1 共催レポート

Ayumi Kumano

この記事は2024年4月24日に開催された半熟デザインシステム vol.1の座談会で話した内容をもとにしています。

半熟デザインシステムは、half-boiled（半熟）なデザインシステムを持つ企業が集まってデザインシステムの構築・運用に関する悩みやナレッジを赤裸々に語り合うイベントです。

第1回の今回は、Ubieのデザインシステムを紹介＆Ubie、note、ROUTE06、Wantedlyの4社でデザインシステム運用についてのリアルな悩みや工夫について語り合います！

https://ubie.connpass.com/event/314434/

共催レポートに入るまでの前置きが長くなります。いち早く読み進めたい方は、🍳 いざ、半熟デザインシステム vol.1 開催の部分まで読み飛ばしてください⏩


💔 「デザインシステム」と名乗ることへの躊躇

「デザインシステムって何?」「デザインシステムを作ると何がうれしいの?」とデザイナー以外から聞かれたことはありませんか?
もしかしたら、デザイナー同士でもそんな会話をする経験がある人がいるかもしれません。
作っているものは多分デザインシステムだけど、いまいち「デザインシステム」と名乗るのが恥ずかしい気持ちがありました。
「デザインシステム」というキーワードで検索すると、既に世に広く公開されている著名なデザインシステムに辿り着くはずです。
デザインシステムの目的は公開して人目を引くことではありませんが、そこまで到達しないとデザインシステムと名乗るのは恥ずかしいのではないかと感じていました。
今まさに目の前のプロダクトに対して質の高い一貫性のあるインターフェースを作ろうとしているけれども、もしかしたら同じようにデザインシステムを作っていると名乗るのに気が引けるような感情を持っているかもしれない全ての人たちに向けて、この記事を書こうと思います。

🧊 Plain UIというデザインシステム

前述のようなモヤモヤを抱えつつ、ROUTE06では2023年6月から2024年3月までPlain UIというデザインシステムの構想から構築・運用に携わっていました。

Plain UIは顧客へ提供するプロダクトのUIを自由にカスタマイズ可能な状態にしたいというデザイン面への要望を叶えるデザインコンポーネントライブラリとして構築をスタートしました。
ベースとなるコンセプトデザインを作成してからUIデザインのカスタマイズを進めていくことを前提としていたため、一般的なデザインシステムと比較するとPlain UIは可能な限り「らしさ」を削ぎ落としたスタイリングをしていくことをコンセプトとしていました。

ROUTE06は創業以来、顧客やプロジェクトに合わせて毎回スクラッチでプロダクトデザインや開発を行っていました。
プロジェクトの数が増えるたびに作るべきプロダクトデザインやコードは増えていきました。
プロジェクトチームのメンバーに合わせて採用される技術スタックが異なるように、フロントエンドのフレームワークやUIライブラリのアーキテクチャもプロダクトごとに異なり、デザイナー観点で見ると過去に作ってきたプロダクトのデザインデータの命名方法やコンポーネントの整理方法では新しいプロダクトには適さずルールを都度変えていく場面に遭遇しました。

「デザインシステム」という言葉には標準の定義があるわけではなく、様々な用途で使用されています。
デザインシステムの基礎はパターンと慣習です。
Plain UIで行おうとしていたことは、「プロダクトのUIを自由にカスタマイズ可能な状態にする」ためのデザインパターンを作り、そのデザインパターンのカスタマイズ方法についてPlain UIを作っているチーム外のデザイナーにも「慣習やデザイン原則をハンドオフする」ためのガイドラインやオンボーディングプロセスをドキュメンテーションすることでした。

🤝 チームビルディング

デザインシステムチームは、リードの自分を含め専任のメンバーはおらず、進行中の他のプロダクト開発も担っているデザイナーとデザインエンジニアで構成し、社員だけでなく、フリーランスやデザインインターンなどの業務委託のメンバーにも関わっていただきました。
コンセプトデザインをもとにスタイリングをカスタマイズするのはデザインシステムを構築するメンバーに限らないため、デザイナーからデザイナーへのハンドオフをいかに上手くやっていくかを意識し、最初から属人性を排除して、今いるメンバーが誰一人いなくなったとしても運用が回ることを目指していました。
そのため、意図的に知見の深さに偏りのあるチームメンバーの配置や入れ替えを行い、自分自身もチームのリードを交替するという選択を取りました。

🎨 デザインシステムの構築プロセス

全くのゼロベースからデザインシステムを構築したわけではなく、既存のプロダクトで実績があり、かつフロントエンド側でもアーキテクチャとして再利用を想定しているプロダクトデザインのUIコンポーネントをベースとして、デザインシステム用のコンポーネントライブラリやデザインパターンを構築していきました。

📚 デザインシステムの構成

滞りないハンドオフを目指していたため、ドキュメンテーションは特に時間を掛けた部分となります。Plain UIのデザインシステムは以下のような構成で構築していました。

  • Figmaのデザインデータ

    • コンポーネントライブラリ

      • コンポーネント集

      • Storybookへのリンク

      • UIフレームワークのドキュメントへのリンク

    • ページパターンライブラリ

      • コンポーネントを利用して形成されるプロダクトドメインに紐づいたデザインパターン集

  • GitHub上のドキュメント

    • Introduction（オンボーディングガイドライン）

      • 実際にデザインシステムを利用してプロダクトのデザインをしていくデザイナーに向けた、デザインデータの場所の説明・セットアップ方法・デザイントークン利用前の環境構築のプロセスをまとめていました。

    • デザインガイドラインの書き方

      • 誰が書くのか、誰がレビューするのか、ガイドライン中の画像の形式・圧縮ルール・命名ルールなどを記載していました。

    • ADR(Architecture Decision Record)

      • デザインデータの作り方やドキュメンテーションの方針など、デザインシステム構築における方針の変更の意思決定のログを残しています。

      • 意思決定について提案・承認・棄却などの状態を管理可能となるため、デザインシステムの運用にとても効果的な方法です。

    • Design Tokens

      • デザイントークンについての説明・設定方法・参照情報やカスタマイズ方法などを記載していました。

    • Component Library

      • Figmaに存在する各Componentのデザインガイドラインを記載していました。

    • Pages（画面仕様書）

      • プロダクトドメインに紐づくページパターンライブラリの画面仕様書の他、ユーザーフィードバックの定義など全体に関わる仕様もここに記載していました。

    • Figmaの命名規則

      • UIフレームワークのPropsなどで定義している命名を再利用するなど、実装コードベースに命名を揃える方針を取っていたため、コンポーネント名だけでなくVariantの命名規則も設けていました。

ある程度基盤が整ったところでしたが、社としての方針転換や組織改編に伴い、冒頭で記したとおり2024年3月でPlain UIという名前でのプロジェクトはアーカイブとなりました。

そんな折、以前デザインバトルイベントKODで共催していただいたUbieのtakanoripさんの以下の投稿をデザインシステムのチームメンバーから教えてもらったことがきっかけで、手を挙げさせていただき半熟デザインシステムのイベント共催の運びとなりました。


🍳 いざ、半熟デザインシステム vol.1 開催

❤️ Ubie Vitalsの発表

当日のイベントでは、Ubieさんのデザインシステム「Ubie Vitals」に業務委託として参画されている腹筋さんより、Ubie Vitalsの取り組みについて発表がありました。
Ubie Vitalsの出現と失敗・再始動や具体的な施策について紹介されているので下記のスライドは必見です！

🪑 座談会

「Ubie Vitals」の発表の後、Ubieのtakanoripさん、noteのuto-usuiさん、Wantedlyのtomoさんと共に座談会を行いました。

📸 当日の様子

Xでの #半熟デザインシステム でのポストがTogetterにまとめられています。 noteさんによりスポンサードされた会場のnote placeがとても素敵で、楽しく参加させていただきました！

テーマ① デザインシステムを始めたきっかけとチームビルディング

Ubie: takanoripさん

  • きっかけ

    • Ubie Vitalsの発表にもあったように、人員増加に伴いプロダクトが複雑化し、効率化や構築手法の統一化のニーズが高まったことがきっかけとなった。

  • チームビルディング

    • 当初は社内のメンバーが兼業でデザインシステムに取り組んでいたが、進捗が芳しくなかった。

    • 業務委託として、Ubie Vitalsで登壇した腹筋さんが参画。

    • 正社員のtakanoripさんは、主に社内調整や指標作り、社内浸透に注力。

    • 実際のコーディングやドキュメント作成は、主に業務委託の方が担当し、正社員と業務委託が二人三脚で推進した。

note: uto-usuiさん

  • チームビルディング

    • 現在はusuiさんが専任で取り組み、デザイナーは業務委託で参加している。

    • 発足時当初は様々な職種(ブランドコミュニケーション、イラストレーターなど)が参加し、どのように進めるか話し合った。

  • きっかけ

    • 技術的・デザイン的な負債が溜まり、開発が難しくなる状況にあった。

    • マークアップできるデザイナーの退職で、エンジニアがコーディングしやすいルールが必要となった。

    • noteのリブランディングに向け、変数などで簡単に変更できるデザインが求められそうと予想していた。

  • ベストプラクティスの共有と、プロジェクトへのフィードバック方法が課題だった。

    • 定例では週30分の雑談の時間を設け、質問や相談を受け付けている。

    • 自分が関与していないプロジェクトの定例にも参加し、デザインシステムの状況を説明している。

  • 新しいUIは"赤ちゃんUI"ページに集約し、名前も未定のものもある。

  • 一定期間でFigmaファイルを新しくし、古いファイルはアーカイブしている。

    • マスターデータは持たず、プロダクトデザイナーが新しいデザインをここに集約する。

ROUTE06: ayumiko

  • きっかけ

    • トップダウン。新規プロジェクトごとにスクラッチで開発するのではなく、一定の型をベースに展開することが指示された。

    • デザイナー間でコンポーネントの作り方に違いがあったため、デザインの共通認識を持つ必要があった。

    • そのため、コンポーネントライブラリ、デザインガイドライン、ドキュメンテーションの作成と、それらの活用を集約した結果、デザインシステムが生まれた。

  • チームビルディング

    • 様々なバックグラウンドを持つデザイナー・デザインエンジニア(社員、インターン、フリーランスなど)を交えた。

    • デザインシステムを誰でも使えるよう、オンボーディング資料の作成やオンボーディングのテストも行った。

    • チームのリードをローテーションさせることで、目的の自分事化と主体的な関与を促した。

    • 運用する人が変わっても継続して使えるデザインシステムを目指した。

Wantedly: tomoさん

  • きっかけ

    • Wantedlyのデザインシステムは2017年頃に始まったが、当時の関係者がいなくなったため、今回のイベントをきっかけに考古学的にヒアリングを行い、その経緯を掘り下げた。

    • 2012年からサービスを開始していたが、2017年までデザインシステムはなく、デザインやブランドの一貫性がない課題があった。当時のデザインマネージャーが権限を持って推進したことがきっかけとなった。

  • チームビルディング

    • Wantedlyにはデザインシステムギルドという有志で構成されたチームがあり、デザイナー、フロントエンドエンジニア、モバイルエンジニアで構成される。

  • 課題

    • 過去のデザインの意図が残っていないため、デザインシステムのルールから逸脱したコンポーネントの理由が分からず、再定義する必要がある。

    • デザインシステムには負債があり、メンテナンスコストが高い。特にドキュメント化が課題となっている。

    • ユーザー体験を重視し、一定の自由度を認めるルールがあるが、その設計を改善する際に意図が分からないことが課題となっており、現在見直し中である。

テーマ② 各社のデザインシステムの熟し方ってどんな感じ？

Ubie

「半分くらい熟してきた」
デザインシステムの理念や仕組み自体は整備されつつあるものの、実務への浸透が遅れているため、今後は関係者間の認識の統一と、ルール徹底に向けた取り組みが重要になってくる状況。

  • Ubie Vitalsを参照すれば生産性が向上するという状態には至っておらず、まだ半分程度の段階。

  • 様々なプロダクトにデザインシステムを導入している最中。

  • デザイナーへの浸透が十分でなく、UIライブラリとFigmaコンポーネントが一対一対応になっていない。

  • エンジニアがどこを見ればよいかわからない状況があり、乖離が課題となっている。

  • Figmaのデザイントークンなどのルールベースに沿ってUIを作れるようになれば、浸透や進捗が進む見込み。

  • そのためのアプローチ方法が現在の課題。

note

「熟すまでのゴールが変わった」
事業拡大に伴うデザインシステム自体のニーズの変化に対応すべく、ドメインからの切り離しを進めながら、柔軟で使い勝手の良いデザインシステムを再構築する取り組みを行っている最中。

  • noteの事業が拡大し、デザインシステムに求められる領域が広がった。

  • フェーズ2のようにゴールがより遠くなり、作業を見直す必要が出てきた。

  • 現在の取り組みとして、「note.comらしさ」の定義を行っている。

  • ドメイン知識を排除した上でnoteのあり方をデザインシステムに反映する作業を行っている。

  • 実装とデザインをべったり結びつけ過ぎるとお互いの使い勝手が悪くなる可能性がある。

  • 実装はStorybook、Figmaファイルはデザイナーの使い勝手を優先して管理している。

  • FigmaのModeなどを活用しつつ、Figmaファイルのより幅広い活用を検討中。

  • デザインコンポーネントとUIキットというライブラリがある。

  • UIキットはドメイン知識を前提とした専用コンポーネント。

  • デザインコンポーネントは汎用的で、note.comのドメイン知識を必要としない。

  • この2つの切り分けと新規コンポーネントの追加を行っている。

ROUTE06

「焼き方のオーダーが変わった」
事業の方針転換に伴い、当初のアプローチからの大きな転換を余儀なくされたが、これまでの資産を最大限活かしつつ、よりドメイン非依存の形でデザインシステムの再構築を進めている状況。

  • 約9か月前にチームを立ち上げ、最初の半年間はデリバリーを目的にデザインシステムの構築を進めた。

  • その際、ドメインとの密接な関係性やエンジニアリングを意識した作り方をしていた。

  • しかし直近3か月で事業の方針転換があり、チームを一度解散し、再構築する事態となった。

  • 現在はドメインからの切り離しを進めており、目標が大きく変更された。

  • これまで構築したものをベースにしつつ、より異なるアプローチでデザインシステムを再構築中。

  • 最終的な目標(デザインシステムを活用したデリバリー)自体は変わっていない。

  • Plain UIについてもゼロベースから作られたわけではなく、既存のプロダクトをベースに洗練させたもの。

  • そのためコード、Figmaデータなどの資産が既存プロダクトには引き継がれている状態。

  • 新規コンポーネント作成時も、これらの資産が参照・活用されている。

Wantedly

「まだ完熟していない」
これまでのデザインシステムの構築は一定の成果を上げてきたものの、実装への展開が十分でない点や、ドキュメンテーションの不足などの課題が残されている。今後はこれらの解消に注力。

  • 2017年頃からデザインシステムは存在していたが、2020年にSketchからFigmaへ移行した

  • 現在はまだVariableやコンポーネントプロパティの適用が大半できていない状況。

  • 実装面でも、デザインを100%実装できていない。

  • ユースケースのないコンポーネントが一部存在する。

  • 実装に反映されていないUI コンポーネント/パターンが残存している。

  • デザインと実装の100%の一致を目標に掲げている。

  • デザインシステムの設計思想や、デザインの理由を明文化することを検討中。

  • ドキュメンテーションの充実化を進める予定。

  • プロダクトのデザインシステムとブランドのデザインシステムが同一のものとして機能している。

  • ブランドカラーやUIパターンなどが一つのデザインシステムに統合されている。

テーマ③ 組織、他チームへの説明の仕方、予算の取り方ってどうしてる？

Ubie

  • デザインシステム単体ではリソースを十分に確保できていなかった。

  • デザイナーやデザインエンジニアはプロダクト開発業務が最優先で、デザインシステムはサイド業務的な位置づけだった。

  • スタートアップとして収益確保が最優先課題だったため、リソースがデザインシステムに回りにくい状況にあった。

  • 最近になり組織やプロダクトが大きくなり、生産性向上の重要性が高まってきた。

  • 生産性を向上させればさらなる収益確保につながるという説明で、デザインシステムの必要性が認知されるようになった。

  • しかし半年近くデザインシステムの効果が実感できない状況が続いた。

  • 2023年4月から6月の3ヶ月で成果が出ない場合、業務委託の見直しやデザインシステムへの投資自体を断念する可能性がある。

  • スタートアップにとって収益確保が命題であり、生産性向上によるメリットを具体的に示す必要がある。

note

  • デザインシステムの予算確保について、デザインシステムは必要不可欠なものとして認識されている。

  • noteのプロダクトは長年運用されており、技術的な負債が蓄積している状況で、新しいフレームワークへの移行やコンポーネントの開発が必要とされている。

  • デザインシステムチームの貢献により、これらの課題に対応することができている。

  • また、過去のイベント登壇がきっかけでインターンが参加するなど、人材の獲得にも繋がっている。

  • アサインされたデザイナーの退職があった場合にも、業務委託で対応することができた。

  • 今後は、アプリとWebの親和性を高めるためのプロジェクトや、Figmaファイルの効率化など、デザインシステムチームが担える部分を巻き取っていく予定である。

  • デザインシステムチームの存在意義は継続していくと見込まれる。

  • 一方で、デザインシステムの成果の測り方については課題がある。

  • 定量的な評価が難しい領域であり、各チームからのフィードバックを収集するなどの方法しかないのが現状。

  • 過去には、生産性向上をデザインシステムチームの目標に設定し、タスク管理にチェックマークを付けるなどの工夫をしていた時期もあった。

ROUTE06

  • もともとトップダウンで行われていた背景があり、予算は確保されていた。

  • 関係者に対してデザインシステムとは何かという基本的な説明から始める必要があり、理解を深めていく必要があった。

  • デザインシステムについて様々な人から質問をうけるたびハンズオンでFigmaを見せて説明する時間を要しており、工数が重なっていった。

  • デザインシステムについてドキュメント化することで、デザイナー間、デザイナーとエンジニア間、対組織へのハンドオフ時にドキュメントを元に説明することが可能となる為、ハンドオフの対応から属人性を排除させることを目指した。

  • デザインシステムの導入によって生産性が向上することを説明していたが、具体的な効果を示すことが求められている。

  • 手離れの良さや、コミュニケーションパスが通っていなくてもドキュメントを参照することで情報を得られることなどを、デザインシステムの効果として考えている。

Wantedly

  • デザインシステムの導入は、デザインマネージャーやCTOなどのメンバーが主導で始めた。

  • 代表自身もデザインに対する理解が深く、デザインマネージャーやCTOの権限を活用してデザインシステムを作ったと推測される。

  • 現状、デザインシステムの保守管理には予算が確保されておらず、有志で集まって週1回のSync Upなどの定例会を行っている。

  • しかし、メンバーのメインの部署のタスクが優先されるため、デザインシステムの保守管理は優先度が下がり、ドキュメンテーションやFigmaの定義の整理などが鈍足になっており、課題となっている。

  • 代表自身がプロダクトのUIを作成する際にデザインシステムを使用しており、アセットの使いづらさについてフィードバックがあった。

  • 代表自身がデザインシステムの改善の必要性を感じているため、今後予算を確保してデザインシステムをアップデートし、改善していくプロジェクトが立ち上がる可能性もあるかも…？

最後に

座談会後の懇親会ではたくさんお声がけいただき、感無量でした。
プロジェクトとしては一旦アーカイブになったものの、チームでデザインシステムを構築していくプロセス自体が自分としても組織としても代え難い価値やナレッジとなったので、それをシェアしないまま過去のものとすることになるのはとても残念だと感じていました。
イベントに参加してくださった方々に何かナレッジをお土産として持ち帰っていただけたなら、今回共催で参加させていただいた一番の成果になったのではないかと感じています。

半熟デザインシステムのイベントは今後もvol.2なども開催されるかもしれないので、主催のUbieさんの今後の展開も目が離せません。
この記事が気になった方はUbieさんのconnpassをフォローしていただくのがオススメです👍️

ROUTE06としても自分はPlain UIから次のフェーズに移り、絶賛開発中なので引き続き頑張っていきます💪


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