SwiftUIによるデザイン

みなさん、こんにちは。 お集まりいただき、ありがとうございます。 大変申し訳ありません。 コントロール画面のせいで…… プレゼンテーションのメモをもう 少し大きくしていただけませんか？読めません。

このイベントのために、デザインに 関する「ウィッシュリスト」を携えて、 チーム一同で皆様にお越しいただけたことを 心より感謝申し上げます。 そして、そのプロセスがどのように 形になっていったかを、 皆様と共有できることを大変嬉しく 思っております。 この数年で私が学んだことや デザインプロセスを、 少しでも皆様の活動に お役立ていただければ幸いです。 それでは、始めましょう。 まずはアプリのナビゲーションから始めます。 これは、コンテンツや機能に合わせて 具体的なセクションを作成することから 始まります。 私たちとしては、こうした 流れで始めるのが好きなんです。 何を作るのかを正確に把握した上で、 計画を立て始める必要があります。 ナビゲーションというのは、 少々堅苦しいトピックに思えるかもしれません が、個人的にはとても好きな分野です。 そこで、次はそこから スタートしていきましょう。 続いてレイアウトについて触れ、 画面上でコンテンツを効果的に表現する 方法についてお話しします。 そして最後に、ビジュアルデザインについて 詳しく掘り下げていきます。 コンポーネントやビジュアル要素が 組み合わさることで、 アプリに明快さと個性が生まれるのです。

さて、先ほどもお話しした通り、 私はこのアプリを一から デザインしました。最初にやったことは、 アプリのナビゲーションについて考え、

アプリに搭載するコンテンツや 機能を決定することで、 しっかりとした構造を築くことでした。 そうすることで、明確な方向性を持って 開発を進めることができ、 トップバーやツールバーといったナビゲーションコンポーネントの 活用方法も 理解できるようになります。

まず、チームと私がアプリに 搭載したい機能や実現したいことをすべて リストアップし、 ブレインストーミングを行いました。

私たちは目標の達成を祝いたいと考えており、 あらゆるアイデアを歓迎しました。 私たちは、このブレインストーミングの 段階にいました。

デザイナーが「ちょっと待ってください」 と言いました。 そこから、私は内容を簡素化し、 旅行バケットリストアプリに必要な 「旅行プランの作成」「写真の追加」 「検索」といった必須機能のみを残しました。 そして一歩引いて、旅行やアクティビティ、 進捗状況、完了した旅行の祝いといった関連する アイデアをグループ分けしました。

これらのグループはアプリの主要な 3つのセクションを表しているため、 「ウィッシュリスト」「目標」 「検索」と名付けました。

これが私たちのアプリです。 これが皆さんにとっての意味です。

ゼロから始める場合でも、 既存のアプリを見直す場合でも、 この作業を行うことは非常に役立ちます。 私はここ「Developer Center」 で、 デベロッパの方々とワークショップを通じてしばらくの 間この作業を行ってきました が、いつも非常に目から鱗が 落ちるような体験となります。 ですから、皆さんもぜひ 同じことを試してみてください。 これにより、考えを整理し、 ブレインストーミングで浮かんだ 散らばったアイデアを、 相互に関連した画面へとまとめ上げ、 実際に構築する準備が整います。

これらすべてがSwiftUIとどのように 関連しているかについて、 説明させていただきます。 皆さんがここに来られたのは、 まさにこのためだと存じます。 iOSのセクションでその 点についてお話しします。 アプリのナビゲーションを支える コンポーネントは2つあります。 トップバーとツールバーです。

まず、トップバーの仕組みについて ご説明します。

トップバーにはアプリの最上位セクションが 表示され、 すべての画面で常に表示されたままになります。

この例では、アプリが実際よりも 複雑に感じられるかもしれません。 皆さん、こうしたアプリを目にしたことが あるでしょう。機能が増えれば増えるほど、 トップバーに表示される 項目がどんどん増えていくのですが、 それを好む人はあまりいません。 非常に複雑になってしまいます。 ですから、私が常にお勧めしているのは、 タブの数を少なく抑えることです。

そうすることでシンプルさを保てますし、 非常に予測しやすくなります。 ユーザーによる判断の負担も軽減されます。 そのため、アプリを開くたびに、 どのような選択肢があるかが正確にわかります。

次に、タブバーは ネイティブのままにしておきましょう。 これは、今日の「ビンゴカード」 に入っていますか？

ご存知のように、SwiftUIのコンポーネント （タブバーなど）には、 アニメーションやアクセシビリティ対応といった 組み込みの挙動が備わっています。 そのため、カスタマイズを行うと、こうした 挙動が失われてしまう可能性があります。

しかし、ご安心ください。 アプリには、個性を表現できる 場所が他にもたくさんあります。 ただ、トップバーはその場所の 一つではありません。

最後に、タブバーには、各タブの内容と一致する 明確なシンボルとラベルを 使用するようにしてください。

「ウィッシュリスト」には、 普遍的なシンボルがありませんよね？ そこで私は虹を選びました。 これは認識しやすく、人々が撮りたいと 憧れるような写真を表現していますよね？ 希望に満ちているような感じです。 一方、目標とするのは、 より明確で、ラベルと非常によくマッチし、 内部の収集アイテムの多くと同じ 形状をしたアイコンを使用することです。 これは素敵な工夫だと思いました。

これらのガイドラインに従えば、 タブバーは効率的であると同時に 効果的になるでしょう。

ここで少し脱線させていただきます。 デザインやタブバーについてもう 少し詳しく知りたい場合は、

「ヒューマンインターフェイスガイドライン」を ご覧ください。 これについては、以前にも お伝えしたことがありますね。 「The Hague」は、 Appleのすべてのプラットフォームや テクノロジーにわたるデザイン、 ガイダンス、ベストプラクティスの拠点です。

私たちに相談される前に、まずここを訪れて 質問やアドバイスを求めてください。 デベロッパ向けウェブサイトの 「デザイン」セクションに、 ついに「The Hague」 へのリンクが掲載されました。 このセクションには、非常に貴重なAppleの デザインリソースも含まれています。

「ウィッシュリスト」タブや、 私がこれまでデザインしてきたほぼすべての アプリのデザインには、 このライブラリのネイティブコンポーネントが 使用されています。

デザインツールボックスを閲覧・構築している 間に、ぜひ「SF Symbols」 アプリを ダウンロードしてみてはいかがでしょうか？ これは、アイコンの宝庫のようなものです。 7, 000個以上のシンボルが 収録されており、デザインやコードに コピー＆ペーストするだけで利用できます。

これらは私がトップバーに使用しているもので、 今後も使い続けることになるでしょう。 今日だけでも何度か参照する予定です。 さて、本題に戻りましょう。 トップバーもツールバーも、 アプリのナビゲーションをサポートしています。 しかし、違いがありますよね？ 動作するレベルが異なるのです。 ユーザーは、アプリ内を移動する 際にトップバーを使用します。 先ほど「トップレベルナビゲーション」 とお話ししましたね。 しかし、アクションを実行したり、 特定のセクションに移動したりする際は、 ツールバーを使用します。

ツールバーには、ナビゲーションをサポートするさまざまな 要素があります。 まず、現在のビューのタイトルです。 この画面では、ユーザーが

自分が現在どこにいるのかがわかります。 「ウィッシュリスト」――失礼、 この「ウィッシュリスト」 セクションにいること、そして画面の内容に 関するコンテキストも把握できます。 いわば、全体の雰囲気を決めるような 役割を果たしています。 そして、ツールバーには、この画面上で 最も重要なアクションを行うための コントロールが表示されます。 主なアクションは「旅行を作成する」ことです。 そこで、そのための操作ボタンを 右上に配置しました。

ツールバーの3つ目の要素は、 ナビゲーション操作です。 ここ「旅行の詳細」画面では、 1つ前のレベルに戻り、 再び「ウィッシュリスト」にアクセスできる 「戻る」ボタンを追加しました。

画面をひと目で把握しやすくするためです。 操作の数を最小限に抑えています。 トップバーと同様の指針に従い、 馴染みのあるアイコンを選ぶことで、 意味が明確に伝わるようにしています。

項目が多すぎると、 この例のように、 ユーザーが最初に何をすべきか 理解しにくくなってしまいます。 これを改善するには、 あまり頻繁に使われないアクションや、 より高度な機能を「もっと見る」 メニューの背後に隠すだけで済みます。

ツールバーは、主要なアクションを際立たせる スタイルも提供します。 アプリをデザインする際、 色鮮やかなアクセントを加え、

瞬時に視線を引く焦点を作り出します。 このスタイルは、1画面につき1つのアクションにのみ 使用するようにしてください。 トップバーには、 強調したい目立つ機能が 数多くあることは承知しています が、すべてが重要だと、 結局は何も重要ではなくなってしまいます。

ですから、この場合、 旅行のバケットリストに旅行の予定が 一つもなければ、何の意味もありません。 ですから、これを際立たせたいと思います。

ツールバーについて最後に申し上げたいのは、 トップバーと同様に、 ネイティブな状態を保つのが 最善だということです。 皆さん、一緒に言ってみましょう。

背景などの余計な要素を追加しても、実際には コンテンツと競合してしまいます。 機能やモーフィング効果とも 競合してしまいます。 この点については、 後ほどカートも少し触れる予定です。

ここまで、アプリの構造やユーザーがどのように アプリ内を移動するかについて 集中モードで集中してきました。 それでは、画面にコンテンツを配置し、 どのように表示するかを決定する 段階に入ります。

これが、私が「レイアウト」 と呼んでいるものです。 私がよく使用する2つのレイアウトパターン、 リストとコレクションの例をいくつか ご紹介します。

どちらも非常に柔軟性が高く、 どちらを選んでも構いませんが、 表示したいコンテンツや、 ユーザーがそのコンテンツに 対して何を行う必要があるかによって、 どちらかのオプションの方が 適していることがすぐにわかるはずです。

例えば、コンテンツがテキストベースの場合は 「リスト」を使います。 そうですね。表示する 必要がある項目が複数ある場合、 ユーザーが素早く目を通すのに役立ちます。 だからこそ、このレイアウトは 旅行のアクティビティに最適なのです。

ここでは、必要に迫られて「エッジ・トゥ・ エッジ」というスタイルを使用しています。 また、コンテンツを分類する必要がある場合は、 「グループ」スタイルを使用します。 つまり、その違いは微妙なものなのです。 しかし、「インセット」 レイアウトと角丸加工により、 リスト内に含まれる異なる カテゴリのコンテンツが明確に区別されます。 ですから、このアプリではこのスタイルは 必ずしも必要ではありませんでした。 アプリをダウンロードして実際に使ってみても、 この例は見つからないと思いますが、 いつ「エッジ・トゥ・エッジ」を使い、 いつ「インセット」を使うべきかといった点で、 常に多少の混乱があるため、 私がどのように対応している かをお見せしたかったのです。 これが私たちのやり方です。

最後に、ユーザーがリスト内を素早く 移動・操作できるようにするため、 アクセサリとコントロールを使用しています。 画像やサブタイトルなどのアクセサリは、 行ごとに読む必要なく項目を素早く 認識するのに役立ちます。

また、ここにある選択ボタンのような コントロールは、別のビューに 移動することなく操作を行えるようにするもので、 これは非常に一般的な手法です。 リストビューから直接実行できるわずかな アクションのために ビューを追加してしまうことで、 アプリが複雑になりすぎてしまうことが あります。

追加できるコントロールの種類は多岐にわたり、 さまざまな機能をサポートしています。 ですから、利用可能な機能をぜひ探ってみて、 レイアウトを簡素化できる 機会がないか確認してみることをお勧めします。 ここには、ステッパー、トグル、 スライダーなど、試してみることができる コントロールが多数用意されています。

これらは、ユーザーが テキストを素早く移動するのに 役立つリストに関する内容でした。 しかし、写真や動画、 あるいは商品を閲覧することが目的の場合、 コレクションの方がはるかに適しています。

SwiftUIのコレクションは、 本質的にスクロールビューを備えた スタックビューであり、コンテンツが 画面の外にまで広がることを可能にし、 ユーザーがスクロールして中身を探索したくなるような 仕組みになっています。

しかし、こちらの「ウィッシュリスト」 タブでは、主な目的は閲覧にあります。 そこで、ユーザーがアップロードした 写真を際立たせ、より視覚的で、

パーソナルかつワクワクするような 印象を与えるよう、 コレクションのバリエーションを複数用いた レイアウトを採用しました。

ここで留意すべき点は、 コレクションではすべてのコンテンツが 一度に表示されるわけではないということです。 その大部分は画面外にあります。 そのため、ユーザーに適切な期待を持たせ、 スクロールして閲覧するよう促すために、 タイトルや画像を効果的に 配置するようにします。 これはどういうことでしょうか？ さて、この例において、 画像は付加価値をもたらしていると思いますか？

少しランダムに見えませんか？ はい。非常にランダムです。そして、 画像に一貫性がなく、意味が通じないため、 コンテンツの信頼性を損なってしまうことが あるのです。 厳選された印象が受けられません。 そこで、長さが統一された タイトルを追加することができます。 そうしないと、レイアウトがまた 少し不格好に見え、位置がずれているように 見えてしまいます。 そのため、コレクション全体の見た目が 損なわれるだけでなく、 下にコンテンツがある 場合の縦スクロールにも支障をきたします。 今や、すべてが少し不安定に見えてしまいます。 ですから、コレクションのコンテンツにおいて、 いくつかのルールを設定しておくことは、 見栄えを良くし、すっきりとした 印象を与えるために重要です。 さて、SwiftUIは、私が説明の中で 少しずつ触れてきた多くのデザイン原則をすでに 処理してくれていますが、階層、 配置、近接性といった要素は、 すべてコンポーネントの一部となっています。 しかし、レイアウトを作成する際には、 これらの要素を自ら探求し 始めてみることをお勧めします。 それがビジュアルデザインの 重要な部分なのです。

そこで、テキストの色や 画像を活用して、視線を誘導し、 あなたの個性を表現していきましょう。 ここまでは、効率性を重視して 機能面に重点を置いてきました。 それでは、ここからさらに、 あなたの魅力を少しだけ加えてみましょう。 そこで、ビジュアルデザインの中でも、 最も早く、かつ大きな影響を与える3つの側面、 すなわち「テキスト」、 「セマンティックカラー」、そして 「一貫性」に集中していきます。

これら3つが組み合わさることで、 アプリは楽しく、理解しやすくなり、 私が大好きなものになります。 これらは、アプリが成長するにつれて、 デザインパターンを再利用するための 指針となります。

まずはテキストスタイルから始めましょう。 これらはスタイルの階層構造を確立します。 すみません。これらは階層構造を確立し、 さまざまな画面サイズや 環境において読みやすさを高めます。 そこで、システムテキストスタイルを 使用すれば、 最初からその階層構造が得られます。 しかし重要なのは、アプリ内の目的に 合わせて適切なテキストスタイルを 選択することです。 私はこれを一貫して使用しています。 例えば、「タイトル3」は、 「Summer glow」のようなすべての セクションタイトルに使用します。 これにより、すべての画面がよりバランスよく、 洗練された印象になります。 コンテンツが明確なセクションに 分かれているため、どの階層を表す Textileか一目でわかる瞬間、 そのコンテンツが何を意味するのか 正確に把握できるからです。

私がSystem Textilesを 頼りにしているもう一つの理由は、 ダイナミックタイプです。 多くの人が、読みやすさのため、 あるいはその両方の理由で、 より大きなTextileを使用しています。 ダイナミックタイプを使用する場合、 それらのテキスタイルの名前は同じですが、 一貫して大きくなります。 ぜひご活用ください。

フォントに詳しい方なら、 アプリ全体で「Apple SystemFontSFPro」 を使用していることに 気づかれるかもしれませんが、 実際にはそうではありません。「Pro」 という1つのスタイルを使用するだけで、 さまざまなバリエーションが利用でき、 可読性を損なうことなく アプリの個性を形作ることができます。 私たちはよりスポーティーな 雰囲気を目指していたため、 タイトルでの強調には 「Expanded」を使用し、 「Condensed」は一部のオーバーレイで 控えめに使用しています。

ここでも、UIに意図を感じさせると同時に、 アプリのメンテナンスや拡張を容易にするため、 選択肢を最小限に抑えたいと考えています。 さて、再びテキスタイルの話に戻りますが、 「ああ、いつ『Expanded』 を使えばいいの？」という疑問が湧いてきます。 いつ使うべきでしょうか？ そして今や、たくさんのテキスタイル、 たくさんのバリエーション、 そして、なんと、 膨大な数のフォントがあります。

先ほどコレクションについて説明した際、 画像がアプリの視覚的な重みを大きく 担っていると述べました。 そのため、セマンティックカラーは UIをうまく補完するものであり、 役割は非常によく似ていますが、 ステータスやフィードバックという、

より具体的な役割を担っています。 例えば、私はアプリ全体で「インディゴ」 という色を使用していますが、ここでは、 完了したアクティビティや トップバーの選択済みタブなどでは、

装飾目的でこの色やインディゴに非常に 似た色の使用を避けています。 そうしないと、ユーザーは 「これは操作可能な部分なのか？ 」「何か意味があるのか？」 と理解できなくなる可能性があります。 何か意味があるのか、 といった混乱を招く恐れがあります。 この色を「インディゴ」と名付けましたが、 その前に、セマンティックカラーについて 説明しています。 ですから、これは単に 周囲にあるような色ではありません。 つまり、そうですね、ランダムに選んだのです。

システムによって提供されている色であり、 ネイティブの……失礼、 各ネイティブコンポーネントにはそれぞれ固有の 色があります。ですから、 背景色は設定していません。 セパレータの色も設定していません。 これらはすべて、私にとっては 最初から用意されているものです。 私が選んだのは、 このアクセントカラーだけです。

これらの色は、ライトモードや ダークモード、 Liquid Glass、 そしてさまざまな画面環境に 自動的に適応するため、 特にボタンやコントロールに 関しては、カスタマイズに 再び追われることのないようにするのが 最善です。

おそらくアプリをご覧になった方もいらっしゃるかと 思いますが、 カラーパレットにはネオングリーンも 含まれており、 私はこれを進行状況インジケーターや 小見出しなど、強調用途にのみ使用しています。 繰り返しになりますが、 意味やこれらの視覚的なメタファーを 認識できるように心がけています。 したがって、この色は セマンティックな意味を持ちません。 当社のキットにはこの色は含まれていません。 そのため、十分なコントラストが確保されている ことを確認しています。 さまざまな背景に対してテストを行いました。 また、コントラストを高めるための 値も用意しました。

ですから、システムカラー以外の 色を使用する場合は、 いくつかの簡単なルールに 従うようにしてください。 このように、テストを続け、 アプリの表現力を損なわずに、使いやすさを 損なわないようにしてください。

さて、そろそろ終わりに近づいてきました。 つまり、すべてが最良の状態に 見えるかを確認する良いタイミングです。 最後の仕上げとして、 もう一度確認し、すべての要素が整列し、 間隔が統一されていることを確認します。

これにより、デザインはより洗練され、 視覚的にもバランスが取れた印象になります。 プロフェッショナルな印象を与えるだけでなく、 ユーザーが情報を把握し、次に 何をすべきかを判断するのをサポートします。 もし、多くのコンポーネントが狭い スペースにぎゅうぎゅうに詰め込まれていると、 どうなるでしょうか？ 私たちはストレスを感じ、 考えるためのスペースや時間が 足りないと感じてしまいます。 そして、UIに少し余裕を持たせることで、 ユーザーが情報を処理するためのスペースが 生まれ、素晴らしい体験が生まれ始めるのです。

ですから、ネイティブコンポーネントを 使用する際も、 異なる画面間で一貫した 使い方を心がけています。 同じ操作に対して複数の方法を 提供することは避けています。 これは時々起こりがちなことです。 新しい画面を作成する際、私たちは ワクワクして、一から作り始めてしまいます。 しかし、開発を簡素化するだけでなく、 ユーザーが体験する ユーザーエクスペリエンスの観点からも、 これらのコンポーネントを再利用することが 最も重要です。 ユーザーは、どこでそれを見たことが あるかを知っています。 その動作も理解しています。 そして、自分に何が求められている かを正確に把握しています。 例えば、進行状況インジケーターは、 ここでも同じアクセントカラーと同じ 形状を使用していますが、 それでも少し小さめになっています。 それは、私が知っている文脈の 中にあります。ええ。 あれ、あれは何をしたのでしょうか？ そして、その一貫性は開発の面でも役立ちます。 作成すべきコンポーネントの数が減ります。

コレクションの説明の中で 画像について簡単に触れましたが、 もちろんそれらはビジュアルデザインの 一部です。 ですから、画像やイラストを選ぶ際は、 それらを並べて配置し、 見た目が馴染んでいるかどうかを 確認してください。 ディテールのレベルや全体的な雰囲気を見極め、 同じブランドの一部であると感じられるよう 微調整を行ってください。 同じコレクションに 属していると感じられるかどうかです。 直感を信じてください。 おそらくその直感は正しいはずです。 どのリストに含めるべきでしょうか？ 例えば、ユーザーが自分の写真を アップロードすることもあります。 しかし、ここでもポイントを明確にするために、 画像を使ってどのように組み 込めるかを示しました。コード上では、 それらの画像にアクセスできるようになります。 先ほど説明したパターンが、 お分かりいただけたかと思います。 そこで、私は「ダイナミック・ スカイ」を採用することにしました。 被写体が小さかったり、空間と相互作用していたりすることが 多いのですが、 基本的な考え方は、写真よりも UIを際立たせるということです。 とはいえ、アプリ全体で 一貫した外観を実現するためには、 ぜひご自身で検討していただきたい 点でもあります。 一歩引いて考えてみると、 アプリのデザインについては、私にも少なから

ず貢献した部分はあるかもしれませんが、 実際のところ、デザインに 関する多くの決定は皆さんが 担当してくださっています。これは、 正直なところ、事実です。

でも、本当のことなんです。 私は、このアプリを作るために エンジニアの皆さんと協力できることを、 本当に楽しんでいます。 そして、私がデザインしたものがすべて、 コード上で非常に忠実に 再現されているのを見るのは、 本当に素晴らしいことです。 ですから、皆さんにこのアプリをご紹介し、 実際に触っていただくことが できることを、とても楽しみにしています。 そして、皆さんの制作プロセスにこれらの ヒントをいくつか取り入れていただき、 創造性を発揮したい時に 時々生じてしまう不確実性を少しでも 軽減できればと思います。 例えば、思いついた時にすぐに取り掛かったり、 あるいは最初の段階で創造性を発揮し、 意思決定やブレインストーミングを行い、 その後でコーディングに 取り掛かるための余裕を持てたりするでしょう。

ですから、作業に戻る際には、 構造とそのナビゲーションを 定義または評価してください。 コンポーネントを慎重に活用してください。 そうすることで、明確な判断を 下す助けになります。 そうすれば、コーディングを始める時点で、 自分がどこへ向かっているのかが 正確に把握できます。 自分が何を作っているのか、 はっきりと理解できるのです。 そうすれば、より意図的なアプリを 構築できるはずです。 では、SwiftUIを活用しましょう。 面倒な作業はSwiftUIに任せ、 あなた自身は個性や創造性、人間味をアプリに 吹き込むことに全力を注いでください。

本当にありがとうございました。アプリの 開発や操作を存分に お楽しみいただければ幸いです。 デザインに関する説明は以上です。 ご来場ありがとうございました。 それでは、ここからは リーアさんにお返しいたします。