Zenn
🤝

『ペアデザ』で現場の共通言語をつくった話

2022/06/04に公開
UI/UX
UI
UX
idea

はじめに

本記事はUIデザインも扱うフロントエンドエンジニアが短納期PJで他エンジニアと行った「ペアデザイン」という取り組みについて書いたものです。

デザイナーとエンジニアが協業するときは色んな要望・悩みがあがると思います(短納期PJは特に)
◯ レスポンシブ時の仕様やレイアウトを伝えるのが難しい
◯ スタイルの微調整にPRを切りたくない
◯ デザインデータを共有されてもパラメータの見方がわからない
◯ デザイナーが想定している挙動を実装したい
◯ エンジニアが実装しやすいように仕様を伝えたい
などなど。

デザイナーとエンジニア間のコミュニケーションを円滑にする方策は度々話題になってます。
かくいう私も業務の中でデザイナーとエンジニアの中間の(半端な)立場におり、
◯ 実装したComponentの微細なスタイルの手戻り
◯ デザインドメインのないエンジニアにデバイスごとのレイアウト変更について伝えにくい
といった悩みを解消できずにいました。

なぜコミュニケーションを円滑するのか

(このセクションは私見です)
前述した要望・悩みは、デザイナーとエンジニアの役割の違いによって起こります。
デザイナーは体験を設計し、エンジニアは体験を形に起こす役割です。

「エンジニア(デザイナー)の考えてることがわからない！」 という思いはその違いによって生まれやすくなると私は考えています。

ですが、職が違えどもその最終目的は概ね「ユーザーへの価値提供や価値そのものの向上」に収束します。
それを叶えるために重要となるのが円滑なコミュニケーションと 『デザイナーとエンジニアの共通言語(インターフェース) です。

それを実現するために ２職種共同の「ペアデザイン」 を業務内で企画・実施しました。
本記事ではこのペアデザについて紹介します。

『ペアデザイン』とは

読んで字の如く、ペアでUIデザインを行い職種間の共通言語を作ることを目的とした取り組みです。
ペアプログラミングやモブプログラミングの思想を基にしています。

ペアプロと同じく、ペアデザにはドライバとナビゲータが存在します。
それぞれの役割は以下の通りです。

  • ドライバ
    • ナビゲータに合わせてFigmaを操作し、UIコンポーネントをトレースする人
    • デザイナーが設定したスタイルの見方を知る
  • ナビゲータ
    • Figmaをメイン操作し、UIコンポーネントを作成する人
    • 設計中の
    • (事前に)colorやfontのstyleを登録しておく

今回やったこと

対象: 同PJにいるフロントエンドエンジニア2名(1名はFigma初心者)
環境: 各自のPC→Figmaで同時に操作
タスク: トースト通知UI, テキスト入力フォーム通知UIの作成

事前準備

  • ペアデザ全体の目標設定(どんな共通言語, 状態を作りたいのか)
  • 共通言語となる情報リストアップ
    • パラメータの見方
    • デザインシステムに習ったUIの挙動(ホバー, エラー, 成功時)
    • 表示に必要なデータ(props) etc...
  • プロトタイプ(見本)を作成
    • 本番の挙動まで実装する(レスポンシブやホバーアクションなど)

実施内容

※以下の内容はサンプルではなく、実際に行った/説明した内容です。

  1. ペアデザのゴールを説明
    • どんなコンポーネントをどんな状態まで作るのか
      • Componentをゼロから作成し、AutoLayoutを使ってレスポンシブ対応まで行う
    • どれくらいの時間でやるのか
      • 今回は20分/人
    • ペアデザ全体の目標
      • スタイルの微細な手戻り防止として、ColorやPadding等をGUIから読み取る方法を知ってもらう
      • 実装イメージを持ってもらいa11yの不備がないか擦り合わせる
  2. Component作成
    • ドライバのデザインツールの使用経験に合わせてナビゲーション(ドライバができる部分はどんどん進めてもらう)
    • 図形や文字をつかって見た目(ピクセルサイズと位置)だけ見本と同じものを作る
    • スタイル時にColorStyleとTextStyleの追加方法を説明する
    • AutoLayoutを使用して子要素が親要素に従うように調整する
  3. 既存のページにComponentを埋め込む
    • 本番利用のイメージを視覚的に共有し、認識を統一する
    • ステート管理等の実装イメージを持ってもらう
  4. a11y擦り合わせ
    • 画面操作に関わる情報を適切にユーザに伝えられているか
    • 色のコントラストは適切か
  5. パラメータ管理の擦り合わせ
    • どのような責務(管理)をComponentに与えるか(ステート)
    • どのような命名規則か(デザインツール上のどの部分を反映するか)
    • Colorのグラデーションはopacityで管理するか, トーンで管理するか
    • 今後使われそうなSpacingは何ピクセルか etc...
  6. 終了

各セクションの要点

事前準備

ここでの重要ポイントは 情報を満遍なく洗い出すこと と プロトタイプを作り込みすぎないこと です。

情報の洗い出しは目標設定のために言わずもがな重要です。
現状にどこに課題があり、何が原因で、どのようにすれば共通言語があれば解決できそうか、を言語化します。

今回の例

課題: スタイルや命名の手戻りが多く機能実装に割くリソースが減っている
原因: Componentのデバイスごとの挙動についてうまく伝えられていない
目標: パラメータの命名規則(共通言語①)やComponent共通の挙動(共通言語②)の互いの認識を合わせる

もう一つの『プロトタイプを作り込みすぎないこと』ですが、プロトタイプの難易度が一方的に上がることの防止します。難易度ーによってデザイナーの意図の一方的な押し付けを防止するためです。
共通言語をつくる中では最も重要なのはお互いの思考について理解しようという姿勢です。

プロトタイプは「どんなものを作るかを端的に表現するもの」程度に作ったほうが良いでしょう。

実施内容: Component作成

ここでの重要ポイントは 感情をさらけ出すこと です。

命名やComponentの構造に限らず、デザインツールの使い方などわからないことがあればエンジニアは遠慮せずデザイナーに聞きましょう。どんなに小さいことでも疑問をぶつけることで「何がわからないのかわからない」を予防できます。
デザイナーも何がわかっていないのか察するだけでなく、「内容をどこまで理解しているか？」とエンジニアの理解度を確認するとストレスフリーなペアデザができます。

評価

今回のペアデザを通して 「実施前後でエンジニアの開発生産性が向上したか」 をドライバ陣に聞いたところ、

  • configファイルにカラパレを整備するときに都度確認する労力がなくなった
  • hoverやfocus, デバイス差によるレイアウトの変化など細かなインタラクションの挙動を想定しやすくなった
  • GUIツールからデザインの意図を(以前より)汲み取りやすくなった

といったコミュニケーションや実装面で良い効果を得られました。
今回ナビゲータとして振る舞った私も、ペアデザ後からUIの微細な修正作業やPull Requestが激減したことを感じました。

目的は『共通言語』をつくること

ペアデザの目的は「知識差をなくすこと」や「デザインの体験入門」ではありません。

デザイナーとエンジニアがそれぞれ考えている
・どのようなルールでComponentをつくるか(色やピクセル数の選定)
・どのような責務(管理)をComponentに与えているか(ステート)
・どのような挙動を想定しているか(レスポンシブ, アニメーション)
といった要素を擦り合わせて、コミュニケーションをとるときのタイムラグをなくす(共通言語をつくる)ことが目的です。
その上で環境に合わせた目標設定をすることで効果の高いペアデザが行えます。

事前準備の要点でも書きましたが、目標設定もガチガチに固めてしまうと一方的な押し付けになったり自らの首を絞めてしまいます。
実際にやってみて 「そうかこの部分が伝わりにくいのか！」「ここわかるなら説明は二度手間だな...」 とそのとき気づいたり、その場の擦り合わせがより高い効果を生むことも十分あります。

ペアデザをするときは目標をしっかり言語化しつつ、デザイナーとエンジニアがお互いに対してリスペクトを持って、対等にコミュニケーションが取れるよう進めていきましょう。

さいごに

今回紹介したペアデザは 極めて限定的で、ジャストアイデアな内容です。
エンジニアの手動と会話によってミニマムなUIと共通言語をつくることで実装の効率化、都度その現場に合わせて企画しては首が回らないでしょう。
どのメンバーに、どんな共通言語を、どんな目標の下で作っていくかを言語化できればそれぞれに合ったペアデザが企画できると思います。

初めてのIdea記事だったため、適切に表現できていない部分が多々あると思います。
ご意見・ご質問がございましたらコメントくださると幸いです。

Discussion