デザインシステムを持たない組織のこれまでの取り組みと今後を考える

2019年9月19日に開催された React.js meetup #9 の登壇資料です。

📝 note のフォローアップ記事にトーク内容をまとめています。
https://note.mu/featherplain/n/n4aa45eb267b6

デザインシステムを持たないキッチハイクが、プロダクト開発においてどのような取り組みをしてきたのかをテーマにお話しました。これまでの取り組みを踏まえて、デザインシステム検討のタイミングも考えてみます。

Transcript

1. 2019.9.19 React.js meetup #9 株式会社キッチハイク 羽野めぐみ デザインシステムを持たない組織の これまでの取り組みと今後を考える
2. 羽野めぐみ @featherplain デザイナー 自己紹介
3. キッチハイクチームについて 2019 2人 8人 デザイナ + エンジニア 体制 エンジニアもUIデザインをするフェーズに 2017 ~ 2018 1人 7人 デザイナ + エンジニア 体制 React 導入開始・React Native でアプリ開発開始 2016 ~ 2017 1人 4 ~ 6人 デザイナ + エンジニア 体制 プロダクトはwebのみ・Reactレス時代 創業 ~ 2015 デザイナレス時代 プロダクトはCTO含め2人のエンジニアで開発
4. 2名 2019年 ついにデザイナ 体制に デザイナ1人に対して エンジニアが複数名いる状態が続いた
5. 今日のテーマ
6. デザインシステムを 持たずにどのような 取り組みをしてきたか 今日のテーマ デザインシステムを 持つべきタイミングを 考えてみる これから これまで
7. その前に
8. デザインシステムとは
9. デザインシステムとは すべて含んだ ユーザーに一貫した体験を届けるために 必要なものを 存在
10. デザインシステムとは 一部でしかない コンポーネントカタログや、 スタイルガイドは 同じ意味で語られがち
11. 実装 形状 原則 形状をコードに落とし込むための アプローチが具現化・言語化されている デザイン原則を形状に落とし込むための アプローチが具現化・言語化されている ユーザーに提供したい価値を言語化している デザインシステムを支えるもの 抽象 具象
12. 何をもたらしてくれるの？ 「良い」 評価基準が明確になる ブランド・アイデンティティの確立や認知 デザイン・実装コストの削減 ユーザーの認知負荷の削減 チームのベストプラクティスを凝縮
13. キッチハイクはどうなの？ どうやってベストプラクティスを 構築していったのか？
14. 前編 キッチハイクの取り組みと ワークフロー
15. 2016 ひとりめのデザイナとして本格参入 Ruby on Rails React レス( Backbone.js ) プロダク トは web だけ エンジニア デザイナ
16. 当時のワークフロー 2016 エンジニア UI 設計 UI コーディング 組み込み モデル設計・ルーティング設計 Sketch Haml・Sass・Javascript 組み込みの一部をデザイナが担当することもあった フロントエンドの作業領域は分担していた デザイナ
17. リリースこそ正義 チームビルディングもしつつ とにかく早くアウトプットする
18. 2017 ~ 2018 エンジニアが 6 ~ 8人に増えた エンジニア React Native でアプリ開発 React 導入 デザイナ
19. 2017 ~ 2018 エンジニア デザイナ 当時のワークフロー UI 設計 UI コーディング 組み込み モデル・API 設計 Sketch serverside view デザイナはコードに コミットしないことが増えた
20. 当時のチーム状況 きれいな構造でつく るよりも、 ユーザーに届けるのが最優先 ゼロイチで開発 デザイナ含めてアプリ開発経験者がいない だれもReactを触ったことがない 2017 ~ 2018
21. リリースこそ正義 チームの成熟度向上が優先 ベストプラクティス構築期間
22. ここまでのまとめ デザインシステムをつくれるだけの 土台がなかった
23. 後編 キッチハイクの取り組みと ワークフロー
24. キッチハイクに新たな概念登場 コンポーネント指向 Reactベースの開発...それは即ち と向き合うこと
25. チームにおける課題 いかに効率よく実装するか？ コンポーネントの粒度をデザイナとエンジニアで どう統一見解を持つか
26. 統一された仕組みの中で UI カタログとコードが 参照できる Storybookの導入も検討 デザイナが直接コードを 触ってリアルタイム 変更できる 誰がメンテナンス するのか？ ワークフローに組み込む コスト 期待したこと 課題
27. ここで、 話題を少し変えます
28. デザインの共有プロセス の煩雑化 同じ頃、 デザインツールをFigmaに移行 Sketch はデザインが 閉じがちになる デザインリソースとして 機能させたい チームでデザイン するための ハブとして機能させたい 課題 ゴール
29. UIカタログ view全体 デザイナ UI 設計 Sketch エンジニア UI コーディング 組み込み モデル・API 設計 serverside view デザイナはコードに コミットしない 移行前のワークフロー
30. デザイナ エンジニア UI 設計・更新 view全体・UIカタログ・スタイルガイド デザイナはコードに コミットしない 移行後のワークフロー UI コーディング 組み込み モデル・API 設計
31. Figma移行によるインパクト Single Source of Design 事実上、 信頼できる唯一のデザインリソースと化した
32. デザイナがつくったUIを指標に、 エンジニアが設計を担う コンポーネント設計どうしてる？ Storybookは見送り、 Figmaを指標とする ただし、UIのレベルデザインに厳格に適用しない 共通概念 Atomic Designを として取り入れた
33. キッチハイクの特性を生かしたワークフロー いつも本当に助かってます＞＜ エンジニアもデザインに対して理解・興味を 持ってくれている 最近はReactの概念も共通言語になりつつある デザイナがある程度コードが書けるので、 エンジニアと同じことばで会話できる デザイナは設計や体験のデザインに注力したい
34. ここまでのまとめ コンポーネント志向とワークフローに 向き合った結果、 デザインツールによる仕組み化に成功
35. キッチハイクのこれから
36. デザイナとエンジニアをつなぐものはできてきた いかに効率よく実装するか？という視点 これまで 実装 形状 原則
37. デザイナがひとりの組織 デザイナのスキルや特性・リソース配分によって ワークフローが変わる その代わり、 デザインが属人化しがち デザイナ自身が single source of design の役割を担う
38. チーム全体の生産性・実装力があがった エンジニアも UI デザインをするフェーズに デザイナがカバーできる生産性を越えつつある 最近のチーム体制
39. あるエンジニアの一言 自分の中で言語化はできていないけれど デザイナが大事にしているものは 何となくわかります
40. いまのキッチハイク デザイナ エンジニア 少人数かつ守備範囲の広さゆえの 「いい感じ力」
41. デザイナがさらに増えて、 組織がより拡大したときが検討のタイミング デザインシステムはまだ必要ない
42. デザイナとデザイナをつなぐものが必要になる デザイナにとっての地図・コンパスを構築するフェーズ これから 形状 原則