「UIは構造→視覚→文字の順で組み立てる」という進め方は、手を動かす前の指針としては役に立ちます。ところが、実際に組み終わったあとに「その順番を守れたのか」を確かめる方法がほとんど語られません。順番を守ったつもりでも、配色を詰めている途中で優先順位が入れ替わり、最終的に「色が強い要素」が一番目立つ画面になっている――これは珍しいことではありません。
構造→視覚→文字の順で組めたかどうかは、完成したUIから「色」「ぼかし（＝細部）」「強弱」を順に剥ぎ取り、それでも情報の優先順位が読み取れるかで判定できます。剥いだ状態で優先順位が崩れるなら、その順位は構造ではなく装飾が作っていたということです。判定はブラウザの開発者ツールだけで完結し、デザインツールも追加のプラグインも要りません。
この記事では、その剥ぎ取りテストを3本に整理します。それぞれ「何を剥ぐか」「何が合格か」「落ちたら最初に何をするか」まで書きました。判定の根拠にはW3CのWCAG 2.2、Nielsen Norman Group、Apple Human Interface Guidelines、Material Design 3を使っています。掲載しているコードはすべて実際のブラウザ（Chromium 151）で実行し、出力を確認したものです。
この記事で「構造・視覚・文字」が指すもの
3つの言葉は人によって指す範囲が違います。判定の話をする前に、この記事での定義を1つに固定します。
| 段階 | この記事での中身 | この記事では扱わないもの |
|---|---|---|
| 構造 | 要素の配置・グルーピング・情報の優先順位 | サイト全体のページ階層（情報設計） |
| 視覚 | 色・コントラスト・画像・装飾 | 配色理論とパレットの組み方 |
| 文字 | タイポグラフィ（サイズ・太さ・行間・階層比） | コピーライティング（文章そのもの） |
とくに紛らわしいのが「文字」です。ここでは文字＝タイポグラフィとし、コピーライティング（何と書くか）は範囲外とします。文言の良し悪しは剥ぎ取りテストでは判定できないためです。
もう一つ先に断っておきます。「構造→視覚→文字」という語順そのものを規定した公的な標準や一次資料は存在しません。これは当サイトの整理です。ただし「装飾に入る前に階層を決めておく」という原則には裏付けがあります。Nielsen Norman Groupの「Visual Hierarchy in UX: Definition」（Kelley Gordon、2021年1月17日／2026年8月2日確認）は、結論部で「デザインを始める前に、ビジュアルからいったん離れてコンテンツの階層と伝えたい要点を定義せよ」と述べています。本記事はこの原則を、着手前の心構えではなく着手後の判定手順に置き換えたものです。
着手する前にウィンドウ幅・コンテンツ幅・カラム数といった数字を決めておく話は別記事にあります。デザインカンプ前に決めるWebデザインのルールで先に土台を決めてから、この記事の判定に進むと接続がきれいです。
順番を守れたかは、作り終えてからしか分からない
着手前のチェックリストは「これから何をするか」の宣言です。宣言は守れているかどうかを自分では証明しません。実際の画面は、宣言のあとに入れた画像・実データ・長い見出し・アイコンによって、宣言とは違う優先順位を持ってしまいます。
Nielsen Norman Groupの同記事は、Spotifyの画面をぼかした例を挙げたうえで「テンプレートを設計するだけでは足りない。そこに入るコンテンツも考慮しなければならない」と書いています。強い色の写真1枚が、意図していない要素をページの主役にしてしまう。テンプレートの設計が正しくても、中身が入った瞬間に階層が崩れるという指摘です。
だから判定は、完成した実物に対して行う必要があります。ここで使う3つのテストは、いずれも「情報を減らして、それでも残るものを見る」という同じ発想です。減らしても優先順位が残るなら、その順位は構造が作っている。減らした瞬間に消えるなら、装飾が作っていたということになります。
なお、この考え方はアクセシビリティの達成基準と根が同じです。色が見えない・文字を拡大している・支援技術で読んでいるといった状況は、どれも「一部の手掛かりが使えない状態」だからです。制度としての全体像を知りたい場合はWebアクセシビリティの基本｜WCAG 2.2と2024年法改正への対応を先に読んでおくと、以下の根拠が読み解きやすくなります。
剥ぎ取りテストの3層と、それぞれ何を検出するか
3本のテストは剥ぐ対象が違い、露呈する欠陥も違います。まず全体像を押さえます。
| テスト | 剥ぐもの | 露呈する欠陥 |
|---|---|---|
| 色剥ぎ | 色相・彩度 | 優先順位を色だけで作っていた |
| ぼかし | 文字と細部の判読性 | グルーピングと視覚的重心のズレ |
| 強弱剥ぎ | サイズ・太さ・文字色 | 見出しと本文の区別が装飾頼み |
それぞれの根拠と合格条件は次のとおりです。
| テスト | 根拠にする基準 | 合格の条件 |
|---|---|---|
| 色剥ぎ | WCAG 2.2 達成基準 1.4.1「色の使用」 | 最初に目に入る要素が入れ替わらない |
| ぼかし | NN/g「The Squint Test」 | 半径5pxと10pxで意図どおりの重心 |
| 強弱剥ぎ | WCAG 2.2 達成基準 1.3.1「情報及び関係性」 | どこが見出しか読み取れる |
準備は共通です。判定したいページをブラウザで開き、開発者ツール（WindowsならF12、macOSならCommand+Option+I）を開いてConsoleタブを選びます。以下のCSSはConsoleに貼るのではなく、Elementsタブで html 要素にスタイルを追加するか、Consoleで次の1行を実行して差し込みます。
document.head.insertAdjacentHTML('beforeend',
'<style id="strip-test">html { filter: grayscale(1) !important; }</style>');この方法で入れたスタイルはページのCSSファイルを一切書き換えません。document.getElementById('strip-test').remove() で取り消せますし、リロードすれば元に戻ります。本番サイトに対してそのまま実行しても保存されることはありません。
テスト1｜色を剥いで優先順位が残るか
最初に剥ぐのは色です。ページ全体をグレースケールにして、それでも「最初に目が行く要素」が変わらないかを見ます。
当て方
差し込むCSSは1行です。
html { filter: grayscale(1) !important; }正しく当たっていれば、Consoleで getComputedStyle(document.documentElement).filter を実行すると grayscale(1) が返ります。何も返らない（none のまま）なら、サイト側のCSSに負けているので !important が付いているかを確認してください。
合否ライン
グレー1色にした状態で画面を数秒だけ見て、目が最初に止まった要素を1つ書き留めます。それが色付きのときと同じで、かつ意図した最重要要素なら合格です。順位が入れ替わったなら、その優先順位は色が作っていたことになります。判断が割れるときは、色付きの状態と並べたスクリーンショットを別の人に見せて、それぞれ「最初に目が行った要素」を1つだけ挙げてもらうと差が出ます。
この合否ラインはW3CのWCAG 2.2 達成基準1.4.1に対応します。原文は「色が、情報を伝える、動作を示す、反応を促す、又は視覚的な要素を判別するための唯一の視覚的手段になっていないこと」です（W3C「Understanding SC 1.4.1: Use of Color」、2026年8月2日取得）。色を使ってはいけないという意味ではありません。色が唯一の手掛かりになっていると失格という意味です。
Nielsen Norman Groupも同じ立場で「視覚的階層を伝えるのに色だけに頼ってはならない。色覚に特性のある人は、特定の色の組み合わせの違いを知覚できないことがある」と書いています。「CTAボタンは目立つ色にする」という定番の指針は、それ自体は誤りではないものの、色以外の手掛かりを1つ以上持たせて初めて成立すると読み替えてください。
落ちたときに足すもの
色を剥いだら主役が消えた場合、真っ先にやりたくなるのは「もっと目立つ色にする」ですが、それでは同じテストにまた落ちます。足すのは色以外の手掛かりです。
- サイズを上げる（面積で差をつける）
- 周囲の余白を増やして孤立させる
- 枠線・背景の面を与えて領域として区切る
- アイコンや矢印など形の手掛かりを添える
- ラベルの文言そのものを具体的にする
色そのものを見直す段階に来たら、色彩設計の基本｜Webデザインに役立つ配色理論とカラーパレット実装例で配色の組み立て方を確認してください。この記事は色を「選ぶ」ことは扱いません。
「色だけリンク」は機械的に見つけられる
色剥ぎテストで最も再現性の高い不合格が、本文中の「下線のないリンク」です。W3Cはこれを失敗事例F73として明示的に挙げています（2026年8月2日取得）。文中のリンクから下線を外し、色の差だけを残すと失格になる、という内容です。
ただしF73には条件があります。同じ色相でも明度差（コントラスト比）が3:1以上あれば通り、太字にしてあれば「太字は色に依存しない」ため失格になりません。この条件をそのまま実装したのが次のスニペットです。Consoleに貼って実行します。
(() => {
const ROOT = 'main'; // 本文コンテナのセレクタに置き換える
const root = document.querySelector(ROOT) || document.body;
const lum = c => {
const [r, g, b] = c.match(/[\d.]+/g).slice(0, 3)
.map(v => v / 255)
.map(v => v <= 0.03928 ? v / 12.92 : Math.pow((v + 0.055) / 1.055, 2.4));
return 0.2126 * r + 0.7152 * g + 0.0722 * b;
};
const ratio = (a, b) => {
const [hi, lo] = [lum(a), lum(b)].sort((x, y) => y - x);
return (hi + 0.05) / (lo + 0.05);
};
const links = [...root.querySelectorAll('p a, li a')]
.filter(a => !a.closest('footer, aside, nav'));
const risky = links.filter(a => {
const c = getComputedStyle(a), pa = getComputedStyle(a.parentElement);
return c.textDecorationLine === 'none'
&& c.fontWeight === pa.fontWeight
&& ratio(c.color, pa.color) < 3;
});
console.log({ checked: links.length, colorOnly: risky.length,
sample: risky.slice(0, 3).map(a => a.textContent.trim().slice(0, 20)) });
})();合否ラインは colorOnly が0であることです。1以上なら、その要素は色覚に特性のある読者からリンクだと分からない可能性があります。当サイトのデザインカンプ前に決めるWebデザインのルールの本文コンテナを ROOT に指定してChromium 151で走らせた結果と、下線を外したリンクをわざと1本混ぜた検証用HTMLでの結果が次のとおりです。
// 当サイトの記事本文（ROOT を本文コンテナに指定して実行）
{ checked: 14, colorOnly: 0, sample: [] }
// 下線を外した色だけリンクを1本混ぜたテスト用HTML
{ checked: 3, colorOnly: 1, sample: [ '色だけのリンク' ] }ROOTを指定せずページ全体に対して走らせないでください。同じスクリプトを document 全体に当てたところ、当サイトでは149本中147本が「色だけリンク」と判定されました。ヘッダー・フッター・サイドバーのナビゲーションは下線を持たないのが普通で、F73も「ナビゲーションのように、ページのデザインや文脈から視覚的に明らかなリンクもある」と例外に触れています。判定対象は本文中のリンクに限ります。
なおMaterial Design 3のタイポグラフィ指針も、リンクの扱いを「ハイパーリンクのテキストには下線も必要」と明記しています（Material Design 3「Typography: Applying type」、2026年8月2日取得）。W3Cの失敗事例とGoogleのデザインシステムが同じ結論に着地している箇所です。
テスト2｜ぼかして視覚的重心を見る
2本目は文字を読めなくします。目を細めて画面を見る「スクイントテスト」をCSSで再現するもので、Nielsen Norman Groupが前掲記事のなかで手順と半径まで示している方法です。文字が読めなくなると、残るのは面・かたまり・明暗だけになります。そこに現れるのが、読者が実際に最初に認識する順序です。
当て方
半径を3段階に変えながら、それぞれで画面を見ます。
body { filter: blur(5px) !important; }
body { filter: blur(10px) !important; }
body { filter: blur(20px) !important; }色剥ぎと違って対象が body なのは、html にかけるとスクロールバーやページ背景まで巻き込んで見づらくなるためです。3つを同時に入れるのではなく、1つずつ差し替えます。当たっていれば getComputedStyle(document.body).filter がそれぞれ blur(5px) blur(10px) blur(20px) を返します（Chromium 151で確認）。
3段階の読み分け
半径ごとに見るものが違います。Nielsen Norman GroupはSpotifyの画面を例に、5pxと10pxではグルーピングが意図どおりに働き「Recently Played」が最も目立つが、20pxでは意図しない階層が現れ、再生履歴の1項目が強い色のせいでページ内で最も目立つ要素になった、と説明しています。
| 半径 | 見るもの | 合否の判断 |
|---|---|---|
| 5px | 要素のまとまり方 | 意図したグループが1つの塊に見える |
| 10px | 目立ち順 | 最重要要素が最も濃く見える |
| 20px | 実際の視覚的重心 | 別要素が勝つなら要調整 |
合否ラインは5pxと10pxで意図どおりのグルーピングと目立ち順になっていることです。20pxで別の要素が勝つのは即不合格ではありません。20pxはかなり乱暴な条件で、ここまで潰しても残るのは「最も面積が大きく、最もコントラストの強い塊」だけになります。20pxで勝った要素が意図した主役と違うなら、それはいま実際に読者の視線を最初に受け止めている要素だと考えてください。
テンプレートではなくコンテンツを疑う
20pxで意図しない要素が勝ったとき、レイアウトのCSSを直しても解決しないことがよくあります。原因が中身の側にあるためです。
- 彩度の高い写真が1枚だけ入っている
- サムネイルが実データになった途端に暗く重くなった
- 本文の1段落だけが極端に長く、大きな灰色の面になっている
- 広告・バナー枠がコンテンツより強い面を持っている
この場合の打ち手は、画像側のコントラストを落とす、面積を減らす、逆に主役側の面積を増やす、のいずれかです。ダミーデータのカンプでは絶対に出ない不具合なので、必ず実データが入った状態でぼかしてください。テンプレートだけを設計しても足りない、というNN/gの指摘はここに直結します。
テスト3｜強弱を剥いで構造が残るか
最後に、文字のサイズ・太さ・色をすべて同じ値に潰します。ここで「どこが見出しでどこが本文か」がまだ読み取れるなら、構造が装飾に依存していないということです。
当て方
* { font-size: 16px !important; font-weight: 400 !important; color: #000 !important; }当サイトの記事ページで実行すると、見出しも本文も font-size: 16px / font-weight: 400 / color: rgb(0, 0, 0) に揃うことを確認しています（Chromium 151、1280×900）。この状態で残るのは、余白・行送り・行頭の位置・並び順だけです。
合否ラインは見出しの位置が指し示せることです。指せないなら、その見出しはサイズと太さだけで見出しに見えていたことになります。打ち手は見出しの上下の余白を非対称にする（上を厚く、下を薄く）、見出しの前に区切り線や小さなラベルを置く、といった構造側の手当てです。
見出しの実寸を数えて階層と突き合わせる
目視だけでは「h2とh3の差が本当に付いているか」までは分かりません。実寸を出します。Consoleに貼って実行してください。
(() => {
const ROOT = 'main'; // 本文コンテナのセレクタに置き換える
const root = document.querySelector(ROOT) || document.body;
const hs = [...root.querySelectorAll('h1,h2,h3,h4,h5,h6')]
.filter(h => !h.closest('footer, aside, nav'));
const lv = {};
hs.forEach(h => (lv[+h.tagName[1]] ||= []).push(parseFloat(getComputedStyle(h).fontSize)));
const med = a => [...a].sort((x, y) => x - y)[Math.floor(a.length / 2)];
console.table(Object.keys(lv).map(Number).sort()
.map(l => ({ level: 'h' + l, count: lv[l].length, px: med(lv[l]) })));
})();先ほどと同じ記事の本文コンテナを ROOT に指定して実行した実測値です（Chromium 151、1280×900）。
[ { level: 'h2', count: 12, px: 24 },
{ level: 'h3', count: 11, px: 21.06 } ]合否ラインはレベルが下がるにつれて実寸が単調に小さくなることです。逆転を検出できることも確かめてあります。h2に18px、h3に28pxを指定した検証用HTMLで同じスクリプトを走らせると次を返しました。
[ { level: 'h2', count: 2, px: 18 },
{ level: 'h3', count: 2, px: 28 } ]対象を本文に絞らないと必ず誤判定する
このスクリプトで最も間違えやすいのが対象範囲です。ROOT をページの主要領域（main）にしたまま footer, aside, nav の除外を外して当サイトの記事ページで実行したところ、拾う見出しの数が24個から31個に増えました（Chromium 151で実測）。増えた7個はサイト共通のフッターや、サイドバーの「人気記事」といったブロックの見出しです。
サイト共通パーツの見出しは、記事本文とは別の設計判断でサイズが決まっています。これを混ぜて中央値を取ると、本文の階層が壊れていなくても数字が乱れます。ROOT は必ず本文コンテナに合わせ、フッター・サイドバー・ナビゲーションは除外してください。
このページのスニペットを全体 (() => { ... })(); で包んであるのは、Consoleで2回目を実行したときに Uncaught SyntaxError: Identifier 'ROOT' has already been declared で止まるのを避けるためです。実際に包まない形で2回実行するとこのエラーが出ることを確認しています。セレクタを変えて何度も試す使い方をするので、この形にしてあります。
このテストが根拠にしているもの
WCAG 2.2 達成基準1.3.1の原文は「表現を通じて伝達されている情報、構造、及び関係性は、プログラムによる解釈が可能であるか、又はテキストで提供されていること」です（W3C「Understanding SC 1.3.1: Info and Relationships」、2026年8月2日取得）。W3Cは意図の説明で「視覚的または聴覚的な書式によって暗示されている情報と関係性が、表現形式が変わっても保たれること」と述べています。強弱剥ぎテストは、この「表現形式が変わった状態」を手元で作り出す操作にあたります。
Apple Human Interface Guidelinesも同じ観点を持っています。タイポグラフィの章に「重要な情報を強調し、階層を把握できるよう、フォントの太さ・サイズ・色を必要に応じて調整する。ただし、利用者が文字サイズを変更したときにも、テキスト要素の相対的な階層と視覚的な区別が保たれるようにすること」とあります（2026年8月2日取得）。文字サイズが利用者側で変わっても階層が壊れないこと――強弱剥ぎテストはその極端なケースを先に試している、という位置づけです。
見出しと本文のサイズ比そのものをどう決めるかは、この記事の範囲外です。値の決め方はタイポグラフィの基本とデザイン活用術にまとめてあります。
落ちたときにどう直すか
3本のテストで出る不合格は、症状ごとに打ち手が決まっています。
| 症状 | 原因 | 最初にやること |
|---|---|---|
| 色を抜くと主役が沈む | 優先順位が色だけで作られている | サイズか余白で差をつける |
| 色を抜くと全部が同じ強さ | コントラストの段階が足りない | 強い要素を2つまでに絞る |
| ぼかすとまとまりが崩れる | 余白が均一で境目がない | グループ内外の余白差を作る |
| ぼかすと画像が主役になる | 実データの彩度が想定より強い | 画像の面積かコントラストを下げる |
| 強弱を抜くと見出しが消える | 見出しが装飾でしか成立していない | 見出し前後の余白を非対称にする |
| 見出しの実寸が逆転する | 個別指定がCSSの後段で上書きされた | 階層ごとの値を1か所にまとめる |
どの打ち手にも共通するのは「強い要素を増やさない」ことです。落ちた箇所を目立たせようとして色や太字を足すと、他の要素との差が縮んで別のテストに落ちます。Nielsen Norman Groupは前掲記事で、階層を作るときの上限を数値で示しています。
- 複雑でない一般的なデザインでは、色は主要2色・補助2色に絞る
- 複雑なデザインでも、コントラストの段階は3つまで
- サイズは小・中・大の3段階まで
- 「大きい」扱いにする要素は最大2つまで
ひとつ注意があります。同じ記事は本文サイズの目安を「14px〜16px」としていますが、当サイトは全プロジェクトで最小フォントサイズを16pxと定めているため、この下限値はそのまま採用していません。段階の数（3つまで）と比率の考え方は使い、絶対値は自分たちの下限に合わせてください。数値をそのまま写すのではなく、根拠と自分たちの前提の両方を見て決める箇所です。
判定結果をチームに共有するときは、「なんとなく弱い」ではなく「グレースケールでCTAが3番目に落ちた」と症状で書きます。言語化そのものを鍛えたい場合はデザインを言語化する練習帳が対になります。この記事が操作で示すものを、あちらは言葉で示す構成です。
この判定でカバーしていない範囲
剥ぎ取りテストが判定するのは「情報の優先順位が構造に載っているか」だけです。合格しても、寸法・操作・配色は別々に測る必要があります。次に測るものと、その手順をまとめた記事の対応は以下のとおりです。
タップ領域の寸法・コントラスト比・320px幅での破綻といった数値を出したいなら、UIの合否を数値で出す｜タップ領域・コントラスト・320px幅の実測手順へ。この記事は数値を1つも測っていません。
ナビゲーションがキーボードだけで操作できるかを測るなら、ナビゲーションの合否をキーボードで出す｜到達・可視・状態の実測手順へ。この記事は入力デバイスを扱っていません。
要素同士の比率が根拠を持っているかを検算したいなら、黄金比・白銀比・白金比の使い方へ。剥ぎ取りテストは比率の良し悪しを判定しません。
UIの原則そのものを体系立てて知りたいなら「デザイン理論」とは？UI/UXデザインの質を上げる6つの基本原則、画面ではなくサイト全体のページ階層を組む話はサイト構造の設計手順が受け持ちます。
手を動かして目を慣らしたい場合はFigma模写 #7｜配色センスが身につく3色デザイン練習が向いています。色数を絞った状態で作ると、そもそも色剥ぎテストに落ちにくい設計になります。並びの検討にはCSS Gridジェネレーターを使ってグリッドを実際に組んでみるのが早道です。
最後にもう一点。剥ぎ取りテストはユーザーテストの代わりにはなりません。Nielsen Norman Groupが前掲記事の結論で挙げている事後の確認は「対象ユーザーとのテスト」です。剥ぎ取りテストは、そこへ持ち込む前に自分で機械的に落とせる欠陥を落とすための工程だと考えてください。
判定はできたが直し方の判断が付かない、あるいは実装ごと見直したいという段階になったら、制作の相談先も用意しています。
よくある質問（FAQ）
Q. この記事でいう「構造・視覚・文字」はそれぞれ何を指しますか？
構造は要素の配置・グルーピング・情報の優先順位、視覚は色とコントラストと画像や装飾、文字はタイポグラフィ（サイズ・太さ・行間・階層比）を指します。文章の内容そのものを指すコピーライティングは、剥ぎ取りテストでは判定できないためこの記事の範囲外です。なお「構造→視覚→文字」という語順を規定した公的な標準は存在せず、これは当サイトの整理です。
Q. グレースケールにするだけで階層の問題が分かりますか？
色を唯一の手掛かりにしている箇所は確実に露呈します。WCAG 2.2の達成基準1.4.1が禁じているのは「色が唯一の視覚的手段になっていること」なので、グレー1色にして意味が取れなくなる箇所はそのまま不合格候補です。ただしコントラスト比が足りているかどうかは別の基準で、グレースケール化では判定できません。数値としてのコントラスト比は別の手順で測ってください。
Q. ぼかしの半径はいくつが正しいですか？
Nielsen Norman Groupが例として挙げているのは5px・10px・20pxの3段階で、この記事もそれに準じています。合格ラインは5pxと10pxで意図どおりのグルーピングと目立ち順になっていることです。20pxで別の要素が勝つのは即不合格ではなく、「そこが実際の視覚的重心になっている」という読み取り材料として扱います。数値自体が規格で定められているわけではないので、自分たちの画面サイズに合わせて調整して構いません。
Q. 見出しの実寸が階層と逆転していたら必ず直すべきですか？
h要素の階層が正しく組まれていれば、支援技術や検索エンジンには構造が伝わるため、逆転していても情報そのものは失われません。問題になるのは視覚で読んでいる人で、この人たちは実寸の差で階層を判断しています。つまり「即バグ」ではなく「視覚利用者に階層が伝わらない状態」です。ヘッダーやフッターなどページ共通パーツで意図的に実寸を調整している場合もあるため、まず本文コンテナに絞って測り、本文の中で逆転していたら直す、という順序が実務的です。
Q. ワイヤーフレームは白黒でなければいけませんか？
そのような規範はありません。Nielsen Norman Groupの「UX Prototypes: Low Fidelity vs. High Fidelity」（Kara Pernice、2016年12月18日／2026年8月2日確認）は、白黒のスケッチやワイヤーフレームを低忠実度の一例として挙げているだけで、「白黒で十分」とは述べていません。同記事は忠実度をインタラクティビティ・ビジュアル・コンテンツの3つの領域に分け、それぞれで高低が独立して変わりうるとしています。白黒にする狙いが「色に判断を引っ張られないため」なら、この記事の色剥ぎテストが同じ役割を後工程でも果たします。
Q. 順番どおりに作れなかった場合は、やり直しですか？
やり直す必要はありません。この記事の立場は「順番は主張ではなく判定で確かめるもの」です。色から作り始めていても、完成品が3本の剥ぎ取りテストに通るなら、結果として優先順位は構造に載っています。逆に順番どおりに進めたつもりでも、実データを入れた段階でテストに落ちることは普通にあります。判定の対象は工程ではなく成果物です。
Q. 剥ぎ取りテストはユーザーテストの代わりになりますか？
なりません。Nielsen Norman Groupが視覚的階層の記事の結論で挙げている事後確認は「対象ユーザーとのテスト」で、剥ぎ取りテストはその前段に置く自己点検です。ブラウザだけで再現でき、判定者が変わっても同じ結果になる範囲――色への依存、グルーピングの崩れ、見出しの装飾依存――を先に潰しておくことで、ユーザーテストの時間を本来の課題に使えます。