「モックに近づける」を数値にする
YNT Works rootで試したデザイン占有率比較

1. 必要な情報はそろっていた。でも面白くなかった

以前のYNT Works rootにも、必要なアプリへのリンクと、制作ノートや信頼情報への経路はありました。等しい大きさのカードを並べたポータルは理解しやすく、カード型の構成そのものが悪いわけではありません。

ただ、目的も雰囲気も異なるアプリを同じ強さで並べると、一般的なポータルサイトに見えました。運営者自身がその結果を面白いと感じられなかったため、装飾を増やすことではなく、作品ごとの個性を入口から表現することを再設計の目標にしました。AdSenseの「有用性の低いコンテンツ」という判定も見直すきっかけの一つでしたが、Googleが視覚設計を原因としたとは考えていません。視覚的な磨き込みが審査結果や流入を改善するとも主張しません。

2. 「もっとモックに近づける」が曖昧だった

「もっと大きく」「少し右へ」「迫力が足りない」「モックに近づける」。方向は分かっても、この言い方だけでは、どの値をどれだけ直し、どこで完了とするかが決まりません。

同じCSSの文字サイズでも、書体、字形、行数で見た目の量は変わります。画像を広く見せれば、意図したcrop（構図を作るための切り取り）を壊すことがあります。期待した要素がすべて存在しても、大小や前後関係が違えば階層は再現できません。一方、単純なピクセル差分はアンチエイリアスや描画の細部にも反応します。

最後には人の目による判断が必要です。それでも、修正の大きさを測れる場面では、主観的な違和感を検証可能な値へ移す方が、試行錯誤を狭くできます。そこで使ったのが、アートボードに対する正規化占有率の比較です。

3. モックと実装を「占有率」で比較する

正規化とは、ピクセル数をそのまま比べるのではなく、基準となるアートボードやコンテナの幅・高さを1として位置と大きさを表すことです。画面サイズが違っても、構図の比率を同じ物差しで比較できます。

• left ratio: 要素の左端 ÷ アートボード幅
• top ratio: 要素の上端 ÷ アートボード高さ
• width ratio: 要素幅 ÷ アートボード幅
• height ratio: 要素高さ ÷ アートボード高さ
• area ratio: 要素面積 ÷ アートボード面積
• center X: 要素中心のX座標 ÷ アートボード幅
• center Y: 要素中心のY座標 ÷ アートボード高さ
• visible-area ratio: 実際に見えている要素面積 ÷ 要素全体の面積
• crop ratio: 見切れている面積 ÷ 要素全体の面積
• overlap ratio: 重なった面積 ÷ 比較対象に決めた要素面積
• safe-zone intersection: CTAや本文など、守る領域と視覚要素が交差している面積

たとえば、モックのタイトル高さ占有率が34%、実装が26%なら、差は「約31%小さい」ではなく「8パーセントポイント不足」と表します。これは方法を説明するための例であり、保存された本番測定値ではありません。

こうすると「タイトルをもう少し大きく」は、「タイトルの高さ占有率を現在値から約8ポイント増やす」という、範囲のある修正指示に変わります。実装後は同じ基準で再測定し、別の要素を不用意に動かしていないかも確認できます。

4. サイズだけでなく位置・crop・overlapを見る

中心位置

要素の中心Xと中心Yをアートボードに対して正規化すると、単なる「右寄り」「上すぎる」を方向と距離に分けられます。幅が合っていても中心がずれていれば、視線の流れは変わります。

見える面積とcrop

画像が多く見えることは、常に改善ではありません。編集的な構図では、被写体の一部を意図的に切ることで大きさや進行方向を作ります。意図したcrop、CSSやコンテナによる偶発的なclipping、透明画像に残った余白、viewportそのものによる見切れは分けて調べます。

overlap

タイトル、主被写体、地形、前景がどの程度重なるかで奥行きが生まれます。すべての要素があっても、その関係が失われると平坦に見えます。重なりを測ると、単一要素のサイズ調整だけでは直らない理由が見つかります。

safe zone

モックへの忠実さには限界があります。CTAや本文との衝突、ナビゲーションの欠落、focus indicatorの切断、操作部品の利用不能を起こしてまで参照画像を再現しません。モックは構図を導きますが、プロダクトの事実、読みやすさ、操作可能性は守ります。

5. 1枚の完成画像にしなかった

そらほしポータルのシーンでは、責任をUI shell、装飾用visual artboard、semantic UI、runtime behaviorに分けました。概念上の積層は、宇宙の背景、背面の表示文字、火星の地面、ローバー、前面の文字断片、意味を持つ説明、CTA、操作UIです。生のデザインモックやQAスクリーンショットを本番へ埋め込む構成にはしていません。

レイヤーを分けると、ローバーと地面のcropを別々に調整でき、背景と主被写体へ異なるmotionを与えられます。狭い画面では装飾断片だけを省き、画像がなくてもsemantic HTMLの見出し、説明、状態、CTAを残せます。CTAとfocusは画像内の見せかけではなく、実際のHTMLとして操作できます。

もう一つ有効だったのが、外側のmotion shellと、内側のvisual nodeを分ける形です。静的な配置とanimationが同じtransformの所有者を奪い合わないため、基準位置を保ったまま動きだけを合成できます。

6. 画像assetは master / derivative / mock に分けた

生成画像は、統合する前に、偽物または意味不明な文字、watermark、物体の重複、隣接レイヤーの混入、実際のalpha transparency、縁のhalo、途中で切れた物体、意図しない発光や影を確認します。BUILD TRACEで制御できない文字を含んでいたraster表現は、そのまま使わず、内容を管理できるローカルSVGへ置き換えました。

7. レスポンシブは「縮小」ではなく「優先順位の変更」

desktopだけのモックを、mobileのpixel fidelityの証拠にはできません。狭い画面では、構造の連続性、階層、読みやすさ、safe zone、操作を別の合格条件として確認します。

8. 画像やmotionがなくても操作できるようにする

visual imageryは装飾として扱えても、見出し、説明、状態、CTAはsemantic HTMLに残します。装飾画像が失敗しても、どのアプリか、主要な行動は何かが分かる構成です。

motionは場面を理解する唯一の手段にしません。reduced motionでは、途中のtransitionで停止させるのではなく、意味のある最終状態を表示します。視覚的な選択状態とkeyboard focusは別の関心事として扱い、scene navigationのためにfocus trapを作りません。linkやbuttonなどのinteractive descendants（内側の操作要素）は自分の入力を保持し、swipe判定より優先されます。

JavaScriptがなくても、静的なページ順の中にアプリ名、説明、直接のactionを残します。forced colors、200%相当のtext reflow、touch target、swipeと内側の操作要素の境界も、見た目の再現とは別に確認します。

視覚効果は理解を強化しても、理解や操作の唯一の手段にはしない。

9. 占有率比較で見つけやすくなったこと

YNT Works rootの調整では、タイトルのmass（画面内で感じる量）、主被写体のscale、center position、crop、overlap、前景と地面のbalanceを分けて見られるようになりました。単に「全部ある」と確認するだけでは見落としやすい、階層の平坦さを説明しやすくなります。

一般にこの比較は、被写体が見えすぎる・見えなさすぎる、copy-safe regionへの侵入、短いdesktopだけの衝突なども発見しやすくします。これらは検査できる例であり、すべてがYNT Works本番で発生したという主張ではありません。

10. 数字では決められないこと

占有率は万能なデザインscoreではありません。materialの質感、色の印象、texture、lighting、visual rhythm、意図した緊張感、brand impression、感情的な反応までは決められません。複雑な非矩形、blurやglowの広がり、font rasterizationも、単純な矩形だけでは正確に表せません。

占有率比較は、人間のデザイン判断を置き換えるものではない。曖昧な違和感を、検証・修正可能な状態へ変える補助線である。

11. 反省：実装を進める前に測るべきだった

visual explorationと高忠実度の実装を同時に進めすぎました。どのsourceを基準にするか、どのviewportをcanonicalな比較面にするかを先に固定し、title massもfont sizeを繰り返し調整する前に測るべきでした。生成画像は統合前に検査し、desktopの修正はshort desktopとnarrow modeへ必ず回帰確認する必要があります。

motion、cancellation、focus、reduced motion、fallbackも後から別々に足すのではなく、同じinteractionとして設計する方が一貫します。そして、validatorが通るという実装検証と、参照した構図に近いというデザイン検証は別のgateです。片方だけで完了にはできません。

12. 繰り返した作業をSkillにした

繰り返した比較手順は、design-mock-occupancy-auditというSkillへ一般化しました。デザイン参照と実装を正規化geometryで比較し、source evidenceを分類し、occupancy、center position、crop、overlap、safe zoneを測り、変更範囲の明確な修正指示へ変換するためのものです。モックを盲目的に再現せず、accessibilityとproduct truthを優先することも契約に含みます。

• STRUCTURED_SOURCE: 座標や寸法を構造化データから取得できる証拠
• USER_APPROVED: 人が承認し、比較基準として明示した証拠
• VISION_ESTIMATED: 画像を見て推定した証拠

VISION_ESTIMATEDは、画像上の境界や透明余白を含む推定です。正確なデザイン座標として表現してはいけません。この制作ノートは公開に役立つ契約だけを説明しており、private memory repositoryは公開しません。将来OSS化を検討できる候補ではありますが、公開repository、installable package、license選定、OSS releaseはまだ存在しません。

13. 検証済みと未検証を分ける

統合済みのYNT Works rootで確認した範囲には、repository/static validation、複数のresponsive browser viewport、horizontal overflow、image failure、keyboard behavior、reduced motion、forced colors、no-JavaScript behavior、external runtime/network boundary、root runtimeにCookieやStorageがないことが含まれます。

一方、physical iOS Safari、physical Android Chrome、専用環境でのLCP laboratory measurement、最終head専用のsecurity scan、公開後の自然導線によるfinal production verification、deployed commit identityは未検証です。Cloudflareのbuild成功はlive production verificationと同じではありません。

設計の説明でも、検証結果でも、「確認したこと」と「まだ確認していないこと」を同じ言葉でまとめないことが、公開後の判断を安全にします。