WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Design foundations from idea to interface

Design foundations from idea to interface

基礎Design
元の動画を見る

ハイライト

Majo が Design Evangelism チームの視点から、架空のアナログレコードコレクションアプリをケーススタディとして、ゼロからアプリの設計を磨き上げる四つの層を紹介します。

主要内容

アプリを開いて、自分がどこにいるのかわからず、何ができるかわからず、次にどこへ行けばいいのか見えない——これがユーザーが躊躇したり、困惑したり、最悪の場合アンインストールに至る根本原因です。Majo は架空のアナログレコードコレクションアプリで「見た目はまともそうに見えるのに、実際に使うと詰まる」状態を演示します：上部は曖昧なメニューで、タイトルはブランドロゴのようで、下にスクロールしてもアルバムカバーが並んでいるだけでどう操作していいかわからず、一番下にあるタブ名の Records を見てやっと「これは Records ページだったのか」と気づく（02:49）。画面が彼女を導いてくれない。自分でつなぎ合わせる必要がある。

Apple はこのプロセスを 4 つのステップに分解します：Structure（構造）、Navigation（ナビゲーション）、Content（コンテンツ）、Visual Design（ビジュアルデザイン）。各ステップは 3 つの最もシンプルなユーザー問いかけに対応します——「どこにいる？」「何ができる？」「どこへ行ける？」（01:56）。情報アーキテクチャから機能を書き出し、使用シーンを想像し、本質的でないものを削除。Tab bar でナビゲーションを担い、HIG は tabs を navigation として定義し action ではない（06:01）。Toolbar は「どこにいる」と「何ができる」の両方に同時に答える。コンテンツは progressive disclosure（漸進的開示）を使い、時間/進捗/パターンでグループ化。ビジュアルは system text styles + semantic colors で、テキストと色が自動的に Dynamic Type、ダークモード、コントラストに適応するようにする。各ステップで曖昧なデザイン直感を検査可能な具体的な問いに置き換え、判断に根拠を持たせる。

詳細

Structure：まず情報アーキテクチャ、次にインターフェース

Majo のプロセスはとても機械的です：アプリができるすべてのことを書き出す（機能、フロー、乃至 nice-to-have）。判断しない。誰がどんなシーンで使うか、いつ使うかを想像。それから整理を始める——本質的でないものを削除し、ラベルをわかりやすく改名し、自然と一塊になるものを統合（04:02）。彼女の結論は率直です：自分で何が本質か説明できないなら、アプリの中でも説明できない。

Navigation：Tab bar はナビゲーション、アクションパネルではない

当初の tab bar には Records、Crates、Add、Swaps、Saves の 5 項目がありました。Crates は単に「Records をグループ化したページ」なので統合。Add はメイン操作ですが、HIG は明確に「tabs はナビゲーション用でありアクション用ではない」と書いているため、Records の内部に移動（06:06）。残りの 3 つの tab は SF Symbols に明確なラベルを組み合わせる——アイコンを自作しない、なぜなら「自分でもアイコンをデザインするのは難しいと感じる」から（06:42）。tab が一つ増えるたび、ユーザーの意思決定コストも増える。

Toolbar は 2 つの問題を解決します：タイトルは「どこにいる」を、操作ボタンは「何ができる」を伝える（07:23）。スペースは限られているので、最も常用なものだけを置き、統一的に SF Symbols を使う。

Content：漸進的開示 + 4 つのグループ化

Groups と Records の二種類のコンテンツを分けるのが最初のステップ。しかしすべてを広げるとユーザーが瞬時に情報に溺れてしまう——progressive disclosure の手法は、まずいくつかの group を見せ、残りをタイトル横の disclosure control の裏に隠し、必要な時に展開する（09:01）。

レイアウト選択には讲究がある：2 つの item に grid は空きすぎで長テキストに不親切、List に変更——構造化された情報はスキャンしやすく、垂直スペースの利用率が高い（10:22）。Apple Design Resources の list テンプレートはそのまま使える。大量の画像には Collection（間隔一貫、テキストは最小限）が適しており、写真、動画、商品のようなスクロール閲覧シーンに向く。

4 つのグループ化戦略、使用頻度順：

  • 時間で（Recent files、Continue Watching、あるいは「夏に合うレコード」のような季節コンテンツ）
  • 進捗で（メールの下書き、未完了のコース、フルセットの合集）
  • パターンで（関連おすすめ、スタイル、ジャンル）
  • イベントで（11:33 からグルーピングテーマを解説）

Visual Design：squint test + system styles + semantic colors

視覚階層の最簡検査法は squint test——目を細めて画面を見ると、最初に注目するべきが最も重要なコンテンツ（13:55）。もし装飾的要素が最初に見えるなら、階層が逆だ。

修正法はおすすめコンテンツを拡大し、コントラストを強めて視覚的アンカーにすること。しかし手動でフォントサイズを調整するだけでは不十分——テキストは長くなるかもしれない、言語が切り替わるかもしれない、ユーザーは大きな文字サイズを選ぶかもしれない。ここで system text styles に切り替える：title から caption まで一整套で、自動的に Dynamic Type をサポート（15:20）。

テキストが画像に重なる時、busy あるいは高コントラストな画像は可読性を損なう。シンプルな解決策はグラデーションまたはブラー背景を一層加えること——鮮明さ優先（15:40）。

色は 2 種類に区分：palette 色（自分が選んだ 4 色 + retro 形状、組み合わせてスタイルを出す）と semantic colors（label、secondarySystemBackground の類、用途で命名され外観ではなく、自動的に明暗モードとコントラスト設定に適応、17:00）。Accent color は慎重に——buttons、controls、選択状態のような有意な場所のみで、動的切り替え、可読性、ユーザーの快適さへの影響を避ける。

重要ポイント

  • 何をする：「どこにいる / 何ができる / どこへ行ける」の 3 問で各画面を監査する

    • なぜ価値がある：ユーザーが画面に入った後、脳が実際に問うている問題であり、デザイナーが問いたい問題ではない
    • どう始める：アプリを開き、各画面で 5 秒テスト——5 秒以内にこの 3 問に答えられるか？答えられないなら構造の問題で、審美の問題ではない

  • 何をする：tab bar を 3-4 個に削り、アクションを tab bar から出す

    • なぜ価値がある：tab が一つ増えるごとに意思決定コストが一つ増える。tab にアクションボタンを置くのは HIG に違反し、アプリを実際よりも複雑に見せる
    • どう始める：現在のすべての tab を列挙し、各 tab に「統合したらどうなるか」と問う。tab bar 内のすべての非ナビゲーション要素（追加、お気に入り等）を列挙し、対応するコンテンツページの toolbar に移す

  • 何をする：カスタムフォントサイズとカスタム色をすべて system text styles + semantic colors に置き換える

    • なぜ価値がある：Dynamic Type、ダークモード、コントラスト適応を無料で手に入れ、複数のスタイルを自分で維持する必要がない
    • どう始める：コード内のすべての .font(.system(size:)) とハードコードされた色の十六進数を検索し、.font(.title) 等のセマンティックスタイルと Color(.label) 等 の semantic colors に置き換える

  • 何をする：コンテンツが多すぎて一画面に収まらない時、progressive disclosure を使い無限スクロールにしない

    • なぜ価値がある：すべてのコンテンツを一気に広げるとユーザーが溺れる。キーとなる数項目 + 「もっと見る」は大量コンテンツを扱う標準モード
    • どう始める：各グループはまず 3-5 項目だけ見せ、タイトル横に disclosure control を追加。タップして入る二次画面は直前の画面と視覚的連続性を保ち、「展開」感を出し「跳躍」感を出さない

  • 何をする：各画面の修正後、squint test で最終チェック

    • なぜ価値がある：視覚階層を検査する最も安価な方法で、5 秒で重点が本当に重点か判断できる
    • どう始める：画面スクリーンショットを 1/4 サイズにするか目を細めて見、最初に注目した要素を記録し、「最も重要なコンテンツ」リストと照合——合わないなら調整

関連セッション

コメント

GitHub Issues · utterances