見出し画像

Schema by Figma Tokyoに参加したので、そのメモ #Schema2022

カンファレンスに参加したので、そのメモ
→ ざっくりメモったのと、記憶にあるものだけ書いてみる。

Schema by Figma Tokyo

会場の様子


スケジュール


オープニング・キーノート / Opening Keynote

Figma / Sho Kuwamoto

  • Freeform Design × Structured Design
    Figmaは、アイディアレベルのデザインと構造的なデザインの両方をサポートしてきた。一方通行ではなく行ったり来たりするもの。

  • 3つの視点

1) Layout
・画像のありなしや垂直・水平など、レイアウトが変わる場合がある
→ たくさんのレイアウトが必要な場合、デザインシステムチームでは管理が難しくなる
→ 大きなコンポーネントの中にそれぞれのレイアウトのデザインを入れる
→ Nestingを使って組み合わせるのが1つの方法

2) Theming
・メインテーマ以外にもいくつかテーマがある可能性(ex- ライトモード/ダークモード)→ テーマの管理が難しくなる
・ヘッドレスデザインシステム → ボタンのバージョンは一つ、見た目に関してはあとからテーマを考えても良い

3) Process
・デザインシステムはデザインを効率化するもので、ドキュメンテーションやプラグインなども含まれる
・チームが大きくなるとプロセスが崩壊されてしまう → コミュニケーションが重要になってくる
・例えば、デザインシステムチームが20人だった。1日に1〜2回変更を加えてる→それくらいのスピードだったら、誰が何をやってるのか把握できない→明確なプロセスが必要→デザインでもテストを行なって、ユーザーより早く気づくことが大事

  • デザイナーを型にはめない。型にはめてしまうと自由にデザインができなくなる

  • 過去のデザインシステムは複数の人が作業する時に間違えないように作られていた。
    → これからはデザインの摩擦(friction)を減らすという考え方でやりたい。
    デザイナーをより自由に、よりクリエイティブにしていく


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

Fujitsu / Nana Yokota, Noriyasu Vontin

  • 社会問題解決とデザインシステムって関係あるの?
    → 社会課題解決の仕組みと、デザインシステムに共通するオープン化の重要性

  • デザインの対象領域が広がり、さまざまな課題解決にデザインが使われている
    インハウスデザイナーにもとめられること

    • 製品デザイン

    • 企業のデザイン

    • マインド変革のデザイン

  • インハウスデザインの幅が広くなったが、日常生活がデザインの力で良くなったと市民として実感がない
    → デザインアプローチを用いた社会問題起点で…

  • 取り組み事例を紹介

    • JEITAデザイン委員会 / 産官学連携

  • デザインシステムはデザイナーだけのものではない

  • 約8年前にV1のデザインシステムを作った。

    • 今はV4開発中

  • デバロッパーを巻き込んでのデザインシステムの構築

    • 共通言語化: (デザイナー不在でも)デベロッパーが使えるようにする
      →意味がわかり、判断しやすい

    • 社内に浸透: 積極的に使ってくれるデベロッパーを増やす

    • 発信型・参加型の巻き込み

      • 発信型 - 認知を広げる

      • 参加型 - 開発プロセスに参加しやすくするためのタッチポイント作り


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

Yahoo / Takanori Hirohashi

  • ヤフーには社外向きだけ50近くのサービスがある

    • それらを支えるために400人近いデザイナーが描くサービスに所属

  • 組織に基づいたFigma体制

    • 基本的には総括本部 / さ^ビスごとの縦割り

    • FigmaもサービスごとにTeamsが存在

      • Teams: 約50, Editor: 約350, Member: 約2000

  • 前者横断デザインシステムの目的

    • 誰でも簡単にYahoo! JAPANらしい高品質なデザインを行えるためのデザインシステム

      • 目的

        • UIデザイン品質向上

        • デザイン業務効率化

  • デザインシステム誕生の背景

    • デザインシステムが誕生する前は異なるサービスで同一機能のUIを個別に用意している状況だった → この重複リソースを省力化できないか、まさに「車輪の再発明をやめよう」と思い、全社横断デザインシステムチームを発足

  • 全社横断デザインシステムを支えるメンバー

    • 13名(主務1名・他は兼務):かなり少ない人数で、兼務多い

      • Style Guide

      • Design Kit

      • Dev Kit

  • 運用する中での課題

    • 全社横断デザインシステムの普及率が低い

      • これまでも存在していたが、基本的に利用は任意だった

      • 約50あるサービスごとにルールやデザインシステムがすでに存在していた

    • 運用にかけられるコストに制限がある

      • 基本的に兼務メンバーで構成された組織かつ少数メンバーで運用

      • 兼務業務にあたるため基本的には約20~30%しか割くことができない

  • 全てのサービスに一気にアプローチすると莫大なコミュニケーションコストがかかる→ 良くない

  • 実際には運用メンバーが所属するサービスを中心に導入提案を実施

    • その中で連携してくれるサービスからミニマムで実績作り

  • 実績を用いて新たなサービスに提案することで、徐々に普及率を上げていくことができた。

  • コミュニケーション不足によって発生していた問題

    • サービスごとの得時の仕様やルールが存在しているが、全社横断デザインシステム側はそれらの仕様を把握できてなかった → そのため密なコミュニケーションを取った

      • MTG

        • その場で各サービスの問題を共有

        • その場で仕様の方向性も決める

      • Chat

        • 1つのチャンネルでコミュニケーションをすることを徹底

        • 課題や議論がオープンになり、デザインシステムの活性化に繋がった

  • ペアデザイン(参考リンク

    • 2週間のマイルストーンで1タスクを完了させるスケジュール

    • 主務の業務状況によってデザインシステムに割くリソースを確保できない

    • ペアデザインを活用し一気にタスクを消化

  • ペアデザインを実施する際、徹底してること

    • 事前に作業方針やまとめ方を説明しておく → 短時間で共通認識を持って素早くデザインを行うことができる

  • 作業している人の画面を共有する

    • 工程まで見ることで技術向上・作業の出戻りを少なくする

  • 結果

    • Good

      • **ミニマムな実績作りから、10を超えるサービスに導入済み **

      • 密なコミュニケーションから、課題を迅速に吸い上げ、改善に役立ってる

      • ペアデザインを活用することで、タスク達成率が大幅にアップ

    • Next Step

      • 数値影響の下捻転などから改善したものがサービスに採用できなかった場面が発生
        - → もっと気軽に導入検討できるためのABテストのような仕組みの導入を検討

      • 退職などの理由でメンバーが抜けてしまう
        - 連携サービスで実際に活用してるメンバーを中心に全社横断デザインシステムの運用の協力を依頼

        • お互いの仕様を把握しているのでよりスピード感ある開発体制が見込めるため

  • 全サービス/プロダクトが全社横断デザインシステムを利用でき、全メンバーでPDCAを回していくことがデザインシステムチームが目指す姿

  • Tips

    • 複数サービスをまたがるデザインシステムになればなるほどコミュニケーションが重要になる → いかに効率良く課題やニーズを吸い上げられるか、開発スピードを落とさない運用フローが重要になってくる

  • Figmaを活用してチャレンジしたいこと

    • デザインシステムを利用することで何の効果が数値的に現れたか、デザインがどう貢献できたかなどを可視化


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

SmartHR / Masanori Ueda

  • SmartHR Design Systemとは?

    • ウェブサイト:https://smarthr.design/

    • GitHubリポジトリ:https://github.com/kufu/smarthr-design-system

  • "デザイン"のためじゃないデザインシステムとは?

  • 良くある誤解①

    • ❌ デザインシステムは「デザイナーの生産性」をあげるためのツール

    • ⭕️ デザインシステムはデザインとエンジニアリングが不可分であるプロダクト開発において生産性を向上するための手段

  • プロダクトデザイナーには「開発者」としての責任がある

  • プロダクトデザイン文脈のデザインシステムが始まったきっかけ

    • 昨日の拡充や事業拡大などプロダクト開発をスケールする上での強い課題感があった

      • プロダクトデザイナーが4名 (2020.5頃)で、当時もレビュー会やナレッジ共有会はあったが、スケールにともない意図や文脈の説明にコストがかかりそうという課題感があった

      • レイアウトのガイドラインや説明的なコンテンツをつくらねばプロダクト開発の障害になりかねないという危機感から、デザインする上でのルール作りを検討していた

  • 完璧な機能を作り切ってからリリースしているわけではない → ユーザーにとって価値がある最小単位で段階的にリリース

  • デザインシステムは「開発者」に何をもたらすのか?

  • 良くある誤解②

    • ❌ デザインデータがガイドライン通りになっていないと"デザインシステム警察"が来る

    • ⭕️ 妥当な意思決定を早めるための補助線であって、法律ではない。意思決定は現場での判断に委ねられる

  • 開発チームがどのようにデザインの妥当性を判断するか?

    • ボタンのラベルの書き方はどれが適切?

    • プルダウンに表示するアクションの順序は?

  • 自分が考えた最強のUIをみんなで出し合う「モブデザイン」

    • デザイナーを含む開発チームのメンバーでデザイン作業を同時に行う

  • 開発チームでの「モブデザイン」をするメリット

    • デザインの根拠や思考の過程を発露・共有しやすい

      • なぜそのデザインになったか、どうしてその選択をしたかを言語化しやすい

    • デザイナー以外でも「デザイン」を自分ごととして認識しやすい

      • デザインをデザイナーだけの 関心事としてではなく、参加した全員が、自分ごととして考えられるので、共通認識を作りやすい

    • さまざまな職能の観点を取り入れることができる

      • デザイナーだけでなく、エンジニア・ QA・UXライター・PdMなどさまざまな観点で意思決定に関わることで、観点漏れを事前に防ぎやすい

  • SmartHR UI : Figma

  • モブデザインの生産性を向上するデザインシステム

    • 中間成果物(デザインデータ)を素早く作成する

      • コンポーネントや基本的なレイアウトがデザインシステムのリソースとして用意されてるので、議論をしながらリアルタイム作業しやすい(Figma)

    • 本質的な議論に集中できる

      • 基本的なデザインパターンが用意されているため、大まかな部分はガイドに従って組み合わせることができ、本質的な部分に絞り込んで議論しやすい

    • 非デザイナーがデザインに参加するハードルを下げる

      • ガイドやリソースが誰でも利用できる状態なので、非デザイナーでも参入しやすい

  • この規模のデザインシステムをスケールし続けられる秘訣は何か?

  • 良くある誤解③

    • ❌ デザインシステム専任のデザイナーがオーナーシップを握って運用・管理してる

    • ⭕️ 特定の誰かがオーナーシップを握っている訳ではなく、プロダクト開発の各担当者が問題ベースで検討・議論を主導し反映する

  • まとめ

1.プロダクト開発のフェーズで課題となっている部分から小さく積み上げよう
![IMG_6537.png](https://image.docbase.io/uploads/80adb70e-73ee-48da-9b9a-3e09e2c6ac37.png =WxH)

2.開発者がデザイン業務を行うためのハードルを下げよう

3.開発者がデザインシステムに参加するためのハードルを下げよう

  • デザインシステムはプロダクト開発の生産性を高め、顧客に素早く価値を届けるための手段


18以上の製品を持つブランドハウスにデザイントークンを展開する方法 / Rolling out design tokens to a branded house with 18+ products

Atlassian / Deborah Lindberg, Lewis Healey

18 + Products
20,000 Ecosystem Vendors

  • カラーシステムの課題

    • 十分なカラーオプションがなかった(ex - ダークカラー/ダークモード)→ 新しいカラーを追加することで解決

  • 結論 → Design Tokens

    • デザイントークンで決めて、あとはモードを追加するだけ(ポケモンモードはおもろい)

  • パーフェクトなネーミングルールはない

  • デザイントークンの理解度の差を埋めるため、独自のプラグインを作ってFigma Tokenを使うより50%速度アップした

  • 独自のAtlassian Design Token pluginを作るのすごい

The system is only as good as its adoption.


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

note / Tatsuya Sawanobori

  • あなたのデザインシステムの「ターゲット」は誰?

  • わたしたちのデザインシステムは「社員」を助けます

    • Designer, Engineer, Director, PR, Marketing, CS, PMなど

  • どう取り組んだか

  • デザイントークン

  • アクセシビリティの向上を目指す

  • Token - Color → Designer, Engineer

    • 結果と期待される効果

      • 開発コミュニケーションの削減

        • プロセスの変化を観測

        • インタビューなどからペインの確認

      • 色の亜種が生まれない

        • コードレベルでの観測

        • デザイン時のAliasを利用していないケースの観測

  • Voice & Tone → PR, Director

    • 巻き込めてVoice & Toneは作れた → ただ、当事者だけでは完全に機能しなかった

    • 巻き込みは必要とする人だけでは足りない

      • 必要とする人以外の認知も重要

      • プロセスも開示していくことで防げたかも

  • 結果

    • 具体の活用やストーリーを重視する

      • こう使うというストーリーをい意識

      • 真似してもらうことから始められる

  • Palette → Employees

    • デザインシステムの命名は社内公募 → 寿司と肉は人を大きく動かすことができる

  • まとめ

    • 早く価値を提供し、新しい課題をみつける

      • 100点取って次に取り込むだと遅い

      • 10点でも良いから広さを取る

    • 巻き込んで広げる

      • 適切な人を巻き込む

      • 当事者以外にも広く伝える


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

TeamLab / Sukeharu Ito

  • Artで有名なチームラボだが、Solutionの方が規模が大きい

    • 人数700人 / 案件数100件以上 / 制作App1億DL

開発フロー
チームラボはエンジニアが多い
  • デザインのシステム化 / Systemization of design.

  • デザインシステム、必要なのでは?

    • 各案件に同じ部分がある → 例えば、ログイン周り、管理画面周りは共通で使えるのでは…?
      → 提供するUXによって画面も変わってくる。Atomic DesignのLv.1くらいしか再利用できない
      → 似ている、しかしちょっと違う。(機能、役割、世界観‥)その細かい違いが、クオリティにつながる。→ やるしかない!結果teamLab Design System は、できないと悟った。
      → プロジェクト毎に0→1でデザインシステムを作り続けている。

車輪の再発明!
  • 思考の体系化。

    • デザインを考える思考プロセスの汎用化。

    • 原則→パターン→設計→ナレッジ化

  • 原則:ユーザーのための体験を考える

  • パターン:「ユーザーの欲求」「を満たす手段」「を使うときに考える事」

  • 設計:体験、機能、情報、レイアウト、UI

  • ナレッジ化:過去の経験を次の制作につなげる

終わり

#Schema2022

ノベルティ


トートバック、めっちゃ好きな色で嬉しい〜サイズも結構大きくていろんな場面で使えそう!
缶バッジももらえた。一人に一つと言われ、Designerを選んだ!
Tokyoピンバッジ。トートバックにもついてたけど、微妙にデザイン違う!

当選して本当によかった!
色々と考えさせられました。勉強になりやした! 小さなところからしっかりしていこうって思ったわ。

この記事が参加している募集

この記事が気に入ったらサポートをしてみませんか?