UIデザインにおけるインターフェイスアーキテクトの役割

アーキテクチャ(Architecture)とは一般には建築や建築学を指しますが、コンピューターの世界ではあるシステムの概念や設計思想を「アーキテクチャ」という言葉で分類することがあります。中でもソフトウェアの領域では実装モデルの設計指針や分類、コンポーネントの相互関係、ソフトウェアの構築方法などを定めた一連の構造をそう呼ぶことがあります。

アーキテクト(Architect)とは建築家や(建築)設計士、技術者といった職種を指しますが、コンピューターの世界では「アーキテクト(仕組士): システムのアーキテクチャを設計する責任がある、人、チーム、あるいは組織」(IEEE 1471)と規定されます。要するに、システムの構造設計に関して責任を持つ役割です。「構造設計の指針を示し、実行する人」と言った方がわかりやすいでしょうか。

このような、構造設計やそれを担う設計士の役割は、当然のようにUIデザインの世界でも求められています。

インターフェイスアーキテクトの役割

ソフトウェア設計の世界には、ITアーキテクト、ソフトウェアアーキテクト、情報アーキテクト(インフォメーションアーキテクト)と呼ばれる職種がすでに存在します。いずれも何かしらの「設計」に関して責任を持つ職種です。
Goodpatchでは、UIデザイナーの役割の一つとして独自に「インターフェイスアーキテクト」を置いています。

【インターフェイスアーキテクト】 Interface Architect
GUIの構造や設計パターン、システムの仕組みに精通しており、アーキテクチャの設計に責任を持つ「UIデザイナー」の一種。GUIに関する概念・設計思想の定義、ドメイン設計、情報設計、OOUIモデリング、インタラクションの仕組み設計を中心に、ソフトウェアの“拡張性”を考慮しながらデザインに取り組む。

インターフェイスアーキテクトは分類上は UIデザイナー です。ただし、インターフェイスアーキテクトは一般に知られる「UIデザイナー」とは少し異なる領域を担当します。

UIデザインの構造段階

インターフェイスアーキテクトの役割を説明するためには、有名なJJGの「5段階モデル」を参照するのが良さそうです。ここまで〈構造〉という言葉が何度か登場しましたが、5段階モデルにも構造段階が存在します。

The Elements of User Experience

この図はオリジナルの “The Elements of User Experience” とは少し異なる解釈をしていることに留意してください。「Webにおける二つの側面」という視野だけでは本質的なソフトウェアデザインを俯瞰できなくなるため、より抽象化してあります。

これらの段階のうち、構造から表層にかけてがいわゆるUIデザインの領域です。その下の部分、戦略から要件にかけてがいわゆるサービスデザインの領域だろうと考えられます。今回着目するのはUIデザインの領域です。

構造、骨格、表層、それぞれに代表的な役割を当てはめてみると次のようになります。

  • 構造情報設計、モデリングなど、アーキテクチャの設計
  • 骨格ワイヤーフレーム設計、レイアウト設計、状態遷移など、構造を具現化するための骨組みの設計
  • 表層アイコン、タイポグラフィ、色、サウンド、モーションなど、人間の視聴覚に直接関わる設計

UIデザインというとどうしても〈表層〉に寄ったデザインと捉えられがちです。「UIデザイナーは、アイコンやグラフィックス、色、タイポグラフィを整える人」だというのがおそらく世間一般の認識でしょう。ある意味で正しいのですが、しかしこれだけでは「UIの見た目にしか責任を持たない人」となってしまい、その下の段階を担う役割が不在になってしまいます。私たちは〈骨格〉〈構造〉まで含めた範囲が本来のUIデザインの領域で、3つの段階すべてがUIデザイナーの役割であると考えています。

UIデザイナーの役割は、〈構造〉〈骨格〉〈表層〉段階の設計である

これまでの経験から、多くの現場ではこの〈構造〉段階があまり認知されておらず、具体的なデザインの役割が不明瞭で重視されていないか、まったく考慮されていないように感じられることがあります。仮にこの〈構造〉が抜け落ちてしまうと、要件定義からいきなりワイヤーフレームを描く ようなことになります。経験豊富なデザイナーであるならこの技は効果的にはたらくこともあるでしょうが、ほとんどの場面では「画面を描きながら情報構造とレイアウトと画面の状態遷移と色とタイポグラフィを同時に考えなければならない」なんてことになってしまいます。とても効率的とは言えませんし、もしも要件に修正が入って手戻りが発生したとすると、〈骨格〉や〈表層〉の成果をすべて捨てて〈要件〉の段階まで一気に戻らなければなりません。せっかくビジュアル作ったのに……!!

構造が抜けて壊れた5段階

〈構造〉が抜けることで、以降の設計作業が非効率になる、手戻りが発生した場合の巻き戻しが大きすぎ、余計にコストがかかる。戻るにせよ、どこまで戻って良いのかもはっきりしないため、迷いが生じやすくなってしまう。アーキテクチャが定義されないので設計そのものが成り立たず、インタラクティブに作用するUIの設計ではなくただの“お絵かき”になってしまう——。このような〈構造〉を重視しないデザインの進め方にはリスクがあると言えます。

私たちは数多くのデザインの現場に携わってきた経験から、「UIとは表層だけではなく、その基礎設計が大切であること」「構造からデザインしなければ成り立たないこと」「設計の手戻りを想定しながらプロトタイピングの連鎖を回す」というプロセス上の解を導き出しました。インターフェイスアーキテクトの役割は、UIデザインにおける〈構造〉段階を中心にデザインと向き合う、UIにおける基礎設計を担う立場であって、この役割はソフトウェアデザイン業務では不可欠な存在だと考えています。

UIデザインの二面性

私たちは、エンジニアリングがそうであるようにUIデザインにも二面性があると考えています。あえて言うならば、〈フロントサイドUIデザイン〉と〈バックサイドUIデザイン〉です。実際にそのような肩書きを採用しているわけではありませんが、役割の捉え方としてはしっくりくるかと思います。ソフトウェアエンジニアリングの世界ではバックエンドエンジニアがフロントエンドエンジニアを兼務することも稀にありますが、一般には両者は分かれています。なぜなら両領域はあまりにも広すぎるし、考え方や技術の性質、トレンドも大きく異なるからで、専門職を立てて分担・分業するには表裏分けた方が効率的だからです。区別されていた方が専門のエンジニア人材も確保しやすいことでしょう。
同様にUIデザインの領域も「あまりにも広すぎる」のが実際のところですが、世間の認識ではまだ一つの括りで捉えられることの方が多いように感じられます。個人の能力差や作業効率等を考えても、フルスタックにUIデザインのすべてを担える人材はそう多くはないのが現実ですし、プロジェクトが大きくなればなるほど作業の分担が必要になり、必然的に表側と裏側の役割を区別する必要性が生じます。

表側のビジュアルデザイナーに対し、裏側のインターフェイスアーキテクトという表裏一体の組み合わせにより、高品質かつ効率的なUIデザインというものと向き合う準備が整います。

もう一つの背景

VUCAの課題

現代は “VUCA” の世界と言われます。あらゆるものが複雑で不確実、そして将来どうなるのかその予想がとても難しい世の中です。ITの世界を支配しているプラットフォーマーは毎年のように新しいOSやデバイスを発表し、数年前の技術を置き換えます。去年のトレンドが今年には完全に下火になっていたり、突然の破壊的変化によって既存の常識がすべてひっくり返り、業界丸ごと消えてしまうなんてことも普通にあるわけです。政治、経済、世界情勢、イノベーション、あらゆるものの変動が激しく、それらが単一の領域で起こっているわけでもなく、どこで何がどうなるのか誰にも予測がつかない、そんな世界に私たちは生きています。

拡張性と柔軟性

一人の人間としては、その変化に闇雲に抗ってもきっと仕方がなく、きちんと対応し得る拡張性柔軟性を持ち合わせることが “VUCA” の世で求められるスタンスなのだろうと思います。ソフトウェアデザイン、UIデザインという領域ももちろん例外ではなく、デザインもきちんと拡張性を考慮する、環境変化に柔軟に対応する、制作作業は手戻り前提で取り組むといったことが、この世で生き残る術なのでしょう。

不確実性が高いわけですから、ソフトウェアの要件定義をしたら何がなんでもそれを線形に作り上げるのではなく、「手戻り」することを想定して堂々と巻き戻す柔軟性を身につけておくことが大切です。将来を見据えて拡張性を考慮しておくことも必要です。そしてその価値観を受け入れるチームの存在が不可欠でしょう。

理想的なデザインの5段階

Goodpatchでは、失敗を称賛はしませんがいきなり否定することもありません。誰もが失敗するのは当たり前ですし、早く、小さく失敗して「次は間違わないようにする」のが大切だという価値観を持ってデザインに取り組んでいます。
失敗とは、それはある意味で大きな価値なのです。「失敗の知見を得た」と考えれば、それは成功者や未経験者は知らない ナレッジ となるわけです。もしかしたら同じような問題に直面している他のチームの助けとなることもあるでしょう。ロケットの打ち上げにたまたま成功し続けているよりも、一度の打ち上げ失敗事故により潜在的なバグが早く明らかになった方が中長期的には良いと考えることです。

このような、失敗した事例、もちろん成功した事例も含め、メンバー各々がナレッジとして蓄え、次に活かす取り組みを組織全体で推奨しています。

ソフトウェアデザインの対象

GoodpatchではUIデザインもソフトウェアエンジニアリングもまとめて「ソフトウェアデザイン」だと考えています。ソフトウェアという人類史上もっとも複雑な対象の一つをデザインするのだ、という使命は、この領域に関わるすべての人々に共通することなのです。

3つのモデル

ソフトウェアデザインの対象は大きく3つのモデルで区別できます。〈実装モデル〉〈脳内モデル〉そして〈表現モデル〉です。

実装モデルはシステムの仕組みに関する構造です。エンジニアリングやそれに関わるデザインはここに当てはまるでしょう。

脳内モデルは人間の心理に関わる構造です。UXやインタラクションデザインにおけるユーザーのメンタルモデルはここに当てはまるでしょう。

表現モデルは二つのモデルに挟まれる形で存在している構造です。すなわち、ユーザーインターフェイス(UI)です。UIはシステムの仕組みをそのまま映し出すことはそうありません。もしそのようなUIがあるとしたら、それはきっとモーダルでとても「使いづらい」ものとなっていることでしょう。UIデザイナーの役割は、ユーザーがソフトウェアの扱い方を理解できるように彼の脳内モデルにうまく投影できるような表現をデザインしてあげることなのです。

GUIの歴史を振り返ってみると、それは本来ソフトウェアの一部であることは明白です。いま一度原点に立ち返り、GUIがOOUIであるように、UIデザインを「画面コンセプトの描画」ではなくきちんとソフトウェアデザインとして捉え直す視点が必要です。ソフトウェアデザインはコンピューターの世界にははじめからあったひとつの概念で、UXだとか言われるようになった現代においてもそれはきっと不変であることでしょう。だからこそ、この領域でインターフェイスアーキテクトという役割が大きな価値を発揮するだろうと考えています。

ソフトウェアデザインにおけるインターフェイスアーキテクトの提供価値

インターフェイスアーキテクトの人々がソフトウェアデザインにどう関わるのか、具体的な進め方としてはまずUIにおけるアーキテクチャの設計思想を定めること、次にモデリングを行うことが挙げられます。そしてそれらをUIとして成り立たせるためのインタラクション設計を行うところまでが主な担当領域となります。

(今回はそれぞれの工程の簡単なご紹介にとどめ、具体的な進め方については改めて別の記事でご紹介する予定です。)

UIの設計思想

UIの設計思想は、そのUIをどのようにして成り立たせるのか、ユーザーがどう対話するのか、どのように感じられるのかなどを言葉によって明文化したものです。よく知られるデザイン原則やユーザビリティ原則であったり、HIGに書かれているようなデザイン原則を参照しながら、デザイナーがデザインの対象となるオブジェクトの在り方であったり、その世界の秩序を表すための思想を示すのです。

設計思想

例えば写真コンテンツを多く扱うメディア系アプリケーションを作ろうとするのであれば、UIのビジュアルを控えめにしてコンテンツ主体の設計にするとか、写真が映えるレイアウトを検討するとか、解像度は高い方が良いが読み込み速度とトレードオフ関係になりやすいため、そこをインタラクションでどう解決するのかとか、そういったことを挙げてゆきます。そしてこれら中から本質を指し示すであろうキーワードを抽出し、UIデザインの基本指針をわかりやすい言葉でまとめあげます。

UIの設計思想を定めておくことで、後の工程においてデザインの道標として機能するようになり、少なくとも道は踏み外さないようになるでしょう。デザインの意図を説明する理由としても有効にはたらきますし、UIの評価を行う際の観点にもなり得ます。

モデリング

モデリング

モデリングにはいくつかの工程があります。現場によって様々だとは思いますが、Goodpatchのクライアントワークでの代表的なモデリング工程は次のような様子です。

  1. 調査と分析
  2. 概念定義・ドメイン設計
  3. オブジェクトモデリング
  4. UIモデリング

調査と分析

モデリングに取り組むにあたってまずは対象となる製品や取り巻く環境などの調査を行います。すでに形がある製品であれば、まずはそれに触れてみてUIの様相だとか振る舞い方などをよく観察し、課題を洗い出します。ときにはユーザーとデザイナー二つの人格を持つようにし、ユーザーとしても製品に触れるように心がけます。一方でエキスパートレビューの要領で課題を分析することもあります。そして、形あるUIから裏側のモデルをイメージして描き出す「リバースモデリングと呼ばれる独自の手法により、そのUIのオブジェクトモデルを描画してから、モデルのどこに課題があるのか、どこに拡張性を持たせられるのかといった検討を行います。
ゼロイチの制作では対象のリバースモデリングは行いませんが、参考にする他の製品をリバースモデリング作業にかけて検討材料にすることがあります。

そのほか、構造段階の前の要件定義をインプットとして取り入れたり、さまざまな環境制約というものをこの段階でも整理しておきます。時には要件の修正を提案することもあります。

これらの分析は以後の作業工程で検討材料として有効活用されます。

概念明示・ドメイン設計

UIデザインの初期の段階ではまず、ユーザーが触れるUIにはどのような概念が現れるのかをデザイナーモデル上で明らかにします。ユーザーや触れる対象となるオブジェクトはどのように存在しているのか、です。まずその世界そのものの概念から形作ってゆき、次第に具体に着目していくやり方が基本となります。システムの機能やGUIの具体的な挙動——形状、触れた時の状態変化、アニメーションの仕方など——を考える作業はずっと後の工程になるでしょう。

概念の明示で大切なのは、どのようなドメインがあるのかに着目することです。ドメインとは関わるオブジェクト(ヒトや操作対象物など)の関心事や影響を及ぼす範囲、活動領域、一種の環境だと考えてもらえれば何となく意味は伝わるでしょうか。そこに概念があることはわかっていても、具体的な形として表さない限りは直接触れることができませんから、そのためにもまずは概念をある種のモデルとして表す必要があります。

この段階では同時に概念への命名と共通言語を定義する作業にも着手することがあります。ドメイン駆動設計(DDD)でいうユビキタス言語の醸成に当たります。ある概念がドメインとして現れたならば、それを唯一の呼び名で定め(あるいは別の呼び方を紐づける)、関わる人々全員の共通認識として定着させることを目指します。そこにはデザイナー、エンジニア、ディレクターの違いはありません。関わる全員が共通言語で会話する意識を持つことが大切です。この頃に行われる会議ではきっと『(概念図を見ながら)この部分を○○と呼びましょうかね』なんて会話が行われていることでしょう。

「命名することがデザインの第一歩」
デザインにおける命名について考える

オブジェクトモデリング

GoodpatchのインターフェイスアーキテクトはUIを〈オブジェクト指向〉に捉えます。いわゆるOOUI (Object-Oriented User Interface)です。
ユーザーはUIを通じて、ソフトウェアの世界、さらにはその“向こう”の観念の世界にきっと在るであろう〈オブジェクト〉に触れようとします。しかしながらそれは直接は触れられない“何か”であるため、そのオブジェクトを自身の精神に内在化し、あたかも直接触れ感じられるようなデザインを目指す必要があります。このインタラクションの構造を築くために、まずオブジェクトを見える形として表そうとする作業がオブジェクトモデリングになります。

UIクラス図

具体的な方法としては、オブジェクト指向プログラミングの世界にもある概念〈クラス〉と〈インスタンス〉の考え方を導入し、またそれらの設計手法として広く知られているUMLをデザイン言語として採用します。UMLはそのままの形式を採用するのではなく、我々が若干のカスタマイズを施した「UIクラス図」と呼ばれる独自のデザイン言語を使用します。

UIモデリング

UIモデリング

UIモデリングではUIクラス図から具体的なUIを形作る設計を行います。オブジェクト指向にクラスからインスタンスを生成する要領で画面に現れるビューの姿を検討します。「ある状態ではどのプロパティを表示するのか」「ユーザーはどのような操作を行えるのか」などをビューに反映させながら、同時に状態遷移やナビゲーションも見据えてビュー同士の関係性も明らかにしていきます。同じオブジェクトが多数現れる〈複数型〉のビューでは必要最低限のプロパティのみ、一つのオブジェクトのみが現れる〈単一型〉のビューではきっと詳細画面でしょうからクラスに備わる属性を全て表示するといったことが考えられます。何か操作を行うならボタンやメニューなどUIに作用を与えるUIコントロール部品の設置を検討できます。

そのほか、Master-Details パターンなどの設計原則を応用しつつ、「具体的なレイアウトがまだ備わっていない素の画面」をコンポーネントとして定義していきます。この段階ですでに簡素なワイヤーフレームが描かれ始めていることでしょう。

インタラクション設計

インタラクションの方法

インタラクションデザインとは本来はもっと広い領域におけるデザインの営みです。ヒトとオブジェクトがインターフェイスを介して互いに対話している環境をデザインするのがすなわちインタラクションデザインであると考えられます。そこにUIがあるということはインタラクションが起こり得るということですから、このことはあらゆるレイヤーで考える必要があります。

UIモデリングに続く作業ではよりインタラクションの範囲を絞り、あるドメインの中に現れるであろうオブジェクトとユーザーの対話方法を探ります。オブジェクトがただ存在するだけではUIに触れても何も起きませんから、それらに触れる方法というものを具体的に検討するのです。

ソフトウェアデザインのイディオム構築

プラットフォームやデバイスのフォームファクターなどによる制約や基幹技術を考慮しながら、具体的なUIの形を見据えたインタラクションの方法を検討します。対象がPCであればマウスやキーボードを中心とした操作、スマートフォンであればタッチを中心とした操作を起点としてその入力方法が検討できますし、同時に表示方法も考えることができます。このようにして最小単位から次第にルールを組み合わせていって、インターフェイス固有の/よく知られた表現「イディオム」を構築してゆきます。そのためにも、デザイナーは対象となるソフトウェアの基本的な仕組みや操作方法をよく理解しておく必要があります。ここの設計を間違えると、たとえ“正しいモデル図”を描けていたとしてもなんだかとても使いにくいUIに仕上がってしまうことがあります。

もしも“⌘C”で選択対象をコピーできないUIに出来上がっていたとしたら、それはデザイナーが「コピー」という操作の本質、もしくは「コピー機能のショートカット操作」を間違って解釈してしまった可能性が考えられます。Windowsのみを前提に“Ctrl-C”をハードコーディングしていたらならば、macOSやそのほかのプラットフォームではこれは当然機能しなくなることが予想できます。

アプリケーションのUIのイディオムを構築する際には、それらを支える下の層にもプラットフォーム固有のイディオムが存在している事実を考慮することも重要です。このように、UIデザインではインタラクションの方法を見据えながらモデルを正しく表現することも大切です。

UIデザインのアーキテクチャを設計する

インターフェイスアーキテクトの役割としては、「UIデザインのアーキテクチャを設計する」とまとめられます。
具体的には…

  • UIの設計思想を明らかにし、デザインの道標を示す
  • UIに関わる概念を明らかにする
  • UIに関わるドメインを設計する
  • OOUIの観点を持ちながらオブジェクトを明らかにし、UIの構造をモデリングする
  • UIに関わるさまざまな技術を検討しながら、インタラクションの方法を設計する

といった表現で箇条書きできるでしょうか。さらに詳しくそれぞれの工程で何をするのかについては、また改めてお話ししたいと思います。

おわりに

GoodpatchのクライアントワークではUIクラス図を描くデザイナーオブジェクト指向を実践するデザイナーが多く活躍しています。その領域を専門的に担うメンバーもいれば、あるプロジェクトではビジュアル領域、別のプロジェクトではアーキテクチャ領域という具合に、柔軟に役割を切り替えながら実践しているメンバーも在籍しています。このようなチームでデザインに向き合う体制があることはGoodpatchの明確な強みであると確信しています。

もしお困りの案件がございましたら、クライアントワークとしてお受けできるものはぜひこちらのフォームからご依頼ください。そのほか、御社のプロダクトが抱えるデザインの課題分析・フィードバック、UIデザインの分野に関するワークショップや登壇のご依頼なども随時受け付けておりますので、お気軽にお問い合わせください。インターフェイスアーキテクチャからビジュアル、UX、エンジニアリング、そのほかさまざまな領域でご対応いたします。

お問い合わせフォーム | Goodpatch

また、Goodpatchではインターフェイスアーキテクチャをはじめ、UIデザインに関わるさまざまな領域で活躍したいデザイナーも随時募集しております。もしご興味ありましたらこちらから応募くださいませ。お待ちしております。

採用情報:Design Div. UIデザイナー

ABOUTこの記事をかいた人

丸 怜里

ソフトウェアデザイナー、インターフェイスアーキテクト。 学生時代からmacOS / iOSネイティブアプリケーションの開発手法を独学で学び、iOSデベロッパーとしてさまざまなクライアントワークに従事。GoodpatchではiOSデベロッパーの経験と、UIの構造設計、情報設計、インタラクション設計、OOUIに強みを持つデザイナーとして、放送系、メディア系、料理系、金融系などさまざまな領域のクライアントワークに携わる。そのほか、ユーザビリティ評価、UI設計へのアドバイス、イベント登壇なども手がける。
  • Goodpatch Blog