Communitygithub.com

heyviet/wireframe-fundamentals

ワイヤーフレームの作成が適切な場面を判断し、適切な精度(フィデリティ)レベルを選択し、高忠実度デザインやコードへの移行を決定するためのガイドです。

wireframe-fundamentals とは?

このスキルは、デザイナーやプロダクトマネージャー、開発者がワイヤーフレームを効果的に活用するための包括的なフレームワークを提供します。ワイヤーフレームの本質は「共有理解の構築」であり、見た目を整えることではありません。精度(フィデリティ)は決定済みの確実性に合わせるべきであり、検証されていない前提を過度に表現してはいけません。このスキルは、新しい画面や機能の開始時、チームが構造よりもビジュアルにこだわって行き詰まった場合、またはプロジェクトが後工程で大きな手戻りを起こした場合に特に有効です。フィデリティラダー(No-fiからHi-fiまでの段階)に従い、各フェーズで適切な精度を選択することで、初期段階で構造上の欠陥を発見し、コーディング開始後の大規模な修正を防ぎます。さらに、具体的な評価手順やアンチパターン、ツール選択の指針も提供し、チーム全体でワイヤーフレームを正しく使いこなせるよう支援します。

対応~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/heyviet/wireframe-skills/tree/HEAD/skills/wireframe-fundamentals

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

ワイヤーフレームの基礎

概要

精度(フィデリティ)は確実性に応じて決めるべきです。 検証済みの決定事項以上に、見た目を洗練してはいけません。ワイヤーフレームの成果物は「共有された理解」であり、アーティファクトそのものではありません。ワイヤーフレームは、作成が安く、変更が安く、破棄も安いスケッチ/プロトタイプのハイブリッドであり、誰かがコードを書く前に構造上の欠陥を表面化させます。

使用すべきケース

  • 新しい画面、機能、製品を開始するとき — ビジュアルデザインやコードの前
  • 次のデザイン成果物の精度を選択するとき、または精度を上げるか下げるかを決めるとき
  • ワイヤーフレームの手法やツールを選ぶとき(紙、ホワイトボード、専用ソフトウェア)
  • チームがいきなり完成度の高いモックアップに飛びついてピクセル単位の議論で行き詰まっている場合
  • 開発者やステークホルダーに、開発開始前に構造とフローを一致させるため
  • NOT for: ビジュアルの洗練 — タイポグラフィ、色、ブランド、モーション。これらはコンピューター・モックアップの領域です(併用スキル:hallmark)。
  • NOT for: ユーザーとの微細なインタラクションの詳細を検証する — それにはプロトタイプが必要であり、ワイヤーフレームではありません。

なぜローフィデリティが優れているのか

  • 洗練は誤った自信を生む。 リアルなデザインは、全てのレビュワーに「ほぼ完了」と読まれます。フィードバックは構造からブランディングに移行し、承認は間違った軸で下されます。仕様書 → 完成度の高いプロトタイプ に進むチームは、捨てたワイヤーフレームの3ラウンドで発見できたはずの欠陥のために、何ヶ月もの作業を定期的に破棄しています。ワイヤーフレームツールの意図的に手描き風の外観は、まさにこの誤読を防ぐためにあります。
  • 省略こそが機能である。 細部を意図的に省くことで、注意は構造、コンテンツ、フローに集中します。製品と誤認されないワイヤーフレームは構造的な批評を促します。誤認されるワイヤーフレームはフォントの意見を招きます。
  • 変更のしやすさは、作成のしやすさに勝る。 紙のスケッチは作成が速いが修正は遅い。プロトタイプは両方とも遅い。デジタルワイヤーフレームだけが両方とも速いアーティファクトです。これこそが、発散と収束の両方で使える理由です。
  • 頭の中のイメージは、思っているより曖昧である。 アイデアを具体化することで、頭の中にだけ存在している間は見えなかったギャップ(忘れた状態、欠落したステップ、対処されていないケース)が露呈します。最初のワイヤーフレームで何も欠けていないことがわかったなら、それは考えたのではなくコピーしたのです。
  • 量こそが手法であり、無駄ではない。 ピクサーでは、単一の90分のリールに約12,000枚のストーリーボードが使われ、1本の映画につき最大10本のリールが作られます。つまりアニメーション開始前に最大120,000枚の絵が描かれます(エド・キャットマルは失敗を「学習と探求の現れ」と呼びます)。ノーマのルネ・レゼピは率直に言います。「素晴らしいアイデアが一つ生まれるたびに、10のアイデアが入ってくる必要がある。」 最初のコンセプトをそのまま製品化できると期待するなら、それを効率ではなく危険信号として扱ってください。

フィデリティラダー

レベル見た目コード化されている確実性使用目的
No-fiボックス、矢印、フローチャート、コンテンツリスト — UI要素なし問題とフローがまだ不明発見:オプション、画面、コンテンツモデルのマッピング
Low-fi単色のラフなフレーム、不正確な線、プレースホルダーテキスト候補となる構造が形成中迅速な発散:1つにつき数分で多くのレイアウト概念を生成
Mid-fi実際のUIコンポーネント、実際の見出し/ラベル/CTA、限定的なパレット、Lorem Ipsum本文構造が合意され、インタラクションが洗練中結合と洗練、レイアウト/コンポーネントのバリエーション、初期フィードバック
Late-phaseMid-fi + 注釈、画面間の矢印、完全なフロー、サンプルコンテンツ構造とフローが確定ステークホルダーレビュー、開発者への引き継ぎ — 単独で完結する必要あり
Hi-fi製品と見分けがつかない、インタラクティブな場合もあるビジュアル+インタラクションの決定が確定これは現在プロトタイプ/コンピューターであり、ワイヤーフレームではありません。別のアーティファクト、別のルールが適用されます

次のレベルの精度に進むのは、現在のレベルが存在する目的である質問に答えられた場合のみです。フローがレイアウト詳細より先に検証され、レイアウトがコンポーネント選択より先に合意され、構造がリアリズムより先に承認されていること。

次のいずれかの条件が発生したら、精度を1つ下げてください。

  • レビュワーが構造ではなく色やフォント、余白についてコメントする — アーティファクトが目の前の決定に対して過度にレンダリングされています。
  • 議論が目の前の画面ではなく、欠落した機能やフローの順序についてである。
  • コンセプトが行き詰まったか、新しい要件が発生した — 高価な改装ではなく、安価に再スタートする。
  • フローが合意される前に、ピクセルを微調整している自分に気づく。

ステークホルダーが「高忠実度のワイヤーフレーム」を要求した場合: それはコンピューターまたはプロトタイプの要求です。別のアーティファクトとしてそれを作成してください。ワイヤーフレームを肥大化させてはいけません。そうしないと、変更の許容性を失います。

プロセス全体におけるワイヤーフレーム

発散時には量が増加し、収束時には減少します。そして精度は決定が確定した場合にのみ上昇します。収束は1つの滑らかな漏斗ではありません。小さな収束/発散のステップ(Pughの制御収束)を交互に行い、生き残ったものから新しいバリアントを出現させます。

フェーズ精度ワイヤーフレーム数出口基準
発見(Discovery)No-fi多数の断片画面、フロー、コンテンツが列挙され、オプションがマッピングされる
定義(Definition)Low-fi≥3つの異なるコンセプトチームがビジュアルを議論せずに構造を議論できる
デザイン(Design)Mid-fi1〜2つのマージされた生存者+バリアント1つの構造が合意され、インタラクションとナビゲーションが解決される
構築/引き継ぎ(Build/handoff)Late-phase完全な注釈付きフロー開発者が作成者の不在でもそれに基づいて構築できる
  • 発見 — No-fi。 目標:アイデアを頭から出し、そこから現れたものをさらに生成する。フローチャート、画面接続図、コンテンツプレースホルダー。最速のツールで迅速に動く。より多くの出発点は常に良い。ここでUIの詳細を追加しているなら、1つのアイデアに時間をかけすぎている — 一歩下がること。
  • 定義 — Low-fi。 問題ごとに、収束する前に構造的に異なるコンセプトを≥3つ生成する。コンセプトは、その完成度ではなく、それが生み出す会話で評価する。「デザインアーティファクトは完成して見えなければならない」という無意識のルールを打ち破る。
  • デザイン — Mid-fi、「結合と洗練」。 前回のお気に入りを単純に昇格させてはいけません。複数のコンセプトの強い部分をマージし、快適に感じるよりも1ラウンド長く不確実性にとどまる。実際のテキストと実際のコンポーネントを導入する。詳細を制限するために限定的なパレットを維持する。画面間のナビゲーションと画面ごとのインタラクションを開始し、コンポーネントレベルでバリアントを作成する。
  • 構築/引き継ぎ — Late-phase。 新しいオーディエンス(同僚やステークホルダー、自分ではない)のために最適化する。注釈を追加し、画面を矢印で接続し、ワークフローの全ての画面を含め、重要なまたは新しいインタラクションにのみ詳細を追加する。ワイヤーフレームは作成者がいなくても理解できる必要がある。このフェーズの危険:愛着 — ドメインの専門家や開発者は、それを自由に判断し、削除し、無効にする権限を持ち続けなければならない。

良いワイヤーフレームとは

ワイヤーフレームは、それが何を引き起こすかで判断し、製品にどれだけ似ているかで判断してはいけません。

  1. 存在する前に3つの質問に答えている。 ファイルの最初のページに書く:誰がこれを使うか(ペルソナまたは具体的な役割 — 「管理者」、「寄付者」)?彼らの目標は何か(ユーザーニーズとしてフレーム化 — 誰もサインアップしたいとは思わない。彼らは進捗を保存したいのだ)。どのような問題に対処するか(現在の痛み、競合とのギャップ)?問題の定義が不十分な優れた解決策は、よく定義された問題に対する平凡な解決策に負ける。このメモをスキップすることは、プロセス全体において最も影響の大きい間違いである。
  2. 繰り返し改善された。 良いワイヤーフレームは、磨かれた初稿ではなく、多くのラウンドを生き延びたものです。全てのバージョンを使い捨てと見なし、削除する意思が品質の原動力です。
  3. ギャップを明らかにした。 欠落した状態、ステップ、ユースケースを示したワイヤーフレームは、すでにその価値を証明しています。未完成性は機能です。それらのギャップを埋めるアイデアを促します。
  4. 行動を促す。 注釈を付け、意図的に未完成の領域を残し、現在の製品との差異と最も確実性の低い領域を強調する。詳細予算:伝達の労力が、オーディエンスが知る必要のあるものを超えたら停止する。失敗の反応は「OK — それで、次は?」。成功のテストは、次の人があなた無しでそれを引き継いで実行できることです。

ツールの選択

  • 唯一必須の機能:それはフローを中断してはならない。 適切なツールは、アイデアが到着したのと同じ速さで可視化する。初期フェーズ:ペン/紙またはホワイトボードはソフトウェアと完全に競合できる。
  • ソフトウェアの場合、必須条件: 標準UIコンポーネントのライブラリ(中期/後期段階のフレームを開発者が構築できるものに対応させるため) — そして、微調整機能(ピクセル寸法、CSSプロパティ、インタラクティブ動作)の不在を必須とする。これらのオプションは、アイデア出し中に洗練の誘惑となる。
  • 高機能 ≠ 優れている。 制約はスピードと創造性の両方を促進する。実際のものをレンダリングできるツールは、それをするように誘惑するだろう。
  • ツールを好みではなくフェーズに合わせる: 個人の発散 → あなたにとって最速のもの(紙を含む)。グループでのアイデア出し → 全員が描けるようにホワイトボード(物理的またはデジタル)。改訂、共有、注釈が必要なもの → デジタルワイヤーフレームツール。インタラクティブなもの → ワイヤーフレームを離れている。プロトタイピングツールを使用し、その旨を伝える。
  • チーム参加テスト: デザイナーだけがツールを操作できる場合、それは初期フェーズには間違ったツールです。ワイヤーフレームは、PM、開発者、ステークホルダー全員が作成および編集できるため機能します。

必要なコンテキスト

  • 保留中の決定は何か — 精度は抽象的にではなく、決定に対して選択される。
  • 何がすでに検証済みか vs まだ未解決か。精度は確実性を超えてはならない。
  • 次に誰がレビューするのか、そして彼らは洗練度をどのように解釈するのか。
  • それがどれだけ長く残る必要があるか — 使い捨ての探索か、耐久性のあるリファレンスか。
  • 誰がそれを編集する必要があるか — 非デザイナーも貢献する必要がある場合、ツールの選択肢は狭まる。

評価手順

  1. 誰が / 目標 / 問題のメモを書く。書けないなら、停止する — それが発見である。
  2. 保留中の決定と、それに答えられる最も低い精度を特定する。
  3. ラダーに対して確実性を確認する:決定された以上に洗練されてレンダリングされているものはないか?
  4. コンセプトの数を数える。定義フェーズで3未満の場合、発散できていない。
  5. 得ているフィードバックを読む:フォントや色に関するコメントは、アーティファクトが過度にレンダリングされていることを意味する — レベルを下げる。
  6. アイデア出し中にツールがピクセルやCSSの微調整を提供していないことを確認する。
  7. 共有する前に、あなたなしでそれ自体が成り立つか確認する。

出力形式

Decision pending: <このアーティファクトが答えなければならないこと>
Who / goals / problem: <3つの答え>
Fidelity: <レベル> — because certainty is <検証済みのこと>
Concepts explored: <数>  (定義フェーズでは≥3)
Tool: <選択> — because <スピード / 編集可能性 / 貢献すべき人>
Next level when: <上のレベルへの移行を可能にする条件>

クイックリファレンス

状況ルール
新機能または製品No-fi/Low-fiから開始。収束前に≥3つの異なるコンセプト
どの精度を使うべきか不明精度を確実性に合わせる。迷ったら低く
フィードバックがフォントや色についてアーティファクトが過度にレンダリング — 精度を1段階下げる
構造が合意され、インタラクションを洗練中Mid-fiに上げる:実際のコンポーネント、実際のラベル、限定的なパレット
「リアルに見せて」という要求別のコンピューター/プロトタイプを作成。ワイヤーフレームを決して肥大化させない
開発者への引き継ぎLate-phase:注釈、矢印、完全なフロー、単独で完結
最初のアイデアが勝ち確に感じる危険信号 — 他の9つを生成する
ラウンド1完了、1つのお気に入り複数のコンセプトを結合して洗練。ロックする前にさらに一度発散
後期にどの程度詳細を追加するか重要な/新しいインタラクションのみ。限界効用逓減で停止
何かを描く前に最初のページに誰が / 目標 / 問題を書く
ツールの選択フローを中断しない最速のもの。コンポーネントライブラリがあり、微調整オプションがないこと
非デザイナーが貢献したいツールを渡す — ローフィデリティは全員が描くライセンスである
レビュワーが「これが最終デザインですか?」と尋ねる精度の調整ミス — アーティファクトを粗くするか、レビューを再構成する
早期にエンドユーザーにコンセプトを見せるLow/Mid-fiで構造とフローの質問には十分。インタラクション詳細にはプロトタイプのみ
コーディング開始後にプロジェクトがぐらつくワイヤーフレームが安価にするには遅すぎる — コーディングする前に次の変更をワイヤーフレーム化する

アンチパターン

間違い修正
仕様書 → 完成度の高いモック → コード、アイデア出しなし≥3つのLow-fiコンセプトを探索。リアリズムに投資する前に構造をテストする
探索中に洗練(フォント、色、ピクセル)1色、ラフな線。構造が承認されるまでスタイリングしない
1ラウンド後にお気に入りを昇格複数のコンセプトの強みを結合。収束/発散を交互に行う
「高忠実度のワイヤーフレーム」それはプロトタイプ/コンピューターだ — 別のアーティファクトとして構築する
ワイヤーフレームが作成者の説明を必要とする注釈、画面接続矢印、フローの全てのステップを含める
複数画面のフローの1画面だけをワイヤーフレーム化エントリーからイグジットまでワイヤーフレーム化。ギャップは画面の間にある
誰が/目標/問題のメモをスキップ最初のボックスの前に最初のページに3つの答えを書く
後期ワイヤーフレームに愛着を持つそれはアイデアの最終試験であり、トロフィーではない。専門家にカットさせる
ステークホルダーがブランディングを承認まずローフィデリティで構造をレビュー。意図しなくても精度は完成度をシグナルする
アイデア出し中にピクセル/CSS微調整のあるツール紙またはコンポーネントのみのワイヤーフレームツールに切り替える
Mid-fiで至る所にLorem Ipsum実際の見出し、ラベル、CTA。Loremは本文コピーのみ
1つのコンセプトの3つのコスメのバリエーション構造(レイアウト、フロー、階層)を変える。装飾ではない — そうでなければそれは1つのコンセプトである
収束のみの漏斗、再発散なし各カットの後、生存者に小さな発散パスを許可する(制御収束)
「理解させるために」インタラクティブ性を追加インタラクティブ性はそれをプロトタイプにする — 代わりに動作に注釈を付ける
ワイヤーフレームを成果物として扱う理解が出力であり、ファイルはその器である

関連スキル

状況併用
問題の定義

(以下、原文が切れている可能性がありますが、翻訳可能な範囲で翻訳しました)

Individual skills in this repo

This repo contains 1 individual skill — each has its own dedicated page.

関連スキル