見出し画像

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

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

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

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

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

・GUIはOOUIである
・OOUIは新しい考え方ではない
・「オブジェクトベース」と「タスクベース」、ふたつの考え方

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


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

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

メニュー/ツールバー.001

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

画像2

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

ユーザーインターフェイスの構造に着目する

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

現状のUI設計プロセスに関していえば、私の肌感ですと、要件段階や骨格段階でやることは割と認知されているのですが、構造段階で具体的に何をやるのかというところが今ひとつ認知されていないように感じられます。この構造段階に着目しながら、5段階モデルを改めて再解釈してみたいと思います。オリジナルの5段階モデルでは、その適用先として想定されているのは「Webデザイン」と限定的になってしまっていて、デスクトップインターフェイス、ネイティブアプリケーションの方面出身の私としてはこの表現には少々(だいぶ)納得がいきません。UIデザインはWebだけのものではありませんから、より抽象度を高めた上でこの5段階を共通言語としたいです。

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

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

画像3

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

ギャレットの5段階モデルはこのような五重塔のような図ですが、次の図ではオリジナルとは少し異なる解釈をしています。と言っても全く異なる意味に置き換えるようなことはしていなくて、表現や範囲を少し変えてあります。

画像4

オリジナルは「Webには二面性がある」ことを踏まえてのこの透視図ですが、ハイパーテキストなのかソフトウェアインターフェイスなのかはWebの話なので、そこを受け入れつつも抽象度を高めたらどうなるのかを試しに検討してみました。

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

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

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

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

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

UIデザインはソフトウェアデザインである

「UI」が指す対象をデジタルプロダクトのGUIであるという前提で考えた場合、ソフトウェアの仕組みを知らずにUIデザインとは向き合えません。自動車の仕組みを知らずに自動車の筐体を設計できないように、ソフトウェアの仕組みを知らずしてそのUIを設計できない、ということです。

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

UIがソフトウェアであることを知ると、UIデザインとはどのような世界観であるのか、自ずと見えてくるのではないでしょうか。


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

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

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

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

UIデザインに関わる作業工程はきっぱりと線引きできるほどに領域が完全に分かれているわけではなく、実際はグラデーションのような具合になっていて、その作業は手戻りを繰り返しながら仕組みを磨いていくような、そのような具合に進むものと考えられるので、自身の得意な領域からじんわりと前後にも滲み出している……そのような動き方が求められるのではないかと考えています。

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

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

Alan Cooperによると、ソフトウェアデザインの対象を大きく三種類のモデルで区別することができるとしています。この考え方を思考の土台としたいと思います。

実装モデル

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

メンタルモデル(脳内モデル)

メンタルモデルはヒトの認知の仕組みをモデル化したものです。
「映像コンテンツ」の実装モデルを考えると、それは1秒間に60コマの静止画が高速で入れ替わっていて、光の変化によって私たちの視覚に投影していると解釈できますが、ヒトにとってはそのようなロジカルな仕組みは(わかっていたとしても)どうでも良いことなのです。静止画が入れ替わる仕組みがあったとして、それを映像として認識し、そこに映し出される情景を見てどのように感じるかを検討するのがメンタルモデルです。
About Faceの日本語訳ではこれを「ユーザーの脳内モデル」と呼んでいますが、英語ではMental Modelです。Apple Human Interface Guidelines など著名なデザインの資料でもそう表しているため、今回はよく使われる語句に合わせるためにあえてこのように表記します。意味としてはほぼ同一です。

表現モデル

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

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

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

クーパーはこのように述べています。

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

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

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

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

UIモデリング

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

1. インターフェイスで扱う概念を明らかにする(概念モデリングなど)
2. オブジェクトを抽出し、その在り方を決める(オブジェクトモデリング)
3. オブジェクトの見え方と振る舞い方を決める(インタラクション設計)

2の工程では、オブジェクトの表層ではなく裏側の構造に着目します。オブジェクトの論理的な関連性だとか制約といったものをモデルに表し、具体的な骨格や表層を実装するための土台作りを行います。この工程を含む設計の流れを便宜上「UIモデリング」と呼ぶことにします。UIモデリングを導入することにより、いきなり機能要件を考えたり、要件から「画面」と呼ばれる何かを設計するのではなく、ユーザーがオブジェクトとどう触れられるのか、オブジェクトをどう表すのかを志向しながらUIデザインに取り組むことができるのではないかと考えています。

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

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

要素の抽出

これについては色々な方法論があると思いますが、ドメイン駆動設計(DDD)で検討される進め方が有効になるかもしれません。特に「ユビキタス言語」を作ることは重要になるかと思います。そこにある概念やオブジェクトを識別できるように命名を行ったりすることもあるでしょう。あるいは、すでにある概念を引用してメタファーに当てはめたりも考えられるかもしれません。
いずれにしろ名前は非常に重要になるだろうから、共通認識を持てるような形で表すことを目指すと良いのでしょう。

型と値を区別する

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

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

クラス」と「インスタンス」など、オブジェクト指向の設計で扱う概念は非常に重要になってくるでしょう。

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

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

画像5

SketchのSymbolは型(クラス)です。

画像6

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

オブジェクトの明示

この工程では抽出した要素を 名詞的要素動詞的要素に分類し、関連するものをひと塊りにして「クラス」を形作ります。

続いて、現れたクラス同士の関連付けを行い、クラス図として論理的に表します。ここで多重度(インスタンスが作られる度合い)を検討することもあります。

一つのオブジェクトには複数のビューがある

あるオブジェクトの見え方を考えたときに、その見た目はただ一種類であるとは限りません。同じオブジェクトでも、あるときはアイコン表示、あるときはリスト表示になるかもしれません。Finderのウインドウをイメージするとこれはしっくりくるかと思います。ビューの形式が違ったとしても、そこに現れるオブジェクトが同様であるならば、それは同じオブジェクトとして捉えることができます。要するに、オブジェクトを表象する「ビュー」は一つではなく複数種類が検討できます。ビューによって表示される要素(プロパティ)には違いがあることにも注目しておきたいところです。

もしもこれがタスクベースの設計であると、まずやることが要求として決まっていて、それを“させる”ためのビュー(画面)が用意され、「画面設計」などと言われながらビューの見た目ごとに異なる設計が検討されるようになります。すなわち、機能や機能専用の画面が基準となってモデルが設計されるので、似たような情報を扱うのにいちいち違う仕組みが作られてゆきます。当然にUIは機能志向的になってゆくし、やれることが決まっているので使い勝手が悪く、システム設計的にも微妙な構造になってしまうかもしれません。そこでは、ユーザーが「このように使えたかもしれない可能性」というものは、いっさい考慮されません。ヒトの使い方までもがシステムの仕組みによって定まってしまうのです。
このようにしてUIはモーダルで使いづらいものになってしまうのでしょう。

ビューの定義

オブジェクトの形が明らかになったら、具体的なビューの構造やビュー同士の関連を検討します。上野さんの記事では、ビューには単体表示の「シングル」や複数表示の「コレクション」があって、それぞれに適した振る舞いを区別すると良いとあります。私はMaster-Detailパターンの延長で設計を検討すると良さそうであると解釈しました。

コレクション型のビューでは同一属性の複数のインスタンスを扱うことができます。リスト形式のビューやグリッド形式のビューはコレクション型のビューです。シングル型のビューでは一つのインスタンスのみを扱います。基本的には、シングルではオブジェクトが持つ主要な属性の多くを表示する形になるでしょう。Master-Detailパターンでいうマスターペインがコレクション、詳細ペインがシングルという具合です。例えば二つのビューを一つのペインで括った場合にはそれは一つの画面の中に2種類のオブジェクトが同時に現れるビューとなりますし、複数のビューを横並びにするとスプリットビューやカスケーディングリストのような構造になるかもしれません。

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

ここで注意したいのが、ビューの定義はあくまでクラスが持つ情報をどう扱うのかを定めるもので、要素を具体的に画面上のどの位置に表示するか、どのような色で、どのようなフォントで表すのかまでは深く考慮しないことです。ビジュアルやレイアウトに関する具体的な作業は次の工程に入ってからになるでしょう。

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

やはり一番勉強になるのは上野さんによる記事「OOUI – オブジェクトベースのUIモデリング」「速攻改善UIデザイン」ではないでしょうか。この記事の発表によって日本のUIデザイン界隈ではいよいよOOUIと向き合う流れが生まれ始めたように感じられます。


おわりに

画像7

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

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



この記事が気に入ったら、サポートをしてみませんか?
気軽にクリエイターの支援と、記事のオススメができます!
629
GUIを考える。

こちらでもピックアップされています

#デザイン 記事まとめ
#デザイン 記事まとめ
  • 4731本

デザイン系の記事を収集してまとめるマガジン。ハッシュタグ #デザイン のついた記事などをチェックしています。広告プロモーションがメインのものは、基本的にはNGの方向で運用します。

コメントを投稿するには、 ログイン または 会員登録 をする必要があります。