SwiftUIは情報をデザインしてアプリを作る
SwiftUIは情報をデザインしてアプリを作る
SwiftUIでアプリを作る場合、アプリのデザインにおいてUIKitと大きく異なる部分があります。
それは、SwiftUIでは事前に考慮されていることが段違いに多いことです。
例えば、コンポーネント間の余白、アクセシビリティやRTL、macやtvOSで動作する際の見た目の変化など、SwiftUIでは最初から考慮されています。
そういった環境下では、カスタムコンポーネントを作ることは難しくなります。
なぜなら、他のSwiftUIと同様の質を担保するコストを払うか、他のSwiftUIのメリットを享受することを諦める２択になってしまうからです。
これらの前提を持ってアプリをデザインするには、SwiftUIの深い知識が必要になります。
どんなコンポーネントがあり、どういったカスタマイズ性を持っていて、何ができてできないのかを知る必要があります。
そうなると、iOSアプリエンジニア兼デザイナーをやるか、iOSアプリエンジニアとデザイナーが歩幅を合わせて作業を進める必要が出てきます。
しかし、このどちらも要求されるスキルや、時間が現実的ではないでしょう。
そこで、視点を変えてみます。
言葉を選ばずに表現するなら、表面的なデザインの仕事はSwiftUIによって奪われてしまったのです。
これは悲観することではなく、iOSアプリエンジニアがARCによってメモリ管理の知識を問われなくなったり、AutoLayoutによって複数のデバイスに対応出来ることと同義だと思っています。
より、本質的な問題に取り組めるようになったということです。
では、SwiftUIアプリにおいて、デザイナーは何をデザインするべきなのでしょうか。
それは、情報のデザインだと考えています。
ルック・フィールはSwiftUIが吸収してくれるので、それ以外のことをすれば良いのです。
これまでもデザイナーはアプリを使うユーザーの立場から、何を見せて何を見せないのかや、データをどのように見せるかという骨組みを作ってから表層を整えてきました。
そこから表層のステップを省くことで、より情報設計にフォーカスすることができるわけです。
この分担は非常にシンプルです。
デザイナーは画面や分割された画面単位で、そこに何が表示されて、何が変更できるのかを決めます。
エンジニアは、最初にボタンや画像といったシンプルな構成でレイアウトします。
SwiftUIはそれをもとに各OS向けのUIを生成します。
それを見て、エンジニアはより適したコンポーネントを提案し、デザイナーとすり合わせて合意を取ります。
SwiftUIはコンポーネントを変えることが比較的容易なので、この合意の時間では、短い時間で最大の試行回数を取ることが出来ます。
こうして出来上がったアプリは、全てのユーザーに対してAppleの標準的なアプリと同程度のアクセシビリティを持ち、macOSやiOS、iPadOSといった主要なOS間で同じ体験を提供できます。
クリエイティブは不要か
前項で、表面的なデザインの仕事はSwiftUIによって奪われたと表現しましたが、クリエイティブが不要になったわけではありません。
SwiftUIで作ったアプリは、悪い意味で味気無いのも確かです。
そこを埋めるために、SwiftUIでは出来ないことがあります。
SFSymbol
SFSymbolは簡単に言えば、AppleのOS標準のアイコンフォントですがまだまだ足りないアイコンがあります。
これらを解決するために、カスタムのSFSymbolを作る必要があります。
カスタムSFSymbolは、アクセシビリティや動的な表現など考慮することが多く、一つのアイコンに対して、これまでの10倍も20倍もやることがあります。
しかし、SwiftUIによって浮いた工数で、この部分にリソースを注ぎ込むことが出来るようになります。
アプリのシンボルとなるコンポーネント
前項では、カスタムコンポーネントを作ることは難しいと書きましたが、アプリ内のシンボルと言えるUIにこそリソースを投入して開発するべきだと考えています。
Walletアプリのカード表現や、録音アプリの波形、天気アプリの雨の表現など、そのアプリたらしめるコンポーネントに絞って開発します。
そこでは、OSやダークモードでの見え方、アクセシビリティなど考慮することが多くありますが、それを乗り越えるコストを払う価値がアプリのシンボルとなるコンポーネントにはあるということです。
逆にタブバーやスイッチなどのUIのデザインに工数を注ぐ余裕は、SwiftUIのアプリを作る上では全く無いのです。
最後に
個人的には、これまでのアプリを作る組織体制でSwiftUIアプリを作るのはそこまで旨味がないと思っています。おそらくiOSでしか動かないアプリが出来上がるでしょう。（ならUIKitで作ればいいですね）
というわけで、SwiftUI時代のデザイナーとエンジニアの関係は変化しそうだなと思ったので記事にしてみました。皆さんの感想をコメントでお待ちしています。
Discussion