【アプリ設計】使いやすさは、画面を作る前に決まる〜ノンデザイナーのためのIAとデザインシステム〜

KAWAI

2026年8月30日 09:47

AIに頼めば、見栄えのよいアプリ画面は数分で作れるようになりましたが、その画面に「必要な情報が揃っているか」「迷わず操作できるか」「別の画面と同じルールで動くか」は、見た目だけでは判断できません。

この記事では、アプリの土台となるIA（情報アーキテクチャ）と、判断を繰り返し使うためのデザインシステムを、レストラン予約アプリの例でつなげて解説します。

読み終えるころには、FigmaやAIを開く前に作るべき「情報・導線・部品の設計図」を、自分で確認できるようになります。

アプリを企画する事業責任者、ディレクター、エンジニア、AIでアプリを作りたいノンデザイナーに向く内容です。

この記事は全文無料（期間限定）で閲覧できます。

見出し画像はAIで生成しました。
プロンプトは下記の記事に掲載中。
毎日プロンプトは増えていきます。

なぜ、画面を描く前に成否が決まるのか
IAは「情報の住所と道順」を決める
デザインシステムは「判断を再利用する仕組み」
Atomic DesignでUIを部品から組み立てる
予約アプリを、画面の前から設計してみる
SmartHR・Apple・Googleなどは何を共通化しているか
制作前チェックリストで設計を確認する

急いで実践したい方は「5. 予約アプリを、画面の前から設計してみる」と「7. 制作前チェックリストで設計を確認する」から読んでください。

【無料ウェビナーのお知らせ】

「なんかダサい」アプリのUIデザインを、
Claude Codeに直させる60分

🔽 申し込みはこちら
既に109名の方が申し込み済です。

なぜ、画面を描く前に成否が決まるのか

結論から言えば、アプリの使いやすさを左右する大部分は、配色や装飾より前の構造とルールで決まります。

たとえば、予約を変更したい人が「予約履歴」「マイページ」「設定」のどこへ進めばよいか分からない場合、ボタンを美しくしても迷いは消えません。

同じ意味の操作が、ある画面では「確定」、別の画面では「保存」、さらに別の画面ではチェックマークだけで表されていれば、ユーザーは画面ごとに意味を学び直すことになります。

これは装飾の問題ではなく、情報の置き場所と操作ルールの問題です。

アプリを家にたとえるなら、ビジュアルデザインは内装ですが、IAは間取りと案内表示、デザインシステムはドアや照明を同じ考え方で作るための建築ルールに当たります。

内装から先に作ってしまうと、後から動線を直すために壁まで壊すことになりかねません。

「画面を作る前に決まる」とは、最初の設計で未来を完全に予言するという意味ではなく、後から直すと影響が大きい判断を先に揃えるということです。

IAは「情報の住所と道順」を決める

IAとはInformation Architectureの略で、日本語では情報アーキテクチャまたは情報設計と呼ばれます。

SmartHR Design Systemは、情報設計を「情報を整理し、構造化すること」と説明し、主な作業として分類・命名・関係性の定義を挙げています。

アプリに置き換えると、次の3つを決める仕事です。

分類する： どの情報を同じグループとして扱うかを決める
命名する： ユーザーが理解できる言葉で機能や情報へ名前を付ける
関係性を定義する： 何が親で、何が子か、どの操作からどこへ移るかを決める

レストラン予約アプリなら、「店舗」「メニュー」「空席」「予約」「利用者」などが登場する情報です。

さらに「店舗には複数のメニューがある」「予約は店舗・日時・人数・利用者と結び付く」といった関係を整理します。

ここが曖昧なまま画面を作ると、「コース」と「プラン」が混在したり、予約変更が店舗詳細とマイページの両方に置かれたりします。

SmartHRは情報設計の具体的なアウトプットとして、ユーザー業務の説明、概念モデル、オブジェクトモデル、画面同士の呼び出し関係、メインナビゲーションの5種類を公開しています。

ノンデザイナーが最初から専門的な図を作る必要はありませんが、少なくとも登場する名詞・できる操作・情報同士のつながりは、画面より先に書き出すべきです。

デザインシステムは「判断を再利用する仕組み」

デザインシステムは、色見本やボタン集だけではありません。

「私たちは何を大切にするか」という原則から、色・文字・余白などの値、UIコンポーネント、よくある操作パターン、文章、アクセシビリティ、実装コードまでをつなぐ仕組みです。

IBMのCarbon Design Systemも、再利用できるコンポーネント、パターン、ガイダンス、コードを組み合わせ、一貫した体験を効率よく作るための基盤と説明しています。

デザインシステムの価値は、毎回ゼロから考えなくてよいことだけではありません。

「この操作にはどの部品を使うか」「エラーはどう伝えるか」「重要な操作を何色にするか」といった設計判断そのものを保存できる点にあります。

たとえば「送信ボタンの青」を単なる色番号として持つより、「主要操作の背景色」と意味を付けて管理すれば、ブランドカラーを変えても役割は保てます。

このような値はデザイントークンと呼ばれ、色、文字サイズ、余白などの判断をデザインツールとコードの間で共有するために使われます。

W3C Design Tokens Community Groupは2025年10月、ツール間でデザイントークンを交換するための最初の安定仕様を公開しており、デザインと実装を同じ判断でつなぐ基盤が整いつつあります。

小さなアプリに巨大なデザインシステムは不要ですが、最低限でも原則・トークン・部品・使い方の4層があると、画面が増えても判断がぶれにくくなります。

Atomic DesignでUIを部品から組み立てる

Atomic Designは、UIを部分と全体の両方から考えるためにBrad Frost氏が提唱した思考モデルです。

5つの階層は、Atoms、Molecules、Organisms、Templates、Pagesで構成されます。

Atoms（原子）： ラベル、入力欄、ボタン、アイコンなどの最小要素
Molecules（分子）： ラベルと入力欄を組み合わせた日付入力などの小さな機能単位
Organisms（有機体）： 日付、人数、店舗をまとめた予約検索フォームなどのまとまり
Templates（テンプレート）： 実データを入れる前の検索結果画面や予約確認画面の構造
Pages（ページ）： 店名、日時、空席などの実データと状態が入った完成画面

ここで大切なのは、小さい部品から順番に作ることではありません。

Brad Frost氏自身も、Atomic Designは直線的な工程ではなく、UIを「まとまり」と「部品」の両方として考えるためのモデルだと説明しています。

完成画面を見ながら部品へ戻り、部品を直して全体を再確認する往復が前提です。

また、Atomic Designはデザインシステムそのものではなく、コンポーネントを整理するための一つの方法にすぎません。

部品の名前と階層をきれいに揃えても、誰が何を達成するアプリなのか、どの場面でその部品を使うのかが決まっていなければ、使いやすい画面にはなりません。

予約アプリを、画面の前から設計してみる

ここではレストラン予約アプリを、画面を描かずに設計してみます。

最初に決めるのは、「初めて利用する人が、条件に合う店を見つけ、空いている日時を選び、予約を完了できる」という中心タスクです。

次に、アプリへ登場する主な情報を名詞で書き出します。

店舗
エリア
ジャンル
メニュー
日時
人数
空席
予約
利用者

続いて、「探す」「比較する」「選ぶ」「予約する」「変更する」「取り消す」という操作を、関係する情報へ結び付けます。

ここまで整理すると、メインナビゲーションは「探す」「予約」「お気に入り」「アカウント」などに絞れます。

中心となる導線は、次の一本です。

条件を入力する → 候補を見る → 店舗を選ぶ → 日時と人数を確認する → 予約を確定する

導線が決まったら、デザインシステムから必要な部品を選びます。

日付入力、人数選択、店舗カード、空席表示、主要ボタン、確認ダイアログ、エラーメッセージなどです。

最後に、通常時だけでなく、読み込み中、候補なし、入力エラー、予約完了、満席になった場合まで画面へ落とし込みます。

AIへ画面生成を依頼するのは、この段階です。

「予約アプリを作って」ではなく、対象者・中心タスク・情報構造・導線・部品・状態を渡せるため、出力の良し悪しも判断できるようになります。

SmartHR・Apple・Googleなどは何を共通化しているか

著名企業の事例を見ると、デザインシステムは「見た目を同じにする資料」より広いことが分かります。

SmartHRは、情報設計、デザイン原則、デザイントークン、コンポーネント、ライティング、アクセシビリティまでを公開し、企画・UIデザイン・実装に関わる全員が情報設計へ参加する重要性を示しています。

AppleのHuman Interface Guidelinesは、基礎、パターン、コンポーネントを体系化し、各プラットフォームで人が慣れている操作を尊重するための指針を提供しています。

たとえばAppleは、タブバーを最上位のセクション間の移動に使い、現在画面への操作ボタンとして使わないよう案内しています。

これは、情報階層というIAの判断が、タブバーというUI部品の使い方へつながる例です。

GoogleのMaterial Design 3は、ガイドライン、コンポーネント、ツール、実装ライブラリを公開し、異なる画面サイズへ適応する考え方まで含めています。

IBM Carbonは複数の企業向け製品で使える共通基盤、GOV.UK Design Systemは行政手続きを迷わず完了するためのアクセシブルな部品とパターン、Atlassian Design Systemは人が入れ替わっても失われない設計判断の保管場所という特徴があります。

各社が同じ分類方法やAtomic Designを採用しているわけではありません。

共通しているのは、良い体験を偶然や個人のセンスに任せず、原則・情報・部品・使い方として共有していることです。