プロダクトフェーズとFigmaを介したコミュニケーションの変化

名古屋 Figma勉強会 #01 プロダクトフェーズと を介した コミュニケーション の変化

はじめに 登壇時資料の配布用の簡易版です 内容に関して省略していますがご了承ください

名古屋 Figma勉強会 #01 プロダクトフェーズとFigmaを介したコミュニケーションの変化 自己紹介 ジーラム こと村治 泰広と申します 株式会社マネーフォワード ・デザインマネージャー ・プロダクトデザイナー 副業 ・UIデザイン講師 ・スタートアップ支援 ・メンター ・ピアカウンセラー デザイナーチームを率いたり UXやファシリテーションの研修を 担当しています

名古屋 Figma勉強会 #01 プロダクトフェーズとFigmaを介したコミュニケーションの変化 の経歴 愛知の某大学情報科学部メディアアート専攻を卒業 ナゴヤで就職 Webデザイナー -> ディレクター オーサカに引越し&結婚 制作会社 -> 事業会社のUI/UXデザイナー・2021年 現職に入社

名古屋 Figma勉強会 #01 プロダクトフェーズとFigmaを介したコミュニケーションの変化 いろいろな活動 アジャイルにUIを作ることを誤解しない Earliest Testable Product Earliest Usable Product Earliest Lovable Product インクリメンタルに設計する チームで探索的に（時に立ち止まりながら）向かう方向を 6 STEP デザイナーやエンジニアが難しい ドメイン知識も作図でカンタンに 描いて捉える 業務・ドメインインプット デザイナーは プロダクト戦略を 思ってる以上に強化できる

名古屋 Figma勉強会 #01 プロダクトフェーズとFigmaを介したコミュニケーションの変化 ブツブツ言ってるけど よかったら つながりましょう

名古屋 Figma勉強会 #01 プロダクトフェーズとFigmaを介したコミュニケーションの変化 所属先、担当 プロダクトはたくさん 業務や用途に特化した価値を追求できる スモールチームで開発 少人数への権限委譲がされている Money Forward クラウド

いきなり質問 みなさんの関わるプロダクトの 現在の状況やフェーズって どんな感じですか？

プロダクトフェーズと を介した コミュニケーション の変化 0.課題提起 さらに質問！ 現在のプロダクト状況で 理想のFigmaファイル はどんな状態でしょうか？

プロダクトフェーズと を介した コミュニケーション の変化 0.課題提起 多分それは 人それぞれでしょう

ちなみに私のチームでは 美しいFigmaを「美gma」と 言っています 美

プロダクトフェーズと を介した コミュニケーション の変化 0.課題提起 もちろんフェーズに関わらず 理想とすべき部分 もありそう

プロダクトフェーズと を介した コミュニケーション の変化 0.課題提起 この発表では 理想の状態を出すより その時点の状態に どんな変数があるか 考える場にしたい と思いました

名古屋 Figma勉強会 #01 0->1から1->10 にかけての変化 プロダクトフェーズとFigmaを介したコミュニケーションの変化

名古屋 Figma勉強会 #01 プロダクトフェーズとFigmaを介したコミュニケーションの変化 0->1から1->10にかけての変化 2021/12 サービス共通のビューをただ並べる。Figmaは使わず戦略や体験を練っている状況。 システム通知のため、共通のはずのToast / Snackbarを用意。独自ビューはまだ増えない。 ようやくプロダクトの独自ビューを追加（ただしメインは構想タスク） 構想をラフに描きだす。意識的にプロダクトを作らない。 理想から極力シンプルに実現するビューを追加する。プロダクト独自のカバー画像を設定する。 一気にビューが増える。ElevationやComponent定義と共に他デザイナーが関与し始める。 何もない状態ほどdraftページはカオスが必要、できあがったビューは次第に精緻に。No Kaos, No Design PdMとの壁打ちを続ける。本当に価値ある（望んで使ってもらえる）ものができるまで確定したUIは増やさない。 全体像を見ながらサービスとプロダクトの構造化、ナビやオブジェクトの位置関係など詰める。それこそ設計（デザイン） 増えたフレームに対してコンテンツ種別ごとに1段階→2段階に構造化して配置 後任デザイナーがジョイン。理解するためにカオスがカオスのままである必要を思う。バージョン管理はしていない。 2022/12 ビュー/レイアウト単位でページを分割。ページ内はオブジェクトxCRUDでフレームを配置される。 ※配布版で内容を大幅に端折っておりますがご了承ください

ここまで 組織・現行サービスがある中で 立ち上がりからリリースまで経て 考慮した変数と得た教訓 について話します

名古屋 Figma勉強会 #01 変数1. プロダクトフェーズ プロダクトフェーズとFigmaを介したコミュニケーションの変化

名古屋 Figma勉強会 #01 プロダクトフェーズとFigmaを介したコミュニケーションの変化 変数1.プロダクトフェーズ 0->1 ・軸がない ・人が多く関わらない ・検討過程がすべて ・ゴミのようなラフもある 煩雑さが多いほど良い説も ・なんとなく他プロダクトを真似ることもある 1->10 ・軸が必要（CRUD等） ・人を増やして拡充する ・プロダクトに仕立てる ・整える要素が入る PMFしてなくて時期尚早の場合もある ・プロダクト間の無駄な差異を解消する

名古屋 Figma勉強会 #01 プロダクトフェーズとFigmaを介したコミュニケーションの変化 変数1.プロダクトフェーズ フェーズの目的 いま何が必要か？理解して 敬意をもったコミュニケーションを心がけたい

名古屋 Figma勉強会 #01 変数2. 他プロダクト プロダクトフェーズとFigmaを介したコミュニケーションの変化

名古屋 Figma勉強会 #01 プロダクトフェーズとFigmaを介したコミュニケーションの変化 変数2.他プロダクト Bプロダクト Aプロダクト Cプロダクト ・他に頼って共通のUIを探すだけでは古いものの踏襲になる ・新規に習って（AntやMUIをベースにしたもの）よかった面もある ・ログインなど基盤になるような要素は新たに作る必要がなかった ・サービス、プロダクト特有の要素や必要性の見極めが難しい

名古屋 Figma勉強会 #01 プロダクトフェーズとFigmaを介したコミュニケーションの変化 変数2.他プロダクト 最適解が分からないうちは 暗中模索せず まわりに広く聞く

名古屋 Figma勉強会 #01 変数3. デザインシステム プロダクトフェーズとFigmaを介したコミュニケーションの変化

名古屋 Figma勉強会 #01 プロダクトフェーズとFigmaを介したコミュニケーションの変化 変数3.デザインシステム より広い範囲のデザインシステム 直接作りながら育ててきたデザインシステム プロダクトFigmaファイル

名古屋 Figma勉強会 #01 プロダクトフェーズとFigmaを介したコミュニケーションの変化 変数3.デザインシステム ライブラリ内のコンポーネント群 コンポーネントA コンポーネントB コンポーネントC コンポーネントD コンポーネントE コンポーネントF ... コンポーネントライブラリ コンポーネントA コンポーネントB コンポーネントC コンポーネントD コンポーネントE コンポーネントF プロダクトの範囲を拡げるなかで コンポーネント単位の ファイル構成に変更 など 大きくなる中での変化と苦労がある デザインシステムもまた成長する

名古屋 Figma勉強会 #01 プロダクトフェーズとFigmaを介したコミュニケーションの変化 変数3.デザインシステム 答えがある前提でなく プロダクト側からこそ デザインシステムに足りない内容を見つけて 貢献する足掛かりを探す

名古屋 Figma勉強会 #01 変数4. 開発手法 プロダクトフェーズとFigmaを介したコミュニケーションの変化

名古屋 Figma勉強会 #01 プロダクトフェーズとFigmaを介したコミュニケーションの変化 変数4.開発手法 いろんな文脈で出てくるこのような図 イテレーティブな（徐々に増やしていく）開発 インクリメンタルな（都度完成させる）開発

名古屋 Figma勉強会 #01 プロダクトフェーズとFigmaを介したコミュニケーションの変化 変数4.開発手法 Figmaの話から少し逸れるけど モデリング シソーラス、ワーディング 基本の3原則 ルール 漢字とひらがなの使い分け。 技術用語も含めて、長音は省略しない。 UI仕様、ガイド 管理はスクラムで周期的（イテレーティブ）にすればよいが 設計は都度（インクリメンタル）で固めたい

名古屋 Figma勉強会 #01 プロダクトフェーズとFigmaを介したコミュニケーションの変化 変数4.開発手法 管理はイテレーティブに 設計はインクリメンタルに 期限に間に合わせるのでなく、ある程度予定を計画しながら 都度必要な設計を固めていく

名古屋 Figma勉強会 #01 変数5. 開発時の品質要求 プロダクトフェーズとFigmaを介したコミュニケーションの変化

名古屋 Figma勉強会 #01 プロダクトフェーズとFigmaを介したコミュニケーションの変化 変数5.開発時の品質要求 Before UIデザイナー エンジニア スモールチームからプロダクト成長にあわせて人や役割、関わりが増える After UIデザイナー フロントリードエンジニア QA 組織の構造や関係性、人が多さにあわせて求めるものが変化する

名古屋 Figma勉強会 #01 プロダクトフェーズとFigmaを介したコミュニケーションの変化 変数5.開発時の品質要求 キャプチャイメージ： 参加直後メンバー向けの コミュニケーション 関わる人が増えたとき、必要なことを伝えられているかが重要

名古屋 Figma勉強会 #01 プロダクトフェーズとFigmaを介したコミュニケーションの変化 変数5.開発時の品質要求 いま必要なものが 何か考える 場合によって、これまで積み上げてきたものもリセットして考える

名古屋 Figma勉強会 #01 変数6. 関係性 プロダクトフェーズとFigmaを介したコミュニケーションの変化

名古屋 Figma勉強会 #01 プロダクトフェーズとFigmaを介したコミュニケーションの変化 変数6.関係性 ・期待値 ・技術 ・経験 ・インプット ・裁量 ・価値観 もっているものはみんな違う

名古屋 Figma勉強会 #01 プロダクトフェーズとFigmaを介したコミュニケーションの変化 変数6.関係性 それぞれの違いを理解しあって 丁寧に関わる

ここまでの教訓から Figmaでデザインを作りながら たくさんの変数と コミュニケーションの 幅を感じました

しみじみ デザインコミュニケーションって 変化の幅が広くて 大変ですよね

名古屋 Figma勉強会 #01 プロダクトフェーズとFigmaを介したコミュニケーションの変化 そんな幅のあるコミュニケーションをも支える はすごい でも乗りこなすのは自分たち

名古屋 Figma勉強会 #01 プロダクトフェーズとFigmaを介したコミュニケーションの変化 自分たちから意識的に を使って デザインコミュニケーション の変化を乗りこなしましょう

名古屋 Figma勉強会 #01 プロダクトフェーズとFigmaを介したコミュニケーションの変化 そして を介して 変化に適応しながらデザインの 提供価値を高めていきましょう

終わり、の前に少し宣伝させてください 京都開催版でオンライン・オフラインとも募集中 マネフォ名古屋もよろしくです

おわり ご清聴ありがとうございました！