デザインシステムの有用性とは【Schema by Figma Tokyo 2022】

2022年11月2日に開催された「Schema by Figma Tokyo」に参加してきました。
普段web制作会社でクライアントワークをしている自分の日常業務にも活かせそうな気づきを色々もらえて楽しかったので、印象的な部分を備忘録的にまとめてみました。

※当日の走り書きメモをまとめた内容なので、勘違いや解釈違いもあるかもしれません！

オープニングキーノート

Figmaのショウ クワモトさんが後半に話していた下記の部分が特に印象的でした。

デザインシステムは、デザイナー同士やデザイナーと他チームが協業する上で重要なツールであり、年々その必要性は高まっている。
しかし、デザインシステムを単に「デザイン業務に規制をかけるもの」と捉えて、デザインを型にはめるものとしてはいけない。デザインから柔軟な発想や新しいアイデアを取り入れる機会を無くしてはいけない。
デザインシステムは「摩擦を減らす方法」で、デザイナーをより自由、よりクリエイティブにするもの。

まさにデザインシステムに対して感じていた、面倒臭さや退屈さのようなネガティブなイメージに応えてくれた様で、すごく印象的でした。

インハウスデザイン組織が考える社会課題解決におけるオープン化

富士通株式会社 の横田奈々さんとフォンティン徳康さんによる登壇です。
社会課題解決とデザインシステムの関係性についての内容でした。

近年インハウスデザインの幅は広くなったが、日常生活がデザインの力で良くなった実感がない。
なぜ社会課題に対するデザインの効力感がないのか、それはビジネス顧客や技術、製品起点でデザインが行われているから。
→ビジネス顧客(例：病院)が使いやすいサービス＝社会課題の当事者(例：患者)に向けたデザインではないから。

デザインをより直接的に社会課題の解決に価値発揮するため、当事者と共に取り組むためのデザインの仕組みが必要である。
社会課題の特定のフェーズから市民、行政、教育などの観点から決めたり、取り組み自体をオープン化していくことが重要である。
企業内で単一のハコモノプロダクトに閉じ籠らず、広く関係者と共に継続的なイキモノのようなサービスを育てていくことが大事。

社会課題解決の観点からデザインの課題は新鮮で、「確かに」と感じる部分も多かったです。自分のデザインが社会にどう価値を出せるか考えるきっかけになりました。

Yahooにおけるデザインシステムの運用フロー

Yahooの廣橋 孝紀さんによる登壇です。
社外向けだけでも50近いサービスを抱えるYahoo、どうやって全社横断のデザインシステムを運用に載せていくのかという内容でした。

異なるサービスで同一機能のUIを開発するという、いわゆる「車輪の再発明」を避けるためデザインシステムPJTがスタート。

【どのように運用に載せたのか】
①まず、デザインシステム制作に携わったデザイナー自身が所属しているサービスから導入＆運用実績作りを行った。
②次に、各サービスごとに独自のルールがありデザインシステムを導入できない課題に対して、週に1回必ずサービス連携担当者とMTGを実施した。
(＝密なコミュニケーションを丁寧に繰り返しすり合わせを進めた。)

【ポイント】
・活動をオープンにする
スラック上の1チャンネルで課題共有をして、クローズドなコミュニケーションに閉じないようにもした。
・ペアデザインの実施
運用メンバーでリソースが足らない課題について「ペアデザイン」の取り組みでカバー。各自設定したタスクをペアデザインによって、短時間かつ効率的に消化することでPJTを進めた。

今後はFigmaを通して、デザインシステム導入による数値的な結果、デザイナーの貢献度の可視化に取り組んでいきたい。

デザインのためじゃないデザインシステム

SmartHRの植田 将基さんによる登壇でした。
・スマートHRのデザインシステム

以下の「よくあるデザインシステムに対する３つの誤解」が、まさに誤解していたことすぎて、首もげるくらい頷いてました。

誤解①「デザインシステムはデザイナーの生産性を上げるツールではない」→プロダクトデザイナーは開発チームの一員としてインターフェイズ品質や開発活動に責任がある車輪の再発明という開発の無駄を回避し、後発の機能開発の生産性に帰結する。

誤解②「デザインガイドラインの通りになってないとデザインシステム警察がやってくる」
→デザインシステムはあくまで補助線であって法律ではない、意思決定は現場の判断を重視

誤解③「特定の誰かがオーナーシップが握って運用管理している」
→プロダクト開発の各担当者が課題ベースで検討、主導している
極めて地道な努力を重ねている

【まとめ】
・プロダクト開発の段階で課題になっている部分から小さく積み上げる
・開発者がデザイン業務を行うためのハードルと、デザインシステムに参加するハードルを下げる
・プロダクト開発の生産性を高めて顧客に素早く価値を届けるための手段ということを忘れない

開発者のためだけに作らないデザインシステム

noteの沢登達也さんによる登壇です。
pletteと名付けられたnoteのデザインシステムについての内容でした。

デザインシステムは「みんな(社員)のためのツール」だが、作成する際にどこまでをターゲットとするのかの判断は必要。
　→関係者を３段階に分け、優先順位をつけた。

関係者の巻き込みは、デザインシステムを必要とする人だけでは足りない。デザインシステムを必要としていない人にも広めていくことが重要。
→社内でブラッシュアップを進める際に周りを巻き込むための施策
　・スタンプ１つでPJTやMTGに参加意思表明ができるハードルの低さ
　・アイデアが採用されたら肉と寿司をご馳走というインセンティブ
結果：作成に関する130ものアイデアが集まった

【まとめ】
・100点に時間をかけるより10点で早く広げる
・適切な人を呼び、広く伝えることで、周りを巻き込んで広げる
・デザインシステムは持久走、焦らず届け続ける

チームラボのデザインシステムと思考の体系化

チームラボの伊藤祐春さんによる登壇です。
これまでの登壇者は事業会社の観点でしたが、こちらではクライアントワークの観点からデザインシステムを語った内容が非常に印象的でした。

【背景】
バックエンドはかなりパッケージ化できているので、その手前のデザインシステムも必要ではと思い作成を開始した。
(ECサイトを制作する際、管理サイトも共通のフレームワークに落としたりできるのではと、検討を進める)
　結果：より良いUXを考えていくと、パーツに限界がくる

同じECサイトならユーザーに対する姿勢や思想は似てはくるが、全く同じものにはならない。つまり、各所各所に至るまでの文脈(UX)が違う
　文脈が違う＝別のコンポーネントになる
　　→その文脈ごとに合わせた細かい違いがクオリティの高さに繋がる
　　　つまり、車輪の再発明をやり続けるしかない
要素の数やコンポーネントの使い回しに終始してクオリティが落ちる結果、起こるのが「手段の目的化」。これは避けるべき。
　　結論：チームラボのデザインシステムは諦めた
0→１で作り続ける、逆に車輪を発明しまくるしかないと振り切っている

「デザインシステムは諦めた」と話された時はさすがに「えー！」となりましたが、自分自身がクライアントワークでまさに同じ課題感を持っていたので逆に清々しくもありました笑
その上で、もう少し広い視点で「デザインシステム」を考える以下のお話も興味深かったです。

チームラボのデザインシステムは「思考を体系化すること」と考える
　「原則→パターン→設計→ナレッジ化」という順番で体系化する
原則：ユーザーのための体験を考えること
パターン：「ユーザーの欲求」「を満たす手段」「を使うときに考える事」
設計：体験や機能、UIなど情報の表示手段を細分化して洗い出す
ナレッジ：様々なケースでも共通な本質の普遍的な部分を蓄積していく

車輪の再発明をするしかないとはいえ、このデザインシステム(思考の体系化)を通すことで、「常に最適な車輪を発明する」という考え方。

この「時には、クオリティのために最適な車輪を再発明するという考え方もある」という結論に痺れました…

終わり

普段考えない角度からの気づきが多く参加できてよかったです。
ノベルティも色々もらえたし！

※Figmaの公式YouTubeで、皆さんの登壇内容の動画が上がっておりました！(2011/12/8現在)