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