このnoteは株式会社ログラスのデザイナーAdvent Calendar 2025の、21日目の記事です。
挨拶
株式会社ログラスでプロダクトデザイナーをやっています。打田です。
前回の記事では、基本的なデザインのコンポーネントの準備に関して書きました。
今回は応用編で、以下5つの頻出パターンを一挙大公開します、大工のじいちゃんの昔話に付き合っておくれ🔨
- 🗺️ レイアウトパターン
- 🔀 遷移パターン
- 🪢 オブジェクト紐付けパターン
- ✏️ 詳細エディットパターン
- 📃 オブジェクト配布・回収パターン
この記事は誰向け？
引き続きtoB系のSaaSプロダクトをデザインしているプロダクトデザイナーさんが一番メインターゲットになると思います。
が、今回は内容的にはエンジニアさんにも有用ではないかと考えています。特にAI開発が浸透してきた昨今、画面レイアウトやフローのパターンの知識は、プロダクト作りでかなり生きると考えています。
AIが生成したプロトタイプに対し、人間が本記事のパターンを照らし合わせて品質を担保する際の判断材料としてご利用ください。
🗺️ レイアウトパターン
1画面内のカラムの分け方とその意味です。
1カラム
| 特徴 | 解説 |
|---|---|
| 基本 | 縦積みレイアウトで、要素が画面幅いっぱいに広がる 別画面から遷移してきた最後の行き止まりで利用される |
| メリット | スマートフォン対応しやすい 画面情報が少なく迷いにくい |
| デメリット | 頻繁にオブジェクト間を移動する必要があるプロダクトでは遷移が増えて扱いづらい |
| 備考 | input要素は幅いっぱいになると冗長で美しくない 640~720pxくらいの幅をmaxにする テーブルやリストなど大量に情報が並ぶ場合は幅のmaxを設けない |
| 具体例 | Google フォーム、ログイン画面など |
2カラム
| 特徴 | 解説 |
|---|---|
| 基本 | リスト→詳細の関係の典型例 3:7くらいの画面比率でサイドとメインにセクションが分かれる |
| メリット | 画面遷移を挟まずにオブジェクト詳細を提示できる オブジェクト詳細の編集を行いやすい |
| デメリット | 編集中に別のオブジェクトに移動しやすくコントロールが必要 サイドカラム側に検索・フィルタ機能がないと非常に使いづらい |
| 備考 | サイドカラムは幅が狭く追加要素を追加しにくい |
| 具体例 | Slack（サイドバー+メイン）、Gmail（受信トレイ一覧+メール本文）、一般的な管理画面 |
3カラム
| 特徴 | 解説 |
|---|---|
| 基本 | 編集系ソフトの典型レイアウト メインコンテンツの左右にそれぞれカラムが存在する 左から右に向かって情報粒度が小さくなる |
| メリット | オブジェクトを空間的にレイアウトする機能に最適 空間レイアウトの機能ではこれ以外の手段が取れない程度にはポピュラーです。 |
| デメリット | 中心のメインコンテンツ部分が狭くなる |
| 備考 | メインコンテンツ部分には上下左右全方向のスクロールを推奨 |
| 具体例 | Figma（レイヤー+キャンバス+プロパティ）、Notion（サイドバー+エディタ+コメント/目次） |
🔀 遷移パターン
一覧詳細パターン
一覧→詳細に遷移する際のパターンです。画面移動の際ユーザーにかけるコンテキストの記憶負荷と表示情報の情報量のバランスを取るためのパターンです。一般的に「移動した」という感覚が少ない表示方法ほどコンテキストの記憶負荷は小さくなります。
単純遷移パターン
| 特徴 | 解説 |
|---|---|
| 基本 | 一覧の行をクリックすると、画面全体が遷移して詳細ページになる。 Webの最もプリミティブな形。 |
| メリット | 画面領域を最大化できる。 複雑なタブ構成や大量のデータ表示に耐えうる。 1つのタスクに集中できる。 URLが一意に決まりやすくシェアしやすい。 |
| デメリット | 一覧と詳細を行き来する際のコンテキストの記憶負荷が高い（「戻る」ボタン必須）。 |
| 備考 | 詳細ページから一覧に戻る導線（パンくずやBackボタン）が必要。 |
| 具体例 | Amazonの商品一覧→詳細、一般的なECサイト、ニュースサイト |
2カラム遷移パターン
| 特徴 | 解説 |
|---|---|
| 基本 | 左に一覧、右に詳細を表示。 クリックで右側が即時切り替わる（マスター詳細）。 |
| メリット | 一覧性を維持しながら詳細を閲覧・編集できる。 高速にコンテンツ間を移動できる。 |
| デメリット | 詳細エリアが狭くなるため、情報量が多いオブジェクトには不向き。 |
| 備考 | メールクライアントやチャットツールで標準的なUI。 |
| 具体例 | Outlook/Gmail（Web版）、Macのメールアプリ、Slackのスレッド表示 |
nカラム遷移パターン
| 特徴 | 解説 |
|---|---|
| 基本 | 階層構造を左から右へ展開していく（Finder形式）。 |
| メリット | 深い階層構造を持つデータを、現在地を見失わずに探索できる。 |
| デメリット | 横スクロールが発生しやすく、レスポンシブ対応が難しい。 カラム幅が取れないので各オブジェクトの付随情報の一覧性は落ちる。 |
| 備考 | 深いツリー構造を持つデータの管理画面に適している。 |
| 具体例 | macOS Finder（カラム表示）、Linear（設定画面の一部） |
ツリーディレクトリ遷移パターン
| 特徴 | 解説 |
|---|---|
| 基本 | 親子関係を持つリストをツリー状に表示し、開閉やドラッグ&ドロップによる構造変更が可能。 |
| メリット | 複雑な階層構造全体を俯瞰しながら、直感的に整理・移動ができる。 |
| デメリット | 深い階層になるとインデントで横幅を圧迫する。 フロントエンドの実装・運用難易度が高い。 ドラッグ操作の判定（「中に入れる」か「並び替える」か）の実装難易度が高い。 |
| 備考 | フォルダのような「コンテナ」と、ファイルのような「リーフ」の区別を視覚的に明確にする必要がある。 |
| 具体例 | Figmaのレイヤーパネル、VS Codeのエクスプローラー、Notionのサイドバー |
ダイアログ遷移パターン
| 特徴 | 解説 |
|---|---|
| 基本 | 元の画面の上に浮いて表示されるいわゆるモーダル。 |
| メリット | 元の画面の文脈を維持したまま、一時的な確認や編集ができる。 |
| デメリット | 画面領域が狭く、複雑な作業には向かない。 誤って閉じると作業内容が消えるリスクがある。 設定量が多い場合ユーザーにコンテキストの記憶を強要する |
| 備考 | 作成・簡易編集など、短時間で終わるタスクに向く。 |
| 具体例 | カレンダー予定の簡易作成、Twitter(X)の投稿画面、Trelloのカード詳細 |
ドロワー遷移パターン
| 特徴 | 解説 |
|---|---|
| 基本 | 画面の端（主に右）からスライドして出てくる（スライドパネル）。 |
| メリット | ダイアログよりも縦方向の情報を多く表示でき、かつ元の画面の参照性を維持できる。 ダイアログと比較してコンテキストの記憶負荷が低い。 |
| デメリット | モバイルでの挙動制御や、複数開いた時の重なり順管理が複雑。 URLの取得管理が複雑になる。 |
| 備考 | 詳細情報の閲覧と、一覧の参照を両立したい場合に有効。 |
| 具体例 | Asanaのタスク詳細、Slackのプロフィール表示、Jiraの課題詳細（ボードビュー時） |
🪢 オブジェクトの紐付け設定パターン
特定のオブジェクトの設定を行うためにいくつかのサブオブジェクトを利用するケースのパターンです。
たとえば、社員・ロール・許可された操作をそれぞれ組み合わせて権限を作るよというようなパターンです。エンタープライズ要件に応えようとする過程で必ずほとんどのSaaSが経験する課題になります。
別画面遷移パターン
| 特徴 | 解説 |
|---|---|
| 基本 | 「紐付け専用」のウィザードや設定画面タブが分かれており、ユーザーは各ページに遷移して設定を完了する。 |
| メリット | 設定項目が膨大な場合や、検索機能が重厚な場合に集中して操作できる。 ページレベルで編集権限を切り替えられるので管理しやすい。 |
| デメリット | 移動が多くコンテキストの維持が難しい。 今何のために何をどこまで設定しているか見失いやすい。 |
| 備考 | 初期設定や、大量の設定を一度に行う場合に適する。 |
| 具体例 | OAuth認証画面、ウィザード形式の初期セットアップ、Shopifyのアプリインストール |
子オブジェクト包含パターン
※この例は2カラムレイアウト
| 特徴 | 解説 |
|---|---|
| 基本 | 親オブジェクトの作成・編集画面の中に、子オブジェクトを追加するフォームが埋め込まれている。 |
| メリット | コンテキストを切らさずに紐付け作業が完結する。 |
| デメリット | 親画面が複雑化しやすく、バリデーション制御（親保存前に子をどうするか等）が難しくなる。 子全体を一覧することが難しい。 重複した子要素を作りやすくシステムが荒れやすい。 |
| 備考 | 請求書明細の「行」の追加などが典型例。 |
| 具体例 | freee等の会計ソフト（振替伝票入力）、Amazonの注文時の「新しい住所を追加」 |
子オブジェクト紐付けからの詳細設定パターン
| 特徴 | 解説 |
|---|---|
| 基本 | 紐付け管理画面（メンバー一覧など）から、個別のオブジェクト設定へドリルダウンして詳細を調整する。 |
| メリット | 全体の関係性を俯瞰した状態から、気になった個別の要素を深掘りできる。 管理者がメンテナンスを行う際に自然な動線。 |
| デメリット | 階層が深くなりすぎると、元の紐付け一覧に戻れなくなる（迷子になる）リスクがある。 |
| ユースケース | チームメンバー管理画面から特定のメンバーのプロファイル編集へ移動、プレイリスト編集から楽曲詳細へ移動 |
| 備考 | ドロワー（スライドパネル）を用いると、文脈を維持したまま詳細へ行けるので相性が良い。 |
| 具体例 | Notionのメンバー設定、GitHubのチーム管理 |
ドラッグ&ドロップパターン
| 特徴 | 解説 |
|---|---|
| 基本 | 2つのリストを並べて、ドラッグ&ドロップや「追加/削除」ボタンでアイテムを移動させる（Transfer List）。 |
| メリット | 多数のアイテムを一括で紐付け・解除する場合に直感的で高速。 |
| デメリット | 画面幅を大きく占有する。 モバイル対応が困難。 フロントエンドの実装・運用不可が高い。 |
| 備考 | 権限管理やメンバー割り当てなどでよく使われる。 |
| 具体例 | Google グループのメンバー管理、アンケートツールの設問並べ替え |
グラフィカルリレーションパターン
| 特徴 | 解説 |
|---|---|
| 基本 | ノードエディタのように、線を繋いで関係性を定義する。 |
| メリット | 複雑な依存関係やフローを可視化しやすい。 設定全体の俯瞰がしやすい。 |
| デメリット | 実装コストが非常に高く、ユーザーにも操作習熟が必要。 |
| 備考 | ワークフロー設計やDBスキーマ設計ツールなど特殊用途向け。 |
| 具体例 | Miro、Tableauのデータソース編集、Node-RED、Zapierのワークフロー |
✏️ 詳細エディットパターン
詳細情報の編集を行う際のパターンです。編集体験はデータの型やデータそのものを作る体験と言っても過言ではないので、ここの使い勝手の良さは特にtoBアプリでは重要です。
全画面編集モードパターン
| 特徴 | 解説 |
|---|---|
| 基本 | 「編集」ボタンを押すと、画面全体が閲覧モードからフォームモードに切り替わる。 |
| メリット | 誤操作を防ぎ、保存と破棄のタイミングが明確。 バリデーションなどシステム的な制御がしやすい。 |
| デメリット | ちょっとした修正でもモード切替の手間が発生する。 作業中断など、一時的にシステムを離れにくい（保存されてしまう） 一回のリクエストの大きさが巨大になりやすい。 |
| 備考 | 保存の意図が必ず確認でき、即時反映もされないので、誤操作が許されない重要なデータの編集に適している。 |
| 具体例 | ブログの記事編集、ユーザープロフィールの「編集」モード |
インライン編集パターン
| 特徴 | 解説 |
|---|---|
| 基本 | 項目をクリックすると、その部分だけがinputに変わる。 |
| メリット | 修正が高速で、人間のメンタルモデルに近い。（消しゴムで消して書き直す活動と近似） 一般的に非常に操作感が良い。 |
| デメリット | システム的に「保存」のタイミングが曖昧で、簡単に変化させてはいけない値を誤って変更しがち。 |
| 備考 | JiraやNotionなどのタスク管理・ドキュメントツールで主流。アンドゥを搭載することでデメリットを解消する。 |
| 具体例 | Notionのデータベースプロパティ編集、Jiraのインライン編集、Excel/Spreadsheet |
プレビューボタンパターン
| 特徴 | 解説 |
|---|---|
| 基本 | 「プレビュー」ボタンを押すと、別タブやモーダルで実際の表示を確認できる。 |
| メリット | 編集画面を広く使える。 データ量が多くレンダリングコストの高いコンテンツでも編集動作を阻害しない。 |
| デメリット | 確認のたびにワンアクション必要で、微調整の往復が面倒。 |
| 備考 | 印刷プレビューや、公開前の最終確認フローとして配置されることが多い。 |
| 具体例 | noteの記事作成、Peatixのイベントページ作成、Google フォームのプレビュー |
リアルタイムプレビューパターン
| 特徴 | 解説 |
|---|---|
| 基本 | 編集画面の横に、実際の見え方が常時同期して表示される。 （2カラムのSplit View） |
| メリット | フィードバックループが極めて短く、試行錯誤しやすい。 |
| デメリット | 画面幅を常時占有する（基本的にPC向け）。 レンダリング負荷が高い場合パフォーマンスに影響する。 |
| 備考 | MarkdownエディタやWebサイトビルダーで必須の機能。 |
| 具体例 | Zenn/QiitaのMarkdownエディタ、WixなどのWebサイトビルダー、メール配信ツールの作成画面 |
📃 オブジェクト配布・回収パターン
フォームの配布やデータのインポート時のパターンです。概ねここまでの画面パターンでフォームやデータ型を設計した後で登場するパターンです。
タイマー付きパターン
| 特徴 | 解説 |
|---|---|
| 基本 | アンケートや申請など、期限付きで入力を求めるフロー。 |
| メリット | ユーザーのアクション期限を明確にできる。 |
| デメリット | 期限切れ後のデータ扱いや再配布フローの考慮が必要。 |
| 備考 | ステータス管理のデザインが重要。 一般的なSaaSのタスク管理画面はこのコンセプト。 |
| 具体例 | 銀行の振込ワンタイムパスワード、HR系ソフトの年末調整依頼 |
データマッピングパターン
| 特徴 | 解説 |
|---|---|
| 基本 | インポート機能などで、CSVのカラムとシステムのフィールドを突き合わせるUI。 |
| メリット | 外部データの取り込み柔軟性が高まる。 |
| デメリット | マッピング作業自体がユーザーにとって認知負荷が高い。 |
| 備考 | 自動推論（ヘッダー名一致など）と手動修正のバランスがUXの鍵。 |
| 具体例 | Salesforceのデータインポートウィザード、NotionのCSVインポート |
😩 全てを出し切った...
ここまで長話お付き合いいただき本当にありがとう。これで心置きなく過去のデザインスキルをAIに明け渡すことができそうじゃ...👴
ここまでの頻出パターンを後はAIに食べさせて、要件やメリデメに合わせて最適な選択をさせたり、レビューさせたりしてみておくれ🙏
もし非デザイナーだという方はこれを使って、Vibe Codingで出してきた画面の判断に使ってください。
会社紹介
全て出し切った最後に一度弊社を紹介させてください。
ログラスでは「もう一通りデザインの業務はやり切った！もっと難しいことがしたい！」という熱いプロダクトデザイナー、BXデザイナーを大募集中です。一緒にいい景気を作りましょう！🔥
もしこの記事を読んで興味を持たれた方は、ぜひカジュアルにお話しましょう！
プロダクトデザイナー
BXデザイナー