エンジニアリングを生き延びるワイヤーフレームとプロトタイピング
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
初めてそれが起きたとき、私は辞めそうになりました。
設定フローに3週間を費やしました。美しいFigmaファイル。全ての画面。アバターアップロードのホバー状態まで作り込みました(こだわっていたので)。エンジニアリングがそれを実装しました。空の状態は「Empty」という文字が12pxのArialで表示された悲しいグレーのボックスでした。エラーのトーストはブラウザのデフォルトの赤いバーでした。ローディングは一般的なスピナーで、ローカル開発環境ではリクエストが40msで完了するのに即座に表示されました。バリデーションメッセージ? 「requested formatに合わせてください」というネイティブHTMLの<input>ツールチップでした。
エンジニアにメッセージを送りました。彼は落ち着いた口調で「仕様がありませんでした」と言いました。怒りが湧きました。Figmaに戻りました。彼は正しかった。仕様を書いていませんでした。
その会話がこのガイドが存在する理由の全てです。エンジニアリングは敵ではありません。仕様のギャップが敵です。仕様のギャップはUXの問題であり、エンジニアリングの問題ではありません。
なぜ今これが重要なのか
1回のやり直しのコストを計算してみてください。1つの機能。1スプリント。空の状態が間違っていて、エラーハンドリングが欠けていて、バリアントがなかったためにエンジニアリングがコンポーネントをリファクタリングする必要があります。直近の4つの職場から、こうしたやり直しの平均コストはデザイナーの作業時間40時間とエンジニアリングの作業時間60時間です。100人時、混合コストでチームによって12,000〜15,000ドル程度。四半期に1回のやり直しで、より良いハンドオフドキュメントがあれば防げた作業に年間5万ドルを費やします。
これはドルの話だけです。信頼のコストはより深刻です。2回目のやり直しの後、エンジニアリングはあなたの仕様を信頼するのをやめ、あなたが意図したことを自分たちで判断して作り始めます。3回目の後、PMは「デザインは常にもう一ラウンド必要とする」という理由でタイムラインを信じなくなります。ハンドオフは引き渡しではありません。契約です。そのように扱えば、これらのほとんどは消えます。
ローファイとハイファイ: それぞれが価値を発揮するとき
ジュニアデザイナーが犯す最大の失敗の一つは、ハイファイに早すぎる段階で移行することです。フローが固まる前にピクセルパーフェクトなモックを作ります。エンジニアリングがそれを見て興奮し、作り始めます。その後リサーチが返ってきてフローが変わります。エンジニアリングはすでに本番コードで間違ったものの半分を作ってしまい、誰かがPMにスプリントが遅れた理由を説明しなければなりません。
ローファイはフローロジックとステークホルダーの承認のためのものです。紙スケッチ、Balsamiq、プレースホルダー矩形を使ったFigmaの大まかなフレーム。答えようとしている問いは「これはそもそも正しいアイデアか」です。明日捨てるかもしれない画面をピクセル磨きしないでください。成果物は、AからBへのパスが意味をなすことを証明するクリッカブルプロトタイプとフロー図です。それだけです。
ハイファイはビルドのためのものです。ピクセルパーフェクト、本物のコピー(ダミーテキストは絶対に使わない。エンジニアリングはコピーペーストして、本番ログインページに「Lorem ipsum dolor」を見つけることになります。どうして知っているか聞かないでください)、本物のデータの形状、全ての状態。フローが固まってから初めて。フローがまだ議論されている画面のレイアウトの細かい修正をしている自分に気づいたら、止めてください。ローファイに戻って、まずフローを固めてください。
正直なテスト: ステークホルダーがまだ「なぜユーザーはここに行くのか?」と聞いているなら、ハイファイの準備はできていません。矩形がどれほどきれいでも関係ありません。
エンジニアリングが聞いてくる仕様のギャップ(あなたが設計していなかったもの)
これがデザイン学校で誰も教えてくれない部分です。すべての画面には約8つの状態があります。あなたはおそらくそのうちの2つを設計しました。以下が、エンジニアリングが座った瞬間に返してくる状態のリストです。
全ての画面に必要な8つの状態
- デフォルト/データあり。 ハッピーパス。あなたはこれを設計しました。
- 空の状態。 アイテムゼロ、結果ゼロ、初回ユーザー。何も表示するものがないとき、ユーザーは何を見るか?「アイテムはまだありません」はデザインではありません。イラスト、CTAのコピー、セカンダリアクションを見せてください。
- ローディング。 スケルトン、スピナー、楽観的UI。そしてタイミングのルール: スピナーが表示されるまでの時間は?(200msが標準のしきい値。それ以下では何も表示しない。)
- エラー。 APIの失敗、バリデーション、権限拒否、ネットワークオフライン。それぞれ異なります。500エラーは403とは異なり、「パスワードが短すぎます」とも異なります。
- 部分的/劣化した状態。 データが半分ロードされた、一部の画像が壊れている、サードパーティのウィジェットがダウンしている。実際のシステムは常にこれに当たります。
- 権限バリアント。 管理者、メンバー、ビューアー、ゲスト。何が非表示になり、何が無効になり、何がツールチップ付きで表示されるか?
- エッジデータ。 折り返しが必要な長い名前、0/null/負の数、5件向けに設計されたリストに47件、32文字の税ID。
- モバイル/ブレークポイント。 デザインがデスクトップファーストなら、768pxと375pxでは何が起きるか?「レスポンシブ」は仕様ではありません。
このリストをモニターの横に貼っています。ハンドオフの前に、8つの状態に対して全ての画面を確認します。ある状態が「デフォルトと同じ」なら書き留めます。「このスプリントのスコープ外」なら書き留めます。重要なのは常に8つ全てを設計することではありません。8つ全てについて意図的に決断し、その決断をファイルに記録することです。
8つの状態のギャップは、私が見る中で最も一般的な失敗です。これ一つを修正するだけで、「仕様がありませんでした」という瞬間の約60%を排除できます。
FigmaのAuto-Layoutの規律
Auto-Layoutは任意ではありません。ファイルがこれで構築されていなければ、エンジニアリングはどれがコンポーネントでどれがフレームか、パディングとマージンの区別、コピーが長くなったときに何が起きるかを判断できません。推測します。間違った推測をします。そしてあなたの責任になります。
時間を節約してくれた4つのルール:
- デタッチされたフレームではなくコンポーネント。 全ての再利用可能な要素は、エンジニアリングが読める名前を持つコンポーネントです。ボタンは
Button/Primary/Defaultであり、Rectangle 47ではありません。エンジニアリングがインスペクターでコンポーネント名を見られなければ、推測しています。 - 目測でのマージンではなく、本物のスペーシングトークン。 4、8、12、16、24、32。それだけです。
padding: 13pxと入力しているなら、間違っています。一つを選んで先に進んでください。 - リサイズが実際に機能するよう制約を設定する。 最大サイズと最小サイズで全てのコンポーネントをテストしてください。タイトルが80文字のときにカードが壊れるなら、エンジニアリングは本番でそのバグに当たります。
- 状態のためのバリアント。 デフォルト、ホバー、アクティブ、無効、ローディング、エラー。全て1つのコンポーネントにまとめ、プロパティで切り替え可能に。エンジニアリングはバリアントをステートマシンに結び付け、ファイルは自己文書化されます。
便利なスメルテスト: ファイルを開き、任意の要素をクリックし、右側のパネルを見てください。それがどのコンポーネントか、どのバリアントにあるか、どのスペーシングトークンを使っているかが一目でわかるなら、エンジニアリングにも伝わります。ハンドオフ前に修正してください。
デザイントークン: エンジニアリングとの契約
トークンはUXデザイナーがリリースできる中で最もレバレッジが高いものです。色、タイプスケール、スペーシング、角丸、影、モーションの時間: 全て名前付き、全て一度定義、全てのコンポーネントで名前で参照されます。
契約はシンプルです。トークンが変わると(例えば、ブランドが#0066FFから#0052CCに更新される場合)、エンジニアリングは1つの変数を変えます。40個のコンポーネントではありません。タイプスケール、角丸、全ての影も同様です。
配管は本当に良くなっています。真実の情報源としてのFigma Variables。JSONにプッシュするためのTokens Studio(またはネイティブのVariables export)。JSONはTailwindの設定、CSS変数、またはStyle Dictionaryのビルドにインポートされます。エンジニアリングは16進数を手入力しません。あなたは記憶から色を再選択しません。
まだトークンを使っていないなら、今四半期に実施できる最も高ROIの投資です。最初の移行には1週間かかります。その後の全てのハンドオフはより安くなります。
ハンドオフドキュメント: Loomとアノテーション
ハンドオフドキュメントは契約です。口頭でのハンドオフはそうではありません。「エンジニアに直接話します」はデザインで最もコストの高いショートカットです。廊下での会話は明確化には最適です。仕様には最悪です。なぜなら、6週間後にQAがギャップを見つけたとき、あなたとエンジニアは会話の内容を半分ずつ違うように覚えているからです。政治的な影響力が多い方が勝ちます。それはデザイン組織の機能する方法ではありません。
ハンドオフドキュメントは3つの部分で構成されます。
パート1: フローを説明する5分間のLoom。 Figmaを開き、画面共有し、録画を開始します。そのフローを一度も見たことがない開発者のペースでフローを説明します。説明する内容: エントリーポイント、全ての画面、非明示的な動作(「トーストはフェードではなくスライドインします、200ms ease-out」)、全ての状態切り替えロジック(「インボイスがゼロのユーザーにはこれが空になりますが、インボイスがあって全て削除した場合、初回の空の状態ではなく『全て削除済み』バリアントを表示します」)。私はこれを3分間の構成に保っています: 30秒のコンテキスト、2分間のフロー説明、30秒の注意点、30秒のエンジニアリングへの質問。
パート2: アノテーション付きFigmaフレーム。 各画面に番号付きの吹き出し。赤い付箋ではありません。契約のように読める番号付きのアノテーション。「1: アバター。クリックするとアップローダーモーダルが開く。モーダルはEsc、オーバーレイのクリック、正常アップロードで閉じる。」全てのインタラクション。全てのアニメーションのタイミング。8つの状態の確認で明らかになった全てのエッジケース。
パート3: エンジニアリングの言語での受け入れ条件。 これはデザイナーが省略するが省略すべきでない部分です。受け入れ条件はこのように見えます。
ユーザーが無効なメールアドレスで「保存」をクリックしたとき、200ms以内にフィールドの下にインラインエラーが表示され「有効なメールアドレスを入力してください」というテキストが表示され、フィールドに赤い枠線(トークン:
border-error)が付き、フォーカスはフィールドに留まる。
それは3つの動作的な事実(タイミング、コピー、フォーカス状態)で、QAが検証でき、エンジニアリングが作ることができます。非trivialなインタラクションがある画面ごとに5〜10個書いてください。はい、遅いです。意図的に遅いのです。遅い部分は仕様のギャップが死ぬ場所です。
最後のルール: 単一の真実の情報源Figmaフレームにリンクしてください。 12のファイルではありません。「探索v3とv5を参照しますがv4ではありません」でもありません。1つのフレーム。1つのURL。複数のファイルを指定する必要があるなら、エンジニアリングは間違ったものを選びます。それは自業自得です。
「エンジニアに直接話す」という失敗モード
緊密なエンジニアリング関係を誇りにして、書面でのハンドオフをオーバーヘッドと見なすデザイナーを知っています。わかります。私もかつてそうでした。その関係は本物であり、投資する価値があります。しかし、関係はドキュメントの代替ではありません。
口頭ハンドオフの3つの問題:
- 記録がない。 6週間後にQAがギャップを見つけたとき、あなたとエンジニアはどちらも会話を半分ずつ違うように覚えています。政治的な影響力が多い方が勝ちます。それはデザイン組織の機能する方法ではありません。
- 共通理解がない。 エンジニアリングは自分の解釈でコールを終えます。あなたは自分の解釈で終えます。重なる部分は70%程度。残りの30%がバグの住む場所です。
- リリース後に検証する方法がない。 ビルドをQAするときに、照合するものがありません。雰囲気をQAしています。
今私が守るルール: 書き留めていなければ、起きていない。Loomは書き留められています(録画です)。アノテーションは書き留められています。受け入れ条件は書き留められています。廊下での「あ、これもやってもらえますか」という会話は1時間以内に書面でフォローアップされます。そうでなければXは作られません。
リリース後レビュー
ハンドオフはエンジニアリングがマージしたときに完了しません。サンドボックスまたはステージング環境でFigmaと照らし合わせてライブビルドをQAし、一緒にギャップを記録したときに完了します。
私の実施方法: サンドボックスまたはステージング環境で30分間のミーティング。デザイナーとエンジニアが画面を共有します。全ての画面と全ての状態を確認します。それぞれに3つの可能な結果があります。
- 一致。 次に進む。
- ギャップ、今スプリントで修正。 記録し、バグを起票し、エンジニアが修正をコミット。通常、機能ごとに1〜2件。
- ギャップ、受け入れてFigmaを更新。 エンジニアのバージョンが実際には優れている場合や、ギャップがスプリントをかけるほど重要でない場合があります。Figmaを本番の実態に合わせて更新してください。ファイルを本番に何があるかについて嘘をついたままにしないでください。
最も重大な問題はサイレントな修正です。次のリリースでエンジニアに黙って更新しないでください。ギャップが存在しないふりをしないでください。記録し、一緒に決断し、次に進んでください。このサイクルを数回繰り返すと、エンジニアリングはQAが対立的ではなく協調的だと信頼し始めます。ビルドのより早い段階で自分から懸念を表明し始めます。
合理的な目標: リリースした機能ごとに記録されるギャップが3件以下、8つの状態の規律が強化されるにつれて減少していく。
成功を測る方法
3つのサインが、ハンドオフの規律が機能していることを教えてくれます。
- スプリントごとに「仕様がありませんでした」という瞬間がゼロ。 これはラギング指標です。これが起きているなら、8つの状態の確認が完了していませんでした。
- エンジニアリングがPRでFigmaのフレーム名を引用する。 「Settings/Profile/Avatar-Upload v2を実装」。エンジニアリングがあなたのフレームを名前で参照するコミットメッセージとPRの説明を書くとき、あなたのファイルが真実の情報源になっています。それが目標です。
- リリース後レビューが機能ごとに3件以下のギャップを記録する。 そしてギャップが小さな視覚的な修正に向かっており、欠けた状態や間違った動作ではない。
3つ全てが当てはまるなら、ハンドオフの問題を解決しました。あなたの役割はデザインを守ることから拡張することにシフトします。それが最終的にUXが行うべき仕事です。
Figmaファイルはアートではありません。契約です。全てを書き留めてください。8つの状態を確認してください。Loomを録画してください。フレームにアノテーションを付けてください。エンジニアリングの言語で受け入れ条件を書いてください。リリース後レビューを実施してください。これを5回連続で行えば、やり直しの率はほぼゼロに近づき、ハンドオフの金曜日を恐れることがなくなります。
Camellia
関連記事
Principal Product Marketing Strategist