Day 82:画面設計
Day 82では、アプリに必要な画面、ボタン、フォーム、データ項目、ユーザー操作を整理します。画面設計は、見た目を飾ることだけではありません。利用者が何を入力し、どのボタンを押し、操作のあとに何が起きるのかを決める作業です。
ここでは、Day 81の例として取り上げた「学習管理アプリ」を設計します。別のアプリを選んだ場合も、同じ手順で置き換えて考えられます。
画面設計で決めること
今回決める内容は、次の5つです。
- 必要な画面:アプリの情報や操作を、どの画面に配置するか決めます。
- ボタン:ボタンを押したときに何が起きるか決めます。
- フォーム:入力する項目や入力ルールを決めます。
- データ項目:画面で入力・表示するデータを決めます。
- ユーザー操作:画面を開いてから目的を達成するまでの流れを決めます。
画面を作る前にこれらを整理しておくと、「ボタンを押しても何も起きない」「入力したデータをどこに表示するかわからない」といった迷いを減らせます。
ステップ1:アプリの目的と最初の機能を確認する
画面設計に入る前に、Day 81で決めたアプリの目的と、最初の完成版に含める機能を読み返します。今回の例では、次の内容を前提にします。
- 目的:学習した内容と時間を記録し、履歴を振り返れるようにします。
- 最初の機能:記録の追加、一覧表示、削除、合計時間の表示を作ります。
- 後から検討する機能:記録の編集、検索、グラフ表示などは、基本機能の完成後に考えます。
最初の版に必要な画面や操作に集中し、まだ必要のない画面を増やさないことがポイントです。
ステップ2:必要な画面を決める
最初の版では、画面をたくさん作らず、ひとつのページに機能をまとめる方法が考えられます。学習記録の追加と履歴の確認を同じ画面で行えれば、画面移動を実装せずに基本機能を完成できます。
今回の画面構成は、次のようにします。
- アプリ名と短い説明:何をするアプリかを伝えます。
- 学習記録フォーム:学習内容、時間、日付、メモを入力します。
- 状態メッセージ:保存成功や入力エラーを知らせます。
- 合計時間:保存済みの学習時間を表示します。
- 学習履歴:記録を一覧表示し、各記録に削除操作を用意します。
記録が0件の場合も、画面に何もない状態にしません。「まだ記録がありません。学習内容を入力して記録しましょう」のような案内を表示すると、次の操作がわかりやすくなります。
ステップ3:画面を簡単な図にする
最初は、色や細かい装飾を考えず、画面の部品と順番を図にします。このような簡易的な画面案をワイヤーフレームと呼びます。
┌──────────────────────────┐
│ 学習管理アプリ │
│ 学習内容と時間を記録して振り返ります。 │
├──────────────────────────┤
│ 学習内容 [____________________] │
│ 学習時間 [____] 分 │
│ 学習日 [__________] │
│ メモ [____________________] │
│ [記録する] │
│ 状態メッセージ │
├──────────────────────────┤
│ 合計学習時間:○時間○分 │
│ 学習履歴 │
│ ・JavaScriptの配列 40分 [削除] │
│ ・関数の復習 30分 [削除] │
└──────────────────────────┘
この図では、入力欄のあとに記録操作があり、その下に結果を表示しています。画面を上から見たとき、利用者が迷わず記録を追加できる配置になっているか確認しましょう。
ステップ4:フォームの項目を決める
フォームでは、利用者が何を入力するかだけでなく、必須かどうか、どんな値を受け付けるかも決めます。
| 項目 | 入力形式 | 必須 | ルール |
|---|---|---|---|
| 学習内容 | テキスト | はい | 空欄や空白だけの入力は不可 |
| 学習時間 | 数値 | はい | 0より大きい数値 |
| 学習日 | 日付 | はい | 有効な日付を入力 |
| メモ | 複数行テキスト | いいえ | 自由入力 |
フォームのラベルは、入力欄の近くに表示します。プレースホルダーだけで入力内容を説明すると、入力後に説明が見えなくなるため、項目名をラベルとして表示するのが基本です。
ステップ5:ボタンの役割を決める
ボタンは、押したときの結果が利用者に想像できる名前にします。今回の最初の版で使うボタンは、主に次の2種類です。
- 「記録する」:入力内容を確認し、問題がなければ新しい記録を保存して一覧を更新します。
- 「削除」:対応する学習記録を削除し、一覧と合計時間を更新します。
「OK」や「実行」のような曖昧な文言より、操作の内容をそのまま表す名前がわかりやすいです。削除ボタンは、どの記録を削除するのかが明確になる配置にします。誤操作が心配な場合は、確認画面を加える方法もありますが、最初の版では操作を取り消せる仕組みを含めるか、確認ダイアログを使うか、どちらかを決めておきます。
ステップ6:データ項目と画面の対応を考える
画面に入力・表示する項目が、保存データのどの値に対応するかを整理します。今回の例では、次のようになります。
- 学習内容フォーム → `title`
- 学習時間フォーム → `minutes`
- 学習日フォーム → `date`
- メモフォーム → `note`
- 各記録を区別する値 → `id`
学習記録1件分のデータは、次のように表せます。
// 学習記録をJavaScriptのオブジェクトで表す
const studyRecord = {
id: crypto.randomUUID(), // 記録を区別するためのID
title: "JavaScriptの配列", // 学習内容
minutes: 40, // 学習時間(分)
date: "2026-11-08", // 学習した日付
note: "mapとfilterを復習", // 任意のメモ
createdAt: new Date().toISOString() // 記録を作成した日時
};JavaScript時間は画面で「40分」と表示しても、データとしては数値の40を保存します。数値で保存すると、合計時間を計算しやすくなります。
ステップ7:ユーザー操作の流れを書く
次に、利用者が画面を開いてから目的を達成するまでの流れを、順番に書きます。
- 利用者がアプリを開きます。
- アプリは保存済みの学習記録を読み込み、一覧と合計時間を表示します。
- 利用者が学習内容、時間、日付、必要ならメモを入力します。
- 利用者が「記録する」ボタンを押します。
- アプリは入力値を確認し、不備があれば該当する項目を案内します。
- 入力に問題がなければ記録を保存し、一覧と合計時間を更新します。
- 利用者が「削除」ボタンを押すと、選んだ記録を削除し、画面を更新します。
このように操作の流れを決めておくと、あとでイベント処理を実装するときに「何が起きるべきか」を確認できます。
ステップ8:状態ごとの表示を決める
画面は、通常時だけでなく、入力エラーや記録がない場合も設計します。
- 記録がない:空の一覧と、最初の操作を案内するメッセージを表示します。
- 入力エラー:不足している項目や、修正が必要な値を具体的に伝えます。
- 保存成功:記録が追加されたことを知らせます。
- 保存済みの記録がある:一覧と合計時間を表示します。
- 削除後:削除した記録を一覧から取り除き、合計を計算し直します。
エラーメッセージは「エラーです」だけでなく、「学習時間には0より大きい数値を入力してください」のように、どう直せばよいかを伝えます。
画面設計をHTMLの骨組みにする
画面設計をHTMLにするときは、まず必要な要素を配置します。ここではJavaScriptの処理を加える前の、画面の骨組みを示します。
<main>
<!-- アプリの目的が伝わる見出しと説明 -->
<header>
<h1>学習管理アプリ</h1>
<p>学習した内容と時間を記録して振り返ります。</p>
</header>
<!-- 学習記録を入力するフォーム -->
<section aria-labelledby="form-heading">
<h2 id="form-heading">学習を記録する</h2>
<form id="study-form">
<div>
<label for="study-title">学習内容</label>
<input
id="study-title"
name="title"
type="text"
required
maxlength="100"
>
</div>
<div>
<label for="study-minutes">学習時間(分)</label>
<input
id="study-minutes"
name="minutes"
type="number"
min="1"
step="1"
required
>
</div>
<div>
<label for="study-date">学習日</label>
<input
id="study-date"
name="date"
type="date"
required
>
</div>
<div>
<label for="study-note">メモ(任意)</label>
<textarea
id="study-note"
name="note"
rows="3"
maxlength="500"
></textarea>
</div>
<!-- フォームの入力内容を記録する -->
<button type="submit">記録する</button>
</form>
<!-- 入力エラーや保存成功を案内する場所 -->
<p id="status-message" role="status" aria-live="polite"></p>
</section>
<!-- 合計時間と記録一覧を表示する -->
<section aria-labelledby="history-heading">
<h2 id="history-heading">学習履歴</h2>
<p id="total-time">合計学習時間:0分</p>
<!-- JavaScriptで記録項目を追加する場所 -->
<ul id="study-list"></ul>
</section>
</main>
labelと入力欄を結び付けるため、forの値と入力欄のidを一致させています。これにより、項目名をクリックして入力欄へ移動でき、画面読み上げを使う利用者にも項目が伝わりやすくなります。
画面設計でのアクセシビリティと安全性
画面を使いやすくするには、見た目だけでなく、さまざまな利用者が操作できるかも考えます。
- 入力欄には、何を入力するか分かるラベルを付けます。
- エラーの内容を色だけで伝えず、文章でも示します。
- ボタンの名前は、操作内容が伝わる文言にします。
- 入力したメモなどを画面に表示するときは、HTMLとして実行させない方法を使います。
JavaScriptでユーザー入力を画面に表示するときは、基本的にtextContentを使います。入力値をHTML文字列として直接挿入しないようにします。また、maxlengthなどのHTML属性だけに頼らず、JavaScript側でも必要な入力確認を行う設計にします。
画面設計テンプレート
別のアプリを設計するときにも使えるテンプレートです。
アプリ名:
画面名:
画面の目的:
画面に表示する情報:
-
-
フォーム項目:
- 項目名:
入力形式:
必須か:
入力ルール:
ボタン:
- ボタン名:
押したときに起きること:
ユーザー操作の流れ:
1.
2.
3.
画面の状態:
- 初回表示:
- 入力エラー:
- 成功時:
- データがない場合:
保存するデータ:
-
-
Day 82のゴール
Day 82では、次のことができるようになっていれば十分です。
- 最初の完成版に必要な画面と部品を決められます。
- フォーム項目と入力ルールを説明できます。
- ボタンを押したときの動作を決められます。
- 画面と保存データの項目を対応させられます。
- 正常時、空の状態、エラー時の表示を考えられます。
- ユーザーが目的を達成するまでの操作の流れを書けます。
まとめ
Day 82では、学習管理アプリを例に、必要な画面、ボタン、フォーム、データ項目、ユーザー操作を設計しました。画面設計のポイントは、利用者が何を入力し、どの操作を行い、その結果がどこに表示されるかを具体的にすることです。
まずワイヤーフレームで画面の配置を決め、次にフォームのルールやボタンの動作、画面の状態を整理します。すべての機能を一度に盛り込まず、Day 81で決めた最初の完成版の範囲に合わせて設計しましょう。設計ができたら、次はその画面をHTMLやCSSで形にしていきます。
