オブジェクトベースなUIデザインに取り組むための心構え

オブジェクトベースなUIデザインの考え方が近頃注目されてきています。デザイナーとしてこれと向き合うに当たって、私なりに解釈した事柄を記しておこうと思います。

オブジェクトベースのUIとは

UIデザインにオブジェクト指向の設計論を導入したものをオブジェクトベースのUIObject-Oriented User Interfaces= OOUI などと呼ぶようです。オブジェクト指向UIオブジェクト指向ユーザーインターフェイスと呼ぶこともあるかもしれません。そのほかにも OOUX という表記も見られますが、ここでは一貫した呼び名を定めておきたいため、便宜上 OOUI と呼ぶことにします。

私たちが普段目にするGUIは元来OOUIの設計論に基づいていると考えられるのですが、中にはとても機能指向的(タスクベース)な設計のGUIが多くみられるため、特にオブジェクト指向の設計論に基づいているものを強調・区別する意味合いでOOUIと呼ぶことがあるのかもしれません。UIという言葉がほとんど暗黙的にGUIのことを指すように、そこにはOOUIの概念も含んでいるという共通認識があるのが多分理想なのですが、残念ながらまだそのような状況にはないのと、特にこの記事では「タスクベースに対するオブジェクトベース」と区別する目的があるため、ここではあえてUIではなくOOUIと表記してみたいと思います。

OOUIの特徴や考え方は上野先生の記事に解説されていますので、こちらを読むことを強く推奨します。

デザイナーの理念

(私が)OOUIデザインに取り組むにあたり、デザイナーとして次のことを意識しながら向き合います。

・表現に用いる名前の一貫性
・存在するモノや振る舞いの意味性の明示、理解
・実装の隠蔽
・モードレスな世界の実現
・ヒトと情報の対話に害を与えないこと
・文化の尊重
・プラットフォームの尊重
・イディオム的デザイン

OOUIデザインの捉え方

OOUIデザインの設計法では、UIの構成を「オブジェクト」「ビュー」といった要素とそれらの「関連性」の記述によって表現します。機能指向的にシステムの機能仕様を定義して画面を後付けするのではなく、UIの表層に現れるオブジェクトの在り方を定義するところがOOUI的なデザインの特徴と言えるでしょう。オブジェクトの在り方を定めることでその後作られるであろうワイヤーフレームに必要な素材が全て揃うことになるので、画面設計ツールを用いなくてもUIの振る舞いの論理的な正しさをモデル図によって保つことができるようになると考えられます。

OOUIの設計法では関わるデザインの工程を大きく次のように区別します。

1. 製品のインターフェイス要件を定める
2. オブジェクトの在り方を決める
3. オブジェクトの見せ方(見え方)を決める

特に重要なのは2の工程で、オブジェクトの表層ではなく裏側の構造に着目します。情報としての論理的な関連性や制約といったものをモデルとして定義し、具体的な骨格や表層を実装できる土台作りを行います。この工程のことを便宜上「UIモデリング」と呼ぶことにします。UIモデリングを導入することにより、おそらく「画面遷移図」や「サイトマップ」と言われるような指向性の強いモデル図をいきなり作らなくても良くなるか、作るにしてもそれらを根拠としてUI設計を行うようなプロセスは見直すことができるのではないかと考えています。

OOUIの操作手順は「名詞→動詞」構文で表す

OOUIの操作ではまず名詞(目的語)であるオブジェクトに注目し、次にそれに対する動作としての動詞を選びます。現在私たちがよく目にするGUIシステムの多くはこの構文を取り入れています。macOSのメニューバーやツールバーを使った操作がわかりやすい例です。

この「名詞→動詞」構文の原則は、80年代の Apple Human Interface Guidelines (HIG) やオブジェクト指向の教科書にも書かれているほど広く知られています。HIGではポインティング操作の原則として“noun-then-verb”アクションを紹介しています。オブジェクト指向プログラミング(OOP)では、名詞としてのクラスを作ってから動詞としてのメソッドの宣言とその実装を記述します。このようにして、UIモデリングにおいてもまずは名詞的要素のグループを形作り、そこに動詞的要素を紐づけるという設計手順を踏むことになるでしょう。

macOS ネイティブインターフェイスにおける「名詞→動詞」構文を取り入れたインタラクションの実例や考察は、“macOS native #01” というイベントでもお話ししました。

OOUIでは構造に着目する

UIデザインのプロセス全体をギャレットの5段階モデル風に表すと、OOUIでは特に 構造 に着目します。UIに現れる情報の在り方をモデルとして構築し、骨格層以降のデザインで正しく扱えるようにします。ここで注意したいのは、構造層においてはワイヤーフレームに代表されるUIの見た目に関する設計、あるいはナビゲーションストラクチャーや画面遷移図といった指向性の強いデザイナーモデルの設計は(おそらく)行わないだろうということです。画面の見た目に関わることは構造設計では重視しません。情報の構造化を行ってからそこにレイアウトだとか動きだとかの検討をするようにします。

これを補足するためには5段階モデルを改めて理解する必要があるかもしれません。

OOUIに限らず現状のUIデザインプロセスに関していえば、私の肌感ですと、要件層や骨格層でやることは割と認知されているのですが、構造層で具体的に何をやるのかというところが今ひとつ認知されていないように感じられます。これはオリジナルの5段階モデルの書き方のせいだと思っていて、そこには構造層で行うこととして「インタラクションデザイン」「情報アーキテクト」としか書かれていません。UXくらいにビッグワードすぎますね。よくわからないのも当然かと思います。しかも、5段階モデルの適用先として想定されているのが「web デザイン」とかなり限定的になってしまっていて、ネイティブアプリケーション出身の私としてはこの書き方には少々(だいぶ)納得がいきません。

なので、ギャレットの思想的に正しいかどうかは一旦おいておき、私なりにこの5段階モデルをOOUIの理解と納得のために再解釈してみることにしました。

ギャレットの5段階モデルの再解釈

http://www.jjg.net/elements/translations/elements_jp.pdf

ギャレットの5段階モデルはこのような五重塔のような図ですが、次の図ではオリジナルとは少し異なる解釈をしています。と言っても全く異なる意味に置き換えるようなことはしていなくて、表現や範囲を少し変えてあります。そもそも透視図にする必要性もさほど感じられないのですが、この特徴的な見た目が5段階モデルであることをわかりやすく示しているのもあって、これはあえて踏襲しています。

まず、オリジナルでは右側の軸を「ハイパーテキストシステムとしての Web」としていました。私はこれにもう少し汎用性と解釈の余地を残したかったので、「情報システム的観点」と置きました。これでハイパーテキストではない情報システムも受け入れられるようになりました。左側の軸もオリジナルでは「ソフトウェアインターフェイスとしての Web」とされていたところを「ユーザーインターフェイス的観点」と置きました。どちらからも “web” に限っていた視点を排除しています。

それぞれの層においては、特にユーザーインターフェイス的観点の側にある表層〜構造にかけての内容をざっくりと「インタラクションデザイン」と置きました。オリジナルでは構造のみに限定されていましたが、私の中では『情報をヒトが理解できる形に整形する作業とは、インタラクションデザインである』と解釈しているため、これらはすべてそう呼んでも差し支えないだろうという考えからこのようにしています。要するに、構造層で行うUIモデリングも「情報の特性を見出して整理することにより、その在り方を明らかにする」という意味でのインタラクションデザインだということです。
※これらのインタラクションデザインはより細分化して定義する必要があるかもしれません。

そのほかで異なる点で言えば、骨格層で「情報デザイン」とされていた工程を一旦省き、情報システム的観点の側に「レイアウトデザイン」「ナビゲーションデザイン」を置きました。これらはユーザーインターフェイス的観点で見ればどちらもインタラクションデザインとなります。
また、表層のビジュアルデザインを「視覚的情報デザイン」、構造層の「情報アーキテクチャ」を「構造的情報デザイン」と表現を少し変更しました。意味としてはオリジナルとほとんど変わりませんが、情報システムに関わるデザインであることをより強調しています。

ここで明らかにしたかったことは、OOUIをギャレットの5段階モデルに当てはめた場合のUIモデリングの位置付けと、骨格層との区別の仕方です。モデリングの作業には見た目に関する情報は必要ないということを示しました。

次の記事では、この5段階モデルと各工程に関する解釈をより詳しく述べています。

UIデザインとはソフトウェアデザインの一翼である

「UI」が指す対象をデジタルプロダクトのGUIであるという前提で考えた場合、ソフトウェアの仕組みを知らずにUIデザインはできません。

おそらく世間一般に認識されているUIデザインとは「画面の見た目を作る」ことであって、ソフトウェアデザインという視点があまり考慮されていないように感じられます。AppleやGoogleといったプラットフォーマーが定義するソフトウェアの仕様(Human Interface Guidelines、Material Design Guidelines、その他各種ガイドライン、明文化されていないプラットフォームの在り方だとか、OSが備える細かな挙動すべて)がアプリケーションのUIの設計方針を決めるのは当たり前のことで、このことはどう足掻いても無視することはできません。プラットフォームを知ることでそこで稼働するソフトウェアの振る舞い方がある程度決まってきます。

ソフトウェアデザインとは、サービスとユーザーとの架け橋となるインターフェイスを設計することとほぼ同義だと考えられます。


UIデザイナーの役割を二分してみたらどうか

ここまで考察を進めると、「UIデザイナー」という肩書きはどうもざっくりしすぎていると感じられます。場合によっては5段階モデルの表層から戦略まで全てのレイヤーでの活躍が求められることもある気がしていて、流石にそれは酷だと思うのです。そうでないにしても、人には得意不得意ありますから、もしもスペシャリストというキャリアパスがあるのであれば、私はエンジニアがそうであるようにUIデザイナーも表と裏で分けてみたら良いと思うのです。
すなわち、フロントエンドUIデザイナー バックエンドUIデザイナー という役割に二分してみるのはどうだろうか、という提案? です。

フロントエンドUIデザイナーは、世間で一般によく認識されている「UIデザイナー」の呼び名を変えたものです。グラフィックデザインの能力に長けており、特に表層〜骨格に関わる分野のスペシャリストということになります。

バックエンドUIデザイナーは今回私が勝手に新設してみました。OOUIの特に構造的な部分をデザインする役割になります。ソフトウェアの仕組みをある程度知っていて、それを表層に届けるまでの間において構造的な情報デザインを行うスペシャリストという立場です。エンジニア/デベロッパー上がりのUIデザイナーはこちらがはまる可能性が高いかもしれません。

これらを二次元的に解釈すると、どちらの肩書きでも「インタラクションデザイナー」とも名乗ることができそうです。

ただエンジニアリングと異なるところは、UIデザインの作業工程はきっぱりと線引きできるほどに領域が完全に分かれているわけではなく実際はグラデーションのような具合になっていて、作業的にもさまざまなプロトタイピングをしながら行き来するものと思われるので、自身の得意な守備範囲からじんわりと前後にも滲み出している……そのような動き方が求められるのではないかと考えています。

まあ肩書きはどうであれ、5段階モデルに基づいて役割分担をしてみるというのは良いかもしれません。

実装モデル・表現モデル・メンタルモデル

クーパー本によると、ヒトが認知する仕組みを大きく三種類のモデルで区別することができるとしています。この考え方をOOUIデザインにおける思考の土台としたいと思います。

実装モデル

実装モデルでは機械が実際に動作する仕組みや実装の詳細を表します。
ハードディスクを実装モデルで解釈すると、金属の円盤の表面を磁気ヘッドが行き来することによりデジタル信号の記録を実現するといった具合ですが、UIとして実装モデルに直接触れることはあまりないかと思います。普通は磁気ヘッドの存在さえ隠蔽されています。

メンタルモデル

表現モデルの前にメンタルモデルとは何かを定めておきたいと思います。
映像の実装モデルを考えたときに、それは1秒間に60コマの静止画が高速で入れ替わり、それを光によって私たちの視覚に映し出していると解釈されますが、ユーザーの脳内ではそんな複雑な仕組みは(わかっていたとしても)どうでも良いことなのです。ただ映像として認識して、そこに映し出される情景を見てどのように感じるかがメンタルモデルです。クーパーはこれをユーザーの脳内モデルと呼びましたが、Apple Human Interface Guidelines など著名なデザイン資料では似たような概念を指す言葉として「メンタルモデル」と表しているため、今回はそれらに合わせるためにあえてその語句で解釈してみます。

表現モデル

表現モデルは従来の物質的な機械の仕組みを表す場面では見られないモデルでした。ソフトウェアの世界では、プログラムの実際の処理の仕組み(実装モデル)と、ユーザーインターフェイスを通してヒトがどう感じられるか(メンタルモデル)という二つのパラダイムの間に、もう一つ新たなモデルが必要だと考えられるようになりました。クーパー本ではそれを表現モデルと呼びました。

私の解釈では、UIデザインのほとんどはこの表現モデルを設計することだと言えそうです。複雑なシステムの仕組み(実装モデル)を表現モデルとして投影し、ユーザーが正しく認知できるようにメンタルモデルに反映させる手助けをします。まさに、システムとユーザーの間に立つインターフェイスです。

UIは実装モデルではなくユーザーのメンタルモデルに基づくこと

クーパー本ではこのように述べられています:

『ほとんどのソフトウェアは実装モデルに従っている』
『ユーザーインターフェイスは、実装モデルではなく、ユーザーの脳内モデルに基づいて作れ。』

About Face 3, p54 - Alan Cooper / Robert Reimann / David Cronin 著、長尾高弘 訳

要するに、世の中のほとんどのUIは実装モデルをそのまま画面に表しているだけなので、とてもモーダルで使いづらいものになってしまっているという指摘です。デザイナーとしては、実装モデルをうまく隠蔽しつつも、ユーザーがシステムとうまく対話できるような表現モデルを設計しなければなりません。これが「インタラクションデザインの極意」になるのだと思います。

OOUIデザインでもこの考えは導入しておきたいです。おそらく、システムの実装に基づく構造をそのまま「画面化」してしまうとモードレス性は失われてしまいます。モードを如何にうまく隠蔽するか、あるいは感じにくくするかがデザイナーの一番の腕の見せ所になるのだと思います。

OOUIモデリング

今回はあまり踏み込みませんが、UIモデリングの工程をざっくり表すと次のような手順を踏むのだと考えられます。

1. 要素の抽出
2. オブジェクトの定義
3. ビューの定義

要素の抽出

これについては色々な方法論があると思いますが、ドメイン駆動設計(DDD)の「ユビキタス言語」の辞典を作ることが重要になってくるかと思います。概念のドメインを定めて、それに対して適切な命名をするという行為を厳密に行う必要があります。そこで命名したオブジェクトは共通認識を持てるような形で表さなければなりません。要素の抽出と命名行為とユビキタス言語の醸成は同時に行って、UIに関わるモデルの土台作りをします。

型と値を区別する

とは実体を表すモデルのことで、オブジェクト指向プログラミング(OOP)でいう「クラス」、実体関連モデルでいう「エンティティ」にあたります。エンティティのことを実体型と表記することもあります。SketchのSymbolをイメージするとわかりやすいかもしれません。

とは型に流し込まれるデータのことで、オブジェクト指向プログラミング(OOP)でいうプロパティに代入する「値」にあたります。オブジェクトが持つプロパティに実際のデータを代入して処理することがプログラムのランタイム上で行われますが、このように「値は実行時に型に流し込まれる実データ」と捉えることで、オブジェクトの定義と実際のデータとを区別して考えやすくなります。

UIモデリングでは型(実体型)の定義と値の流し込みを区別することが重要になります。ここに実体関連モデルの概念を導入すると言語の品詞に当てはめて考えることができます。

普通名詞: 型だけの定義、実体型、エンティティ、OOP的なクラス
固有名詞: 型に値が流し込まれた実体、OOP的なオブジェクト、インスタンス
形容詞:  型や実体の属性、プロパティ
動詞:   型や実体同士の関連、アクション、メソッド
副詞:   関連の属性

SketchのSymbolは型にあたります。

SketchのSymbol Instanceはオブジェクト、あるいはインスタンスにあたります。インスタンスにはインスペクターから独自の値を代入できます。

オブジェクトの定義

この工程では抽出した要素を 名詞的要素動詞的要素に分類し、関連するものをひと塊りにして「エンティティ」を形作ります。エンティティはよくオブジェクトと呼ばれているものですが、OOP的な解釈ではインスタンスではなくクラスに当たるので、あえて区別してみようと思います。

続いて、現れたエンティティ同士の関連付けを行い、オブジェクトモデルとして仕上げます。エンティティにはビューが複数関連づくことができるため、必要なビューも用意しておきましょう。

一つのオブジェクトには複数のビューが紐付く

あるオブジェクトを考えたときに、その見た目は一種類であるとは限りません。あるときはアイコン表示、あるときはリスト表示になるかもしれません。Finderのウインドウをイメージするとこれはしっくりくるかと思います。ビューによって表示される要素に違いがあることも注目しておきたいところです。

もしもこれがタスクベースの設計であると、ビューの見た目ごとに毎回異なるオブジェクトに関するモデルを用意する羽目になります。同じような情報を扱うのにいちいち違うシステムとインタラクトしなければなりません。システム設計的にも微妙ですし、UI的にもモーダルで使いづらいものになってしまうことでしょう。

ビューの定義

オブジェクトの定義が終わったらビューを定義しますが、これらをオブジェクトモデルと区別する必要がある場合にはインタラクションモデルとでも呼んでみましょうかね。ビュー同士の関連づけ、ビューは シングルコレクションかといった属性の定義を行います。
コレクション型のビューではエンティティの複数のインスタンスを扱うことができます。リスト形式の画面やグリッド形式の画面はコレクション型のビューだと言えます。対してシングル型のビューでは一つのインスタンスのみを扱います。基本的には、シングルではオブジェクトが持つ主要な属性の多くを表示する形になるでしょう。マスター詳細パターンでいうマスターペインがコレクション、詳細ペインがシングルという具合です。

このビューをペインして捉えたときに、どのように結合するかによって画面上の見た目の方針がある程度は決定づけられます。例えば二つのビューを一つのペインで括った場合にはそれは一つの画面の中に2種類のオブジェクトが同時に現れるUIとなります。複数のペイン同士を横並びにするとスプリットビューやカスケーディングリストのような構造になるのかもしれません。

ここで注意したいのが、ビューの定義はあくまでエンティティが持つ情報をどう扱うかということを定めるもので、具体的に画面のどの位置に表示するかまではあまり考慮されないことです。レイアウトに関する具体的な作業は次の工程に入ってからになるでしょう。

日本語で読める、OOUIに関する文献

やはり一番勉強になるのは上野先生による記事(通称“銀の弾丸”)ではないでしょうか。この記事の発表によって日本のUIデザイン界隈ではいよいよOOUIと向き合う流れが生まれ始めたように感じられます。


おわりに

OOUIの概念やその方法論を自分なりに研究してきましたが、これが「銀の弾丸」と言われる所以がわかる気がします。結局我々は今までUIの表層しか捉えていなくて、その裏側にある構造を見て見ぬ振りをしていたのです。OOUIモデリングの価値に気づいて構造に着目しだすと、世の中が二重に見えるようになってきます。そして、ソフトウェアが備えるGUIの多くは大体似たようなパターンによって成り立っていることにも改めて気づくことができます。これこそがOOUIの本質になるのだろうと思います。

さいごに、私はオブジェクト指向やUXの専門家というわけでもないため、解釈に間違いなどがある可能性もあります。その際にはやさしくご指摘いただけると幸いです。


この記事が気に入ったら、サポートをしてみませんか?気軽にクリエイターを支援できます。

390

#デザイン 記事まとめ

デザイン系の記事を収集してまとめるマガジン。ハッシュタグ #デザイン のついた記事などをチェックしています。広告プロモーションがメインのものは、基本的にはNGの方向で運用します。
20つのマガジンに含まれています
コメントを投稿するには、 ログイン または 会員登録 をする必要があります。