モデルベースUIデザイン—構造化UIデザインの発想と方法論

ユーザーインターフェイス（UI）のデザインに強く求められる技術や能力を列挙するとしたら、私は “情報を整理する能力” をまず挙げます。デザイナー職に対する世間一般の認識は「なんとなく絵を描くのが得意な人」だと思うのですが、絵が得意か不得意かはあまり本質的ではなく、情報をどのように整理して適切に表現できるのかが重要だと考えます。

UIデザインにおける “情報を整理すること” をもう少し詳しく説明すると、「設計コンセプトを形にし、コンセプトに基づく適切な部品の姿や機能を記述し、ユースケースに合った使い方を定義すること」と表せそうです。

コンセプトやユースケースもなく、いきなり「画面イメージ」を精緻に描くようなやり方をすると、求められていた価値をうまく表現しきれなかったり、設計プロセスとしても全体の作業効率が悪くなってしまうことがあります。そのようなやり方をするのではなく、IA（情報アーキテクチャ）の視点でUIを論理的に組み立てる発想に切り替えていくことを提案しています。このやり方では、ユーザにとって最適な表現パターンを迅速に網羅できたり、明らかに間違ったパターンというものを検討段階から排除できるようになります。物事を効率的に組み立てられれば、デザイナー自身にも作業の猶予が生まれ、本来注力すべき制作工程により多くのクリエイティビティを発揮しやすくなると思います。

この資料では、コンセプトやユースケースに基づいてUIを構造的に組み立てるモデルベースUIデザインの基本的な流れと、いくつかの方法論のさわりを紹介します。内容はいわゆる画面に映る具体表現に関してではなく、より抽象度の高い概念設計の話になります。

もしも「アラートダイアログの適切なボタン配置」や「モーダルビューの設計の考え方」などの具体的な事柄を求めているのであれば、別の記事「実例から考えるUIの情報設計」をおすすめします。iOSなどのよく知られたUIの実例から、その設計意図をクイズ形式で考えられる内容になっています。UIデザイナーの方はもちろん、アプリケーションエンジニアの方にもおすすめです。

なぜモデルベースに設計するのか

設計をデザイナーの感覚のみに頼って評価するのではなく、設計の根拠となるものを都度示して、論理が成り立つように組み立てていくのがモデルベースUIデザインの基本姿勢です。特にビジュアル表現ではない部分の構造設計では、その姿勢がとても重要になります。

極端な話、ビジュアルとして描かれる画面イメージをいくら綺麗に作ったとしても、含まれている情報の意味や構造に論理性が備わっていなければ、UIデザインとしてはあまり価値がないと判断されてしまうことがあります。

特にソフトウェアUIデザインはほとんどが “ソフトウェアの操作方法” に関する設計になるため、デザイナーはソフトウェアの作り方の過程として捉える視点を持つことが大切です。UIをソフトウェアとして機能させられるようにするためには、モデルベースに作った方が上手くいきます。UIの表層表現の側から闇雲に良さそうと思える表現を感覚的に探るよりかは、論理的に正しい構造をモデリングによって割り出す方が適当であると思います。

モデルベースの設計では「明らかに間違った構造」というものがはっきりと示されやすいため、これを上手く利用して間違ったものを避けていけば自ずと「正解に近い形」を探り当てられます。

ではビジュアル要素は重要ではないのか

UIにとってビジュアル要素はとても大切です。陳腐な見た目のものよりも整っていて綺麗だと思えるものの方が印象が良く、魅力的に感じられると思います。

しかしビジュアル要素はUIデザインにおいては “最重要項目” とまでは言い切れないと考えています。なぜなら、私たちはなんとなく見た目が雑な道具でも、その論理構造が成り立ってさえすれば一応は扱うことができてしまうからです。街中でたまに見かける “注意書きが大量に貼られたドリンクマシーン” は一見最悪の見た目をしていますが、それをよく読み解けば「機能する構造」が絶妙なバランスで成り立っていることを見出せるはずです。そもそも構造が成り立っていなければ、そのマシーンを使うことができません。

確かに見た目が格好よく、使いやすいものである方が絶対に良いはずなのですが、極論、一見格好良くても上手く機能しないものより、ダサくても機能はするものの方が価値はあると思います。

モデルベースUIデザインに取り組む基本姿勢は、論理構造とヒトが触れる部分の表現は区別し、それぞれで何を最も重視して設計していくのかを柔軟に切り替えていくことです。構造設計ではある程度正解と間違いが分かっていて、表現の形もパターン化されているので、その作業ではなるべく時間をかけずに「正しいと言える形」を探り当てることが大切です。ビジュアル設計では逆に「正しさ」が曖昧になってくるので、ここは時間をかけながら構造に矛盾しない表現というものを探っていく姿勢をとるのが良いと思います。

モデルベースUIデザインは、ビジュアル設計の前段にあたる構造設計を、なるべく間違いなく効率的にこなすためのフレームワークです。

構造とビジュアル要素の区別

情報アーキテクチャ（IA）の考え方の一つに、ペースレイヤリング（Pace-layering）と呼ばれるものがあります。建物を例に考えたときに、まずその構成をさまざまな要素に分解します。土地、骨格構造、外壁、家具設備、空間計画、日用品といった具合です。例えば土地の変化は非常に緩やかですが、石鹸のような日用品は数日から数週間の頻度で消耗し入れ替わりが生じます。新築でいきなり柱や壁が崩落することはないでしょうが、部屋の模様替えは数年に1回くらいはあるかもしれません。

この違いを例えば製品寿命として考えると、それぞれのレイヤーに所属する物の設計では、その使われ方や耐久性などを加味して区別する必要があることがわかります。使われ方以外にも、人の活動の仕方であったり変化の度合いだったりを比較する上でも、ペースレイヤリングの考え方は役立ちます。

参考：思想としてのペースレイヤリング

浅野紀予「思想としてのペースレイヤリング」 | ÉKRITS / エクリ

UIデザインの話に戻すと、UI（やソフトウェア）の構成もペースレイヤリングの発想で要素分解し検討することができます。UIでビジュアル要素と呼ばれるものはスキン（Skin）とも呼ばれます。

スキンとは、UIの骨格構造とは切り離されたビジュアル要素に関する構造体です。スキンの仕組みが採用されたUIシステムでは、ユーザは好みのスキンを指定してソフトウェアの見た目を自分好みにカスタマイズすることができます。ただしそこで変化するのは基本的に見た目に関する要素のみで、UIの骨格構造は一律に保たれます。スキンの変更によってボタンの位置が微妙に変わるくらいのレイアウトの変化はあるかもしれませんが、ナビゲーション構造が根本的に書き変わるとか、機能が大きく変化するといったことは起こりません。

最近の例を挙げると、iOSやmacOSの “Dark Mode” アピアランスはスキンの一種と言えます。

長寿命なUIフレームワークの設計する勘所

現代のmacOSで使われるAppKitフレームワーク（macOSのネイティブUI関係の部品を実装したもの）は、非常に息が長いUIフレームワークです。2001年に登場したMac OS X 10.0の頃から根本の設計思想は大きく変わることなく、20年以上運用されてきた歴史があります。20数年の間にmacOSとしての機能追加や細かな設計変更、主要プログラミング言語やCPUアーキテクチャの移行などもありましたが、AppKitは変わらず現役であり続けており、macOSらしいUIの実現に貢献しています。

AppKitのUIフレームワークとしての柔軟さと堅牢さは明らかで、20年以上前のOSで動いていたUI構造の多くが、現代のOSでも大体そのまま動いています。フレームワークのアーキテクチャ設計は当初から大きく変わりませんが、変えるべき部分は毎年手が加えられてきました。最新の開発環境からも扱えるようにモダンなAPIを拡張したり、最新のビジュアルを担えるようにスキンのアップデートも繰り返してきました。

AppKitを採用したアプリケーションでは、新しいOSでUIの見た目が大きく変わっても（例えば写実的な見た目からフラットになったときなど）、その根幹のUI構造までは大きく変わらなかったので、アプリケーションデベロッパーは特に何もしないか、しても必要最小限のコード修正対応のみで最新OSで動くモダンなUIを手に入れることができました。

優れたUI構造の維持とスキンの柔軟なアップデートという運用を行ってきたおかげで、ユーザはUIに特段古臭さを感じることもなく、便利に扱うことができています。初期のデザインがいかに優れていたかをよく反映している事例だと思います。

昨今は「デザインシステム」なるものを構築し、長期的に運用可能なデザインのアセットを維持し継承していくことが重要であるとされます。そういったものを設計する際には、初期のアーキテクチャレベルの設計は将来を見据えて緻密に組み立て、スキンのような表層レベルの設計は柔軟にすげ替えられる仕組みがあると理想的に思います。ペースレイヤリングでいうところの「土地」と「家具」くらいの関係で見ておくと良いのかもしれません。

モデルベースUIデザインの基本プロセス