Webが動く基本の流れ

普段使うWebサービスの裏側では、手元のブラウザ（クライアント）と、遠くにあるサーバが絶えずやり取りをしています。ブラウザが送る依頼をリクエスト、サーバが返す答えをレスポンスと呼び、この往復の共通ルールがHTTPです。

この往復は、ページを開くたびに起きています。読み込みが遅い、表示されないといった不具合も、往復のどの段階でつまずいたのかという視点で捉えられるようになりましょう。不具合の報告を受けたときも、往復のどの段階の問題かを切り分けて、エンジニアに具体的に相談できます。

なお、このHTTPに通信の暗号化を加えた安全版がHTTPSで、アドレス欄の鍵マークが目印です。入力フォームや会員機能を扱う画面では、情報を安全に送れることが前提になります。仕組みの名前として押さえておけば十分です。

画面をつくる3つの言語（HTML・CSS・JavaScript）

サーバから届くのは、ページの中身を記した文字データです。ブラウザがそれを読み取って画面に組み立てる処理をレンダリングと呼び、その組み立ての材料になるのが次の3つの言語です。

本講座でコードを書くことはありません。ただしFigmaで作るデザインは、最終的にこの3つで実装されます。色や余白の指定はCSSに、押したときの反応はJavaScriptに置き換わります。デザインレビューで実装者と話すときも、構造・見た目・動きのどの層を直したいのかを言い分けられると、修正指示が正確に伝わります。

サーバとデータをやり取りする（API・REST）

会員名や予約状況のように変わる情報を画面に出すには、その都度サーバへデータを取りに行きます。このとき、機能どうしがデータを決まった形式でやり取りする窓口をAPIと呼びます。

Webでよく使われるのがRESTという設計の考え方で、欲しいデータをURLで指定し、統一された形式でやり取りします。データが返るまでに時間がかかったり、そもそも該当データが無いこともあります。だから読み込み中の表示や、データが空のときの画面まで用意しておく必要があります。予約状況や在庫のように刻々と変わる情報を扱う画面では、この用意まで済ませておくと、抜け漏れのない設計になります。

このRESTでは、データへの操作を取得・作成・更新・削除の4種類に整理し、それぞれ決まった形式でやり取りします。共通ルールがあるおかげで、別々に作られた機能どうしでも噛み合います。予約サービスなら、予約一覧の取得、新規予約の作成、内容の更新、キャンセルによる削除が、この4操作に対応します。

ページ遷移の2つの作り方（SPAと従来型）

リンクを押したときの画面の切り替え方には、大きく2つの作り方があります。どちらで作るかによって、体感の速さや操作の感触が変わります。

従来型はページごとに全体を読み直し、SPA（シングルページアプリケーション）は最初に読み込んだあと必要な部分だけを差し替えます。SPAは画面遷移がなめらかな反面、初回の読み込みは重くなりがちです。予約フローのように画面を何度も行き来する体験では、この違いが操作感に直結します。設計するときは、SPAか従来型かをふまえて、遷移の見せ方や待ち時間の演出を選べます。

サイトを運用する仕組み（CMS）

公開後もお知らせやメニューを更新し続けるには、専門知識がなくても中身を書き換えられる仕組みが要ります。それがCMS（コンテンツ管理システム）です。

CMSでは、デザインの型（テンプレート）と中身（文章や画像）が分かれています。運営者は管理画面から中身だけを差し替え、ページが自動で組み上がります。テンプレートを設計するときは、文章の長さや画像の有無が実際にはばらつく前提で、どんな中身が入っても崩れないレイアウトを意識しましょう。とくに更新頻度の高いお知らせやブログのページでは、運営者が管理画面から無理なく更新できるレイアウトを提案できます。

デザイナーが押さえる技術的制約

デザインの一つひとつには、実装の手間と表示への影響がついてきます。デザイナーが先に押さえておきたい制約は、大きく3つです。

表示速度は大きな画像や凝った動きで落ち、離脱の原因になります。レスポンシブは同じHTMLをCSSが画面幅に合わせて組み替える仕組みで、PCとスマホの両方の見え方を設計します。そして存在しないデータは画面に出せません。実現できるかを早めにエンジニアへ確認することが重要です。提案の段階で表示速度やレスポンシブを織り込めると、実装後の大きな作り直しを避けられ、エンジニアからの信頼につながります。