はじめに
こんにちは、デザイナーのnakaneです。 みなさまいかがお過ごしでしょうか。 私は、夏に向けて愛猫の毛が大量に抜け始め、3時間に一度毛が目に入って痛い日々を過ごしています。
毎度おなじみ社内向けの研究発表会で、我々デザインハブ※が「デザインフォーマットとワークフローの再整備プロジェクト」というテーマで先日登壇いたしました。 ※ハブ…共通のテーマや関心を持ったメンバーの集まりのこと。
先人たちに倣って、私もブログで紹介させていただきます。
目次
- 課題（なぜ整備したのか）
- 方法（どのように整備したのか）
- 成果物（何ができあがったのか）
- まとめ（どう活かしていくか）
1.課題（なぜ整備したのか）
しくみ製作所では、独自の開発サイクルフレームワークTrycleを採用しています。
Trycleは、探索・アジャイル・リーンの3サイクルと、それらを包括したプロジェクトサイクルの計4つから成り立ち、我々デザイナーは主に探索・アジャイルの2サイクルに携わっています。
今回の整備プロジェクトは、この2サイクルでしばしば直面していた以下の課題を解決すべく、発足しました。
2.方法（どのように整備したのか）
デザイナー各人の得意だったり、担当することが多い領域を分担し、それぞれが研究する形で進めました。
探索サイクルは”いわゆるUX”と捉え高見さん（＋ちょこっとnakane）が、アジャイルサイクルは”いわゆるUI”と捉え久米さんがメインとなり進めました。
“いわゆるUX”の領域の整備
ユーザーインタビューになぞらえ、関係者へのヒアリングを繰り返していきました。
ヒアリングで印象的だった出来事が、PdM（プロダクトマネージャー）を多く務める方と話す中で、「Sprint0」というプロセスを認知したことです。
これまでワイヤーフレーム・デザインシステム・デザインカンプ等は、「アジャイルサイクルに入る前にしっかり準備しておくものたち」となんとなく思い込んでいたのですが、それらを準備している時点ですでにSprintが始まっているのでは…Sprint0と定義してもいいのでは？と気付きを得たのです。
この気付きにより、“いわゆるUX”の領域の成果物は、Sprint0の際に使いやすい形であることが重要との結論に至り、ヒアリング対象をSprint0でメインの作業者となるUIデザイナーに変更しました。
“いわゆるUI”の領域の整備
これまで利用していた独自のデザインシステムのフォーマットが少し古くなっていたので、新しいデザイン手法や定番のUIフレームワークを参考にしたり、Figmaの最新機能を用いて見直しました。
※デザインシステムとはなんぞや？と疑問に思われた方は、 以下をご参照ください。
3.成果物（何ができあがったのか）
デザインフォーマット
”いわゆるUX”の領域（探索サイクル）
「プロダクト設計書」と「プロジェクト計画書」の2つのフォーマットを作成しました。
ざっくりいうと、
- プロダクト設計書: プロダクトの目的や強みが一目でわかる説明書
- プロジェクト計画書: プロジェクト進行に必要な基本情報のまとめ
といったかんじです。
”いわゆるUI”の領域（アジャイルサイクル）
従来のデザインシステムフォーマットの進化版「MIYA」を作成しました。
MIYAは幾度かの改修を経て、以下特徴を持ったものになりました。
- 2つのデザイントークンをベースに使用色を定義
- プリミティブトークン（赤、青などの「ただの色」）とセマンティックトークン（背景色、文字色などの特定の意味を持った色）の2つのデザイントークンの概念を活用
- 2つのトークンを、FigmaのVariables機能を用いて設定
- コンポーネントセットは定番のUIフレームワークを参考
- Chakra UIなどのフレームワークを参考に、高頻度で利用するUIパーツを用意
- プロパティやステートの見直し
- コンポーネントは小レベルまで
- コンポーネントは、アトミックデザインでいう原子・分子レベルまでのものに限定
- それ以上のレベルのコンポーネントはデザインカンプ用のファイルで定義
ちなみに、MIYAはFigma Communityにもアップしており、また、しくみフレームワークの一つとしても紹介しています。しくみ製作所以外の方も、ぜひご利用ください！
デザインワークフロー
探索〜アジャイルサイクルのうち主にデザイナーが携わるフローを、制作物ベースで以下のように制定しました。
さらに、各フローのリソースの割当度合いは、
- ちゃんと取り組むことでプロダクト開発全体の効率化に寄与するもの → ちゃんと作ろう
- 限定的な場面でしか使用しなかったり、メンテコスト増になり得るもの → そこそこでOK
ざっくりこの2レベルを設定しました。
とくにワイヤーフレームは、
- 初期段階で、プロダクトの全体像がつかみやすくなる
- 機能や画面の過不足や共通箇所の洗い出しに有用
- 議論のたたきになる
などのメリットがあるため、今回改めて重要性を認識しました。
逆に、デザインカンプは
- 全画面を作り切るのに時間がかかる
- （とくにグラフィカルな要素は求められない管理システム系のプロダクトにおいて、）多くの画面の構成やレイアウトは類似しているので、有用性が低い
- 運用・改修フェーズに入ったあと、最新の状態を保持するのがかなり大変
などの理由により、「主な画面および重要な画面のみの作成に留める」という結論に至りました。
フロントエンドエンジニアには、基本はワイヤーフレームと主な画面のカンプを照合しながら全画面のフロント実装を進めてもらう想定で、他画面のデザインカンプは必要なときだけ作成依頼をしてもらうことにしました。
なお、デザインシステムは、そのプロダクトおよびプロジェクトの規模や開発期間、参加デザイナーの人数に応じて「ちゃんと作ろう」or「そこそこでOK」を決めることにしています。
デザインシステムは規模や編集者が増加するほどコストパフォーマンスが高くなるので、小規模だったり短期的な案件では、「そこそこでOK」でよい方針です。
課題の解決
以上のデザインフォーマットとワークフローにより、課題が解決された（る）と考えています。
事象 | 課題 | どう解決された（る）か |
情報伝達に煩わしさを感じ、PdMがワイヤーフレームを組むことが多々ある | デザイン視点の情報整理・画面構成提案を逃しがち | フォーマット（プロダクト設計書）によってPdMの情報伝達ハードルが低くなる |
プロダクトの参考資料が散在している | UI作成時に手間取りがち | プロダクト設計書を見れば基本OK |
Figmaとコード間で色やフォントサイズ等のルールが異なっている | フロント実装時に非効率になりがち | コンポーネントやステート、命名等を再定義したことでシームレスにフロント実装にバトンタッチできるように |
最初にデザインカンプをかっちり作り込んでいる | UIデザインのみウォーターフォールになりがち | 必要に応じてデザインカンプを作成する運用にし、UIデザインもアジャイルに沿った形に |
開発・運用中にUI改修をする際、コード上で編集するだけの場合が多々ある | デザインカンプの存在が次第に負担になりがち | 重要性が下がったので、デザインカンプの更新はしなくてOK |
4.まとめ（どう活かしていくか）
当たり前ですが、新規プロジェクトで活用していきます。そして、改善を繰り返してよりよいものに進化させていく予定です。
プロダクト設計書およびプロジェクト計画書は、プロダクトマネージャー・プロジェクトマネージャー・クライアントにも編集 / 更新していただく想定なので、様々な視点でフィードバックをしてもらえると期待しています。
MIYAは主にデザイナーが編集 / 更新していく想定ですが、デザイン→フロント実装のシームレス化も主目的の1つなので、とくにフロントエンドエンジニアからフィードバックをいただけると大変ありがたいと思っています。
デザインハブでは、開発サイクル全体の効率化のために、今後もデザイン領域の効率化を推進していく所存です。
