🤖
Frontend Talk 〜デザインシステム構築のリアルな裏側〜【hey｜note｜ANDPAD】
概要
2022/03/10に開催された下記勉強会のメモです
こちらに書き起こし記事があります
セッション
ヘイのデザインシステムの今までと現状 〜FE、Deの領域を溶かしていくこと〜
- 複数サービスのブランド統合によりデザインリニューアル
- プロダクトでフレームワークが異なる
- tailwindcssを起用
- config統一で吐いたユーティリティクラスを各プロダクトで利用
- デザインシステムを磨き上げるチームを作り、事業にコミットするチームとうまく接続するようにしていく
noteのデザインシステムのはじまりとこれから
なんで始めたか
- UIの品質担保とスキルセット依存を解消したい
- 全社を巻き込んで、共通言語で話せるようにしたい
コードとデザインをつなぐ
- デザインシステムを作る
- デザイン原則
- コンポーネントライブラリ
- アクセシビリティガイドライン
- メールデザインシステム
- イラストシステム
- UXライティングガイドライン
- コミュニケーションガイドライン
- 資料まとめ（スライドテンプレ、カルチャーブック..）
FigmaとGitHub Actions連携による「コンポーネントライブラリ」更新
- デザイントークン
- Figma->json(カラーやタイポグラフィ等)->CSS props, tailwind.config, ...
- 共通アセット（画像）
- GitHub Actions->S3->Fastly
- UIライブラリ
- React Layer
- Storybook
- Tailwind CSS
デザインをみんなで使う
- みんなが使える状態を目指す
- デザイナーやエンジニアだけが使えるデザインシステムでは要件不足
- トーンオブボイス
- 公式アカウントの言葉遣いなど
- PRやディレクターチムなどとワークショップしながら決める
- イラストシステム
- レイヤーやパーツの組み合わせでイラストを生成できる仕組み
- 誰でもイラストを使える状態
- デザイン原則
- まずはステートメントを作成
- 方向性がブレないように
- 70点目指して作成、使って評価
- まずはステートメントを作成
- 共通して意識していること
- 未完成で使い始める
- みんなが使える
- かんたんにすぐ使える
参考：
noteのデザインシステムの記事
noteデザイナーマガジン
エンジニアがデザインシステム導入に取り組む際の落とし穴
デザイン共通化プロジェクトの落とし穴
- 幅広いサービスを展開しているがデザインは少しずつ異なっている現状
- デザインチーム主導でデザイン共通化プロジェクトがスタート
- 全ての問題を一気に解決しようとして、どこから手をつけて良いかわからなくなる
- デザイン共通化はゴールやメリットがイメージしやすい
- 反対意見や疑問が出にくいので細部の仕様の言語化や、中間地点の設定を省略したくなる
アプローチ
- コンポーネント共通化でなくCSS共通化
- フレームワークを選ばずに使える
- 進める範囲を再確認
- まずはフロントエンド＋デザイナーで動ける範囲に絞った
- 新規プロダクトの実装とセットで進める
- 共通CSSが導入されたページがリリースされスタートラインに立てた
アンドパッドのデザインシステムの今までとこれから
- ANDPADではエンジニアとデザイナーはそれぞれ別の部署に所属、チームにアサインされてサービスを作成
- 縦割りチームで複数プロダクトを次々に展開
- 開発コストは膨らむ一方、プロダクトの品質担保が難しくなりデザインシステムの必要性を感じた
デザインシステムの取り組み
- デザインシステムのゴールイメージや構成要素をビジュアライズ化することでデザイナー同士の認識を統一
- Miroを使って書き出し
- パターンライブラリの構成要素をビジュアライズ
- 「同じ話をしているつもりが具体的に見ているところが違った」という気付き
- 認知パターンをデザイントークンとして再定義
- 参照元となるリファレンストークン->システムトークン->コンポーネントトークン
参考にしている主なデザインシステム
Discussion