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

by はのめぐみ / Megumi Hano

Slide 1

Slide 1 text

2019.9.19 React.js meetup #9 株式会社キッチハイク羽野めぐみデザインシステムを持たない組織のこれまでの取り組みと今後を考える

Slide 2

Slide 2 text

羽野めぐみ @featherplain デザイナー自己紹介

Slide 3

Slide 3 text

キッチハイクチームについて 2019 2人 8人デザイナ + エンジニア体制エンジニアもUIデザインをするフェーズに 2017 ~ 2018 1人 7人デザイナ + エンジニア体制 React 導入開始・React Native でアプリ開発開始 2016 ~ 2017 1人 4 ~ 6人デザイナ + エンジニア体制プロダクトはwebのみ・Reactレス時代創業 ~ 2015 デザイナレス時代プロダクトはCTO含め2人のエンジニアで開発

Slide 4

Slide 4 text

2名 2019年ついにデザイナ体制にデザイナ1人に対してエンジニアが複数名いる状態が続いた

Slide 5

Slide 5 text

今日のテーマ

Slide 6

Slide 6 text

デザインシステムを持たずにどのような取り組みをしてきたか今日のテーマデザインシステムを持つべきタイミングを考えてみるこれからこれまで

Slide 7

Slide 7 text

その前に

Slide 8

Slide 8 text

デザインシステムとは

Slide 9

Slide 9 text

デザインシステムとはすべて含んだユーザーに一貫した体験を届けるために必要なものを存在

Slide 10

Slide 10 text

デザインシステムとは一部でしかないコンポーネントカタログや、スタイルガイドは同じ意味で語られがち

Slide 11

Slide 11 text

実装形状原則形状をコードに落とし込むためのアプローチが具現化・言語化されているデザイン原則を形状に落とし込むためのアプローチが具現化・言語化されているユーザーに提供したい価値を言語化しているデザインシステムを支えるもの抽象具象

Slide 12

Slide 12 text

何をもたらしてくれるの？「良い」評価基準が明確になるブランド・アイデンティティの確立や認知デザイン・実装コストの削減ユーザーの認知負荷の削減チームのベストプラクティスを凝縮

Slide 13

Slide 13 text

キッチハイクはどうなの？どうやってベストプラクティスを構築していったのか？

Slide 14

Slide 14 text

前編キッチハイクの取り組みとワークフロー

Slide 15

Slide 15 text

2016 ひとりめのデザイナとして本格参入 Ruby on Rails React レス( Backbone.js ) プロダクトは web だけエンジニアデザイナ

Slide 16

Slide 16 text

当時のワークフロー 2016 エンジニア UI 設計 UI コーディング組み込みモデル設計・ルーティング設計 Sketch Haml・Sass・Javascript 組み込みの一部をデザイナが担当することもあったフロントエンドの作業領域は分担していたデザイナ

Slide 17

Slide 17 text

リリースこそ正義チームビルディングもしつつとにかく早くアウトプットする

Slide 18

Slide 18 text

2017 ~ 2018 エンジニアが 6 ~ 8人に増えたエンジニア React Native でアプリ開発 React 導入デザイナ

Slide 19

Slide 19 text

2017 ~ 2018 エンジニアデザイナ当時のワークフロー UI 設計 UI コーディング組み込みモデル・API 設計 Sketch serverside view デザイナはコードにコミットしないことが増えた

Slide 20

Slide 20 text

当時のチーム状況きれいな構造でつくるよりも、ユーザーに届けるのが最優先ゼロイチで開発デザイナ含めてアプリ開発経験者がいないだれもReactを触ったことがない 2017 ~ 2018

Slide 21

Slide 21 text

リリースこそ正義チームの成熟度向上が優先ベストプラクティス構築期間

Slide 22

Slide 22 text

ここまでのまとめデザインシステムをつくれるだけの土台がなかった

Slide 23

Slide 23 text

後編キッチハイクの取り組みとワークフロー

Slide 24

Slide 24 text

キッチハイクに新たな概念登場コンポーネント指向 Reactベースの開発...それは即ちと向き合うこと

Slide 25

Slide 25 text

チームにおける課題いかに効率よく実装するか？コンポーネントの粒度をデザイナとエンジニアでどう統一見解を持つか

Slide 26

Slide 26 text

統一された仕組みの中で UI カタログとコードが参照できる Storybookの導入も検討デザイナが直接コードを触ってリアルタイム変更できる誰がメンテナンスするのか？ワークフローに組み込むコスト期待したこと課題

Slide 27

Slide 27 text

ここで、話題を少し変えます

Slide 28

Slide 28 text

デザインの共有プロセスの煩雑化同じ頃、デザインツールをFigmaに移行 Sketch はデザインが閉じがちになるデザインリソースとして機能させたいチームでデザインするためのハブとして機能させたい課題ゴール

Slide 29

Slide 29 text

UIカタログ view全体デザイナ UI 設計 Sketch エンジニア UI コーディング組み込みモデル・API 設計 serverside view デザイナはコードにコミットしない移行前のワークフロー

Slide 30

Slide 30 text

デザイナエンジニア UI 設計・更新 view全体・UIカタログ・スタイルガイドデザイナはコードにコミットしない移行後のワークフロー UI コーディング組み込みモデル・API 設計

Slide 31

Slide 31 text

Figma移行によるインパクト Single Source of Design 事実上、信頼できる唯一のデザインリソースと化した

Slide 32

Slide 32 text

デザイナがつくったUIを指標に、エンジニアが設計を担うコンポーネント設計どうしてる？ Storybookは見送り、 Figmaを指標とするただし、UIのレベルデザインに厳格に適用しない共通概念 Atomic Designをとして取り入れた

Slide 33

Slide 33 text

キッチハイクの特性を生かしたワークフローいつも本当に助かってます＞＜エンジニアもデザインに対して理解・興味を持ってくれている最近はReactの概念も共通言語になりつつあるデザイナがある程度コードが書けるので、エンジニアと同じことばで会話できるデザイナは設計や体験のデザインに注力したい

Slide 34

Slide 34 text

ここまでのまとめコンポーネント志向とワークフローに向き合った結果、デザインツールによる仕組み化に成功

Slide 35

Slide 35 text

キッチハイクのこれから

Slide 36

Slide 36 text

デザイナとエンジニアをつなぐものはできてきたいかに効率よく実装するか？という視点これまで実装形状原則

Slide 37

Slide 37 text

デザイナがひとりの組織デザイナのスキルや特性・リソース配分によってワークフローが変わるその代わり、デザインが属人化しがちデザイナ自身が single source of design の役割を担う

Slide 38

Slide 38 text

チーム全体の生産性・実装力があがったエンジニアも UI デザインをするフェーズにデザイナがカバーできる生産性を越えつつある最近のチーム体制

Slide 39

Slide 39 text

あるエンジニアの一言自分の中で言語化はできていないけれどデザイナが大事にしているものは何となくわかります

Slide 40

Slide 40 text

いまのキッチハイクデザイナエンジニア少人数かつ守備範囲の広さゆえの「いい感じ力」

Slide 41

Slide 41 text

デザイナがさらに増えて、組織がより拡大したときが検討のタイミングデザインシステムはまだ必要ない

Slide 42

Slide 42 text

デザイナとデザイナをつなぐものが必要になるデザイナにとっての地図・コンパスを構築するフェーズこれから形状原則