Figmaにできないこと

カンプ確認から、実装プレビュー確認へ

Figmaは設計や共有には強いツールです。しかし、Webサイトの読みやすさ、クリック感、スマホ表示、ページ導線は、実際のブラウザで触って初めて分かることがあります。クラウド、コンテナ、生成AIによって、実装プレビューを見ながら調整する進め方が現実的になっています。

概要

Figmaは、Web制作において非常に便利なツールです。

画面設計、色の整理、余白のルール、コンポーネント管理、デザイン共有、クライアント確認。こうした作業では今でも強力です。

ただし、Webサイトの使いやすさを判断するには、Figmaだけでは分からないことがあります。

実際のブラウザで表示し、スクロールし、クリックし、スマホ幅で確認して初めて分かることがあるからです。

これはFigmaが悪いという話ではありません。Webサイトは静止画ではなく、実際に読まれ、押され、移動されるものだからです。

Figmaが得意なこと

Figmaが得意なのは、実装前に画面の方向性を整理することです。

  • ページ全体の雰囲気
  • 色や余白のルール
  • 見出しやボタンのデザイン
  • コンポーネントの整理
  • 複数人でのレビュー
  • クライアントへの事前共有

特に、大規模なサービスやアプリUIでは、Figmaの価値は大きいです。

画面数が多く、ボタンや入力欄、モーダル、メニュー、状態変化などを整理する必要がある場合、Figmaでデザインシステムを作っておく意味があります。

また、制作会社、デザイナー、エンジニア、クライアントが分かれている場合にも、共通の確認場所として機能します。

Figmaだけでは分かりにくいこと

一方で、Webサイトの実際の使いやすさは、Figmaだけでは判断しにくい部分があります。

  • 実際の文字の読みやすさ
  • 長いタイトルの折り返し
  • 本文量が入ったときの余白
  • スクロールしたときの体感
  • クリックできる範囲
  • hoverや遷移の分かりやすさ
  • スマホでの見え方
  • ブラウザごとのフォント描画
  • 読み込み速度
  • 導線の自然さ

Figma上ではきれいに見えても、実際のHTMLにすると印象が変わることがあります。

特に日本語のWebサイトでは、タイトルの長さ、本文の行間、余白、スマホ表示での折り返しが読みやすさに大きく影響します。

見た目の静止画として整っていても、実際に読んだときに疲れる。クリックできる場所が分かりにくい。スクロールしたときに情報の流れが重い。こうした違和感は、実画面で見た方が早く分かります。

UXは静止画だけでは判断しにくい

UXは、見た目だけではありません。

読んで、押して、戻って、迷って、探して、スクロールして、問い合わせる。この一連の流れで判断するものです。

そのため、静止画のデザインカンプだけでは、実際の使いやすさを確認しきれません。

Webサイトは、画面の一部だけを見るものではありません。ページ全体を読み、リンクを押し、別ページへ移動し、また戻ることもあります。

特にコラムサイトやオウンドメディアでは、記事本文、目次、関連記事、カテゴリ、トップページ、記事一覧がつながって初めて意味を持ちます。

この導線の自然さは、Figmaの1画面だけでは判断しにくい部分です。

なぜ昔はカンプ確認が重視されたのか

それでも、これまでWeb制作では、FigmaやPhotoshopなどのデザインカンプを先に作り、確認してから実装する流れが一般的でした。

これは、実装前に見た目を固める方が安全だったからです。

以前は、実装した画面を本番とは別に安全に確認するだけでも、かなり手間がかかりました。

サーバーを用意し、設定を合わせ、必要なライブラリを入れ、データベースやファイル配置をそろえる。場合によっては、本番環境に近い状態を再現するだけで、制作作業とは別のインフラ作業が発生していました。

そのため、まずFigmaやPhotoshopなどでデザインカンプを作り、見た目を確認してから実装する流れには合理性がありました。

実装後に大きく直すより、事前に静止画で合意しておく方が安全だったからです。

いまは実装プレビューを作りやすくなった

しかし現在は、環境が大きく変わっています。

コンテナをはじめとする仮想化技術とクラウドインフラの普及により、本番とは別の検証環境を用意するハードルは大きく下がりました。

Cloudflare Pages、Vercel、Netlify、GitHub Actions、Dockerなどを使えば、実装した画面を本番に影響させず、プレビュー環境で確認できます。

つまり、昔は「実装して見せる」こと自体が重かった。いまは、実装プレビューを素早く作り、実際のブラウザで確認しながら直す進め方が現実的になっています。

これは、Web制作の確認方法そのものが変わってきているということです。

AIによって実装と修正の速度が上がる

さらに、生成AIやCodexのようなAIエージェントによって、HTMLやCSSの修正速度も上がっています。

以前であれば、デザインを修正し、実装者に伝え、HTMLやCSSを直し、再度確認するまでに時間がかかりました。

しかし現在は、実画面を見ながら、余白を詰める、色を少し薄くする、リンクだと分かるようにする、クリック範囲を広げる、スマホ表示を調整する、関連記事の見た目を変える、といった修正を短いサイクルで進められます。

この場合、Figmaで細かく詰めてから実装するより、先に実装プレビューを作り、ブラウザで見ながら調整した方が早い場面があります。

Figmaが不要になるわけではない

もちろん、Figmaが不要になるわけではありません。

大規模なアプリケーション、複数人開発、ブランド設計、デザインシステム、コンポーネント管理、複雑な画面遷移の整理では、Figmaは今でも有効です。

特に、開発チームとデザインチームが分かれている場合や、事前承認が必要な案件では、Figmaで画面を整理しておく意味があります。

ただし、すべてのWeb制作でFigmaを中心にする必要があるわけではありません。

小規模なWebサイト、コラムサイト、サービスページ、LP、オウンドメディア改善では、静止画カンプを細かく詰めるより、実装プレビューを見ながら判断した方が早いことがあります。

Time合同会社での考え方

Time合同会社では、Webサイトを「見た目の完成物」ではなく、実際に読まれ、クリックされ、改善され続ける情報基盤として考えています。

そのため、Figma上のカンプだけで判断するのではなく、実装されたHTMLをブラウザで確認しながら調整することを重視しています。

タイトルは長すぎないか。本文は読みやすいか。関連記事はクリックできると分かるか。スマホで余白が崩れていないか。トップページから記事へ自然に移動できるか。

こうした確認は、実画面で見た方が早く判断できます。

生成AIやCodexを使えば、実装と修正の反復はさらに速くなります。

Figmaで完成形を描いてから実装するのではなく、実装プレビューを見ながらUXを詰めていく。

AI時代のWeb制作では、この進め方がより現実的になっていくと考えています。

まとめ

Figmaは、Web制作において有効なツールです。

しかし、Figmaだけでは分からないことがあります。

実際の文字の読みやすさ、スクロール感、クリック範囲、スマホ表示、ページ間の導線、ブラウザでの見え方。これらは、実装されたWebサイトを触って初めて分かることがあります。

以前は、実装環境を用意すること自体が重かったため、デザインカンプを先に作って確認する流れには合理性がありました。

しかし現在は、クラウド、コンテナ、プレビュー環境、そして生成AIによって、実装したものを安全に確認し、すぐに修正する流れが作りやすくなっています。

Figmaで設計することと、実装プレビューで確認することは対立しません。

ただし、WebサイトのUXを判断するなら、最終的には実際のブラウザで見て、触って、違和感を潰すことが必要です。

これからのWeb制作では、静止画カンプだけでなく、実装プレビューを前提にした確認と改善がより重要になると考えています。