UI構造設計：導入—プラットフォーム思考とデザイナーの視点
ソフトウェアUIデザインにおける構造設計の前提となるデザインの考え方。
・・・
このシリーズは、ソフトウェアデザインの手引きとなるような考え方や方法論を複数回に渡って紹介するものです。ソフトウェアデザインの中でも特に「UIデザイン」に焦点を当てながら、その構造設計の分野に迫ります。その折、情報設計と呼ばれる分野にも触れていきますが、筆者は情報設計または情報アーキテクチャ（IA）の専門家というわけでもないため、そこを重点的に説くことは致しません。
このシリーズでは、Webに限ったユースケースではなくもう少し広い視野で物事を考察検討します。また、UIデザインというと絵を描く行為を想像しますが、ここでは「見た目では無い部分のソフトウェアUIデザイン」に焦点を当てます。
今回は導入として、具体的な方法論ではなくその前提となるような考え方の話をします。
ソフトウェアのプラットフォームとデザイナーの振る舞い方
同じIT系のデザイン分野でも、WebデザインとソフトウェアUIデザインには大きな違いがあります。WebデザインはWebブラウザで動作するソフトウェア（Webサイト）を対象としますが、ソフトウェアUIデザインはWeb以外のプラットフォームについても検討の対象になり得ます。昨今のメジャーなものだとiOSやAndroidなどのプラットフォームが挙げられます。PCだとmacOSやWindowsが代表的です。デバイスやOSに依存しない非Web系プラットフォームですと、各種ゲームエンジンもその一つとして数えられるでしょう。
Webがすべてではない
昨今はWebがソフトウェアのプラットフォームとして人気かつ巨大なので忘れられがちですが、Webではないソフトウェア環境というものも多く存在しています。ソフトウェアUIデザインではどの環境＝プラットフォームを前提とするのかから考えを巡らせることが大切です。Webは数あるプラットフォームの一つとして数えます。
例えばHTMLタグやCSSプロパティなどの知識はWebデザインでは大切ですが、Web技術を使わないOSネイティブアプリケーションのデザインでは特に必要がない知識になります。SEOやCookieなどの話題もWeb独特の事情でしょう。プラットフォームが変われば、その上でソフトウェアを構築するための知識や技術、慣習、ルールもそれぞれ個別に存在するものなのです。
“基軸とその他”でもない
「Webがすべてではない」—この発想をもう少し広く、文化レイヤーまで思考を広げることも大切に思います。例えば「地球上に存在する国をいくつか挙げて」と質問すると、大抵の日本人は日本の次くらいに米国の名前を挙げると思います。世界には200カ国くらいあるのにまず筆頭に米国の名前が挙がりやすいのは、彼の国が日本にとっては同盟国であり経済的文化的にも密接で非常に重要な国の一つだからです。メディアでも一番取り上げられやすい国名だから、印象としてその存在が大きくなるのだと思います。
何かの存在が自らに深く根ざしていたり、あるいは存在が巨大だったりするとそればかりに目がいってしまうものですが、世の中には大小性質さまざまな「ドメイン」があるものです。デザインでは、時には規模の小さな環境や性質の異なる環境にも目を向けて、それらへのためのデザイン的行為が必要になる場面もあるのではないでしょうか。
ソフトウェアデザインはプラットフォーム選びから
これから自前のソフトウェアを開発して展開しようと考えたときに、まずはそれを載せるためのプラットフォームを検討しなければなりません。ソフトウェアは既存のソフトウェアを部分的にあるいは全面的に利用して機能を組み合わせて構築するものです。真っ白な画用紙に一から絵を描いていくのではなく、過去の誰かが作った既製品を利用して、改良を加えながら新作の絵を描くのです。ソフトウェアデザインとはそのようにして考えます。
プラットフォームはソフトウェアが目指す目的や用途、開発に関する制約や条件等によって決められます。ときには精緻な価値検証を行なって対応するプラットフォームを最終決定することもありますし、はじめからプラットフォームありきでソフトウェア開発が走り出すこともあります。現場によってさまざまです。
同じ“Web”でも、どのブラウザ（エンジン）に対応するかといった戦略策定もプラットフォーム選定行為になります。かつてはInternet Exproler対応が必然的で、その他のマイナーブラウザへの最適化はついでに行われるような時代もありました。今ではIEは基本的に非対応方針を取り、Web標準の仕様や挙動を前提にしながらも、主要なWebブラウザにはなるべく最適化を図ってゆく方針が取られるものだと思います。（Chrome/Chromiumだから正義で、Firefox/GeckoやSafari/WebKitは悪ということでもありません。）
既製品の利用はむしろ善である
アーティスト気質な人ほど「既製品の利用」を忌避する傾向が強いように思うのですが、ソフトウェアデザインで大切なのはむしろこの考え方です。既製品を利用することは善であり、正義であり、ソフトウェアデザインの本質です。ソフトウェアデザインとはブリコラージュで作品を作るような感じなのだと思います。
世界観や表現の統一・一貫性、コンポーネント化（再利用前提とした部品化）、動的に組み合わせて生成する仕組み、システム化前提の設計—このような発想はソフトウェアだからこそな面でもあり、ソフトウェアUIを「完全なる静的な作品」として見ると本質を見誤りやすいでしょう。
ただし、すべてが何かの再利用で、全く同じ見た目振る舞いをしていても面白くはありません。基本的な思想はコンポーネント思考でありながらも、わずかなエッセンスとして独自の表現を盛り込むことも大切です。そのようにしてソフトウェアにブランドをもたらします。
「画面」でUIを考える発想を一旦捨てよ
WebデザインでもUIデザインでも、多くの現場では「画面」と呼ばれる“わかるようでよくわからない単位”が用いられます。画面って何なのでしょう？
Webサイトでいう画面はHTMLページのことを指すのでしょうか。これは何となく境界がはっきりしているのでまだ理解できる気がします。ブラウザがロードしたHTMLファイルを一つの「画面」と見立てれば、画面数とは静的なHTMLファイルの総数と概ね見積もることができるので、工数管理や設計管理になどで都合よく利用しやすいように思います。
では、静的なHTMLページでは表し切れないUI表現については如何でしょうか。例えばスクロールに応じて動的にコンテンツを追加読み込みして無限スクロールが生じるWebページ。この例における「画面」とは一体どこまでの範囲を指すのでしょうか。無限に広がる一枚の画面……？？
別の例を考えてみましょう。iOS appにおける画面は具体的にどこのことを指すでしょうか。字面の意味を愚直に解釈すると、iPhoneやiPadのディスプレイそのものをハード的な意味で「画面」と呼称します。でもソフトウェアなので中身は変化するわけで、その境界は実際のところ曖昧です。全画面で展開するAppのウインドウやモーダルビューならまだ「画面」と言い表しやすいでしょう。しかしハーフシート（半分まで引っ張り出せるドロワー型のビュー）や浮遊するダイアログ、メニューやポップオーバー（吹き出し）はどうでしょうか。
漢字の意味を解釈し直して、画が映る面＝画面として捉えるなら何となく絵が描画される部分を総じて「画面」と呼んでも意味が通じそうな気もしますが、ちょっと無理があるようにも思います。
では、このような「絵が描画される面」のことを何と呼べばよいのかというと、私は「ビュー」の呼称を薦めています。画面上に現れるこのような要素は総じてビューオブジェクトです。Sketchなどのグラフィックデザインツールでは「レイヤー」とも呼ばれますが、それとほぼ同じようなイメージで差し支えありません。アイコンもスライダーもマウスカーソルも、ビューの表面に絵が出力されています。そしてビューには機能としてマウスなどのイベントをキャッチする仕組みも備わっているので、HIデバイスで触れるとインタラクティブに動かせるのです。
UIがレイヤー化していってダイナミックになるほどに、「画面」と呼ばれるものの定義が曖昧になります。ですから、真面目にUIデザインに取り組むなら一旦「画面」で考えるのをやめて、その中身を構成するオブジェクトに目を向けることが大切です。画面とはある瞬間の出力結果（コマ）として考えましょう。
・・・
この記事が気に入ったらサポートをしてみませんか？