シンプルなインターフェイスに多様性を持たせるコンセプト
私は現在、株式会社タイムラボにて、主に新規事業のソフトウェア製品の開発に取り組んでいます。この取り組みでは、CEOのhozumixさん、CDOのNob Nukuiさん達と共に、私たちにとって馴染みのある、そして理想のインターフェイスを備えたアプリというものを形にすべく、日々いろいろなコンセプトの検討を重ねています。
その中には、「複数のビューを切り替えられるインターフェイス」というものがあります。今回は、このコンセプトについて、少しロジカルに表現してみたいと思います。
昨年版：
多様なユースケースに対応するためのデザインアプローチ
ソフトウェアをさまざまなユースケースに対応させていく方法には、いくつかのアプローチがあります。一つは、機能を増やして得られる効果をなるべく大きくしようとするやり方です。もう一つは、一個のコンテンツモデルに対するインターフェイスの種類を増やすことです。
前者のやり方は、もっとも簡単で誰でも思いつく方法です。機能が増えれば、その製品でできることが単純に増えるし、それに比例してユーザーが得られる効果も増やせる見込みがあるからです。しかし、一つ大きな落とし穴があります。機能が増えるということは、インターフェイスに分岐条件が増えるということを意味します。分岐だらけのインターフェイスはほとんど場合使い方が複雑になるので、シンプルさを目指したいデザインの基本姿勢とは真逆の方向に作用しやすくなります。
後者のやり方は、「インターフェイスの種類を増やす」という部分だけ切り取れば、前者の機能を増やすこととほぼ違いが見られません。しかし、ここでは「一個のコンテンツモデルに対するインターフェイスの種類を増やす」と表現してみました。これはどういうことなのかを詳しく説明します。
そもそも「モデル」とは何か
モデルという言葉は多様に解釈される概念なので、その言葉の使用には注意を払わなければなりません。今回私が用いている「モデル」の意味は、概ね次の様な解釈に基づいています：
データやコンテンツの関係性を表した構造
（UI的な意味での）眼に見える実体を持たない
データベースのエンティティのようなもの
モデルクラスのようなもの
UIの中に流し込まれるデータやコンテンツは、インターフェイスの構造（ビューモデル）とは切り離して定義できます。このモデルを私は「コンテンツ構造のモデル」「コンテンツモデル」と言ったりしますが、細かい言葉の定義は置いておいて、構造設計の対象として、少なくともコンテンツとビューの二軸がある、ということをまずは理解すると良いかと思います（図1）。
コンテンツモデルの概念図
例えば、ファイルマネージャーにおけるコンテンツ構造を簡単に表してみると、おおよそ次のような具合に図示できます（図2）。
なんの変哲もない、非常にシンプルな概念図です。ディレクトリは再帰的に関係してくるので（あるディレクトリの中に別のディレクトリが入ることが考えられる）、自己参照の線を入れています。
各矢印には補足情報として多重度と呼ばれるオブジェクトの存在数を示す値を記述してありますが、簡単に図示する意図ならばこれらは無くても問題ありません。
ここで、「ディレクトリ」を指で摘み上げることをイメージしてみてください。すると、矢印が向いているその先の「ファイル」も繋がっているので、一緒にくっついてくる感じになります。まるで芋蔓式のように、関連する概念オブジェクトがぶら下がってくるような様子です。
そのイメージを持ったまま、インターフェイスのビューモデルを対応させることを考えます。「ディレクトリ」に着目したので、ディレクトリを中心に表現されるビューの姿はどういう見た目になるのか、どういうインタラクションが必要なのか、ということを「ビューモデル」で検討すれば良いのです。
ビューモデルの多様性
ビューモデルの多様性とは、要するにインターフェイスの種類のことです。いくつかの細かなユースケースに対する優先度の違いをビューモデルの設計に反映していくと、一つのビューレイアウトのみでは対応しきれなくなるため、ユースケースごとに適した個別のビューレイアウトを用意する必要性が生まれます。
レイアウトが異なる複数のビュー同士をコンテンツモデルと一緒に並べてみると、「一個のコンテンツモデルに対する、複数のビューモデル（インターフェイス）」という構図が現れます。これらのビューモデルはユースケースの差異はあれど、基本的には同じコンセプト「あるコンテンツモデルの中身を表示する」という指針を共有しているので、そもそも大目的は共通していて、そこに至るまでの細かなインタラクションの手段に差異が現れています。
このような説明を補足するのに理解しやすい例は、Finderの「アイコン」「リスト」「カラム」「ギャラリー」表示です（図3）。
Finderウインドウのこれらの表示切り替えは、いずれもファイルやフォルダを並べたコレクションの表示の仕方を変更するものです。ユーザーは、自らの用途や好みに合った表示方法を都度選ぶことができ、見やすいと思えるもの／探しやすいと思える表示方法を採用することができます。例えば、名前順で並べることを優先したいならテーブル表示である「リスト」が適していますし、階層の行き来と階層同士の比較を重視したいなら、ミラーカラムである「カラム」が適しています。
モデルベースの視点
このことをモデルベースの視点で見てみると、次の様な具合になります（表1、図4）。
コンテンツモデル (1)：
→ あるディレクトリ内の要素のコレクション
ビューモデル (1..N)：
→ このコレクションを表示する具体的な方法、レイアウト
※()内は存在数を示す多重度。
とあるディレクトリ（フォルダ）の中身を一個のコンテンツモデルと捉えて、このデータ構造を具体的なUIとして表すには、どのようなパターンが考えられるのか、と思考を巡らせます。Finderの場合は、Appleの開発者は「アイコン」「リスト」「カラム」「ギャラリー」の4種類のビューを対応させるのがユーザー体験として妥当であると判断したようです。
Finderの例では先に答えが解っていたので、改めてこう書いてみても特に面白みはありませんが、「一個のコンテンツ（ディレクトリの中身）」 対 「複数のビュー（表示方法）」の構図を理解するのに、イメージしやすいのではないかと思います。
「複数のビューを切り替えられるインターフェイス」をデザインに盛り込む
単にインターフェイスを複雑にするだけではシンプルさからかけ離れていってしまうことへの懸念は、冒頭で述べた通りです。インターフェイスの複雑化をなるべく避けつつも、一方で多様なユースケースに対応できるように、どうにかしてインターフェイスの種類を増やすアプローチをとらなければなりません。そのテクニックの一つが、コンテンツモデルを単純な形のまま保って、対応するビューの種類を増やすというやり方です。
皆さんが普段カレンダーアプリを使う時、そのビューの見た目はどのような表示になっているでしょうか？
月表示で「今月」を常にアクティブにしていますか？
それとも、週表示で「今週」を常にアクティブにしていますか？
あるいは、日表示で「今日の予定」を常にアクティブにしていますか？
カレンダーの概念モデルを検討すると、指し示す時間そのものの移動に加えて、時間軸のスケール（解像度）変更を同時に考えなければならないため、単純に予定を時間軸上に並べるだけでは、UIがうまく機能しません。しかも、ユーザーによって使い方の好みに差が現れやすい分野でもあるため、何か代表的なペルソナモデルを一人や二人分検討したところで、カレンダーのデザインとしてはユースケースを満たしきれない懸念があるのです。
カレンダーのいろいろな使い方を想定しながら、ただ単に機能をたくさん盛り込んでインターフェイスが複雑化することも避けなければならない。単純そうに見えて、実は非常に奥が深い分野だと思います。
では、その懸念を払拭したデザインを反映したカレンダーというものは、具体的にどういう姿をしているのかというと……これはまだ公表しないでおくつもりです。現在、タイムラボ社内で絶賛開発中ですので、その時が来たら改めて告知させていただきたいと思います。
ちなみに、今回用いたような情報設計の取り組みは、実際にタイムラボのデザイン現場でも意識して実践しているわけではなく、私が理解しているデザインの姿を今回のアドカレのためにただ整理し直しただけのものです。実際の現場では、もっと抽象的に、『〜みたいな感じ』『そういう感じ』『こういうのは避けたい』……ぐらいの非常にざっくりとした会話で議論しています。こういったハイコンテクストなやり取りが問題なく通じてしまう現場でもあって、私としては非常にクリエイティブに感じられています。
・・・
こちらは「タイムラボ Advent Calendar 2024」6日目の発信でした。