UXをどうUIに落とし込むか──4つのモデルで考えるモデルベースUIデザインの実践

スマートフォンアプリをはじめとするソフトウェアのUIデザインに、UXデザイン・ユーザーリサーチの成果を反映するにはどうすればいいのでしょうか。「モデルベースUIデザイン」を提唱するソフトウェアデザイナー／デベロッパー・丸怜里さんに、その考え方と方法論を聞きました。（『Web Designing 2025年10月号』より抜粋）

プロフィール

UXデザインからUIの要素を定義する

モデルベースUIデザインでは、UXデザインの成果物から4つのモデルを定義します。「モデル化」の意味と役割、つくり方の概要を解説します。

#1｜デザインの対象を定義する「概念オブジェクト」

私は「UX」を、十人十色の内面的・主観的なものであり、第三者が造形できるようなデザインの対象物ではないと解釈しています（※）。デザイナーにできるのは、プロダクトを通して間接的に影響を与えることだけです。では、何をデザインの対象とすればいいのでしょうか。

UXデザインでは、十人十色の体験を便宜上ひとつの「想定されるユーザー体験」としてモデル化します。ユーザーストーリーやジャーニーマップなどの成果物がそれです。モデルベースUIデザインでは、これらに含まれる要素を4つのモデル「概念オブジェクト」「ユースケース」「タスク」「コンセプト」に変換し、デザインの対象とします。

概念オブジェクトとは、形のない情報を役割や性質で識別し「オブジェクト」とした要素で、ソフトウェアが扱う「モノ」を定義します。まず、ユーザーストーリーやジャーニーマップに記述される「モノ的な要素（名詞）」を抽出し、一覧にします。これらを「ユースケース」定義の構文にある「何（目的語）」に当てはめ（P065)、ユーザー体験の実現に必要なモノを取捨選択していきます。これにより、ソフトウェアが扱うべきモノを、ユーザーの意図に沿った形で定義できるわけです。

さらに、概念オブジェクト同士の関係性をユースケースの定義に沿って、ダイアグラムで示したものが「概念モデル」です。これを構築すると、ソフトウェアが「何を・どのように扱うか」を構造として捉えることができます。

（※）UXには世界共通の一定した定義がないとされるため、ひとつの解釈として。

#2｜ユーザーの用途を言語化する「ユースケース」

ユースケースとは、もともとシステム開発の分野で「ユーザーが達成したい目的や操作の流れ」を示すための技法です。私はこれを、ユーザー視点をデザインに反映させるモデルのひとつになると考えました。しかし、元が開発者向けの技法であるため、デザインの視点は入り込みにくく、記法も専門的で難解です。そこで、再解釈して記法を簡素化し、要素も絞った形でモデルベースUIデザインに取り入れました。

具体的には、ユーザーストーリーやジャーニーマップの記述を基に「『誰』が『何』を『行動』できる」というシンプルな構文を用い、ユーザーがどんな用途でそのソフトウェアを使うのかを定義していきます。これをリスト化し、必要な機能、振る舞い、インタラクションに変換していくのです。

構文の「何」には先に挙げた概念オブジェクト（モノ）が相当し、「行動」には後述するタスク（コト）が結びつきます。実現すべきユーザー体験、および必要なモノ・コトが、この構文によって明確になり、チーム内で齟齬なく共有できるわけです。

一般的に、ソフトウェア開発の現場では先に「機能一覧」を定義し、セクションごとに分類してWBSで管理する手法がよく採用されますが、UIの振る舞いまでは検討されにくく、機能として定義される要素の粒度もバラつきがちです。一方、先にユースケースを定義する方法なら、必要な振る舞いを必要十分にデザインの対象に定義できると考えられます。

モノ・コト・コンセプトからUIへ

「概念オブジェクト」「ユースケース」の定義と並行して、「タスク整理」でコトの情報を構造化し、「コンセプト」でデザインの指針を定めます。

#1｜ユーザーの動作と機能を繋ぐ「タスク整理」

タスクとは、ソフトウェアにおけるユーザーやシステムの行動です。「モノ」を定義する概念オブジェクトに対し、タスクは「コト」を扱います。

まずUXデザインの成果物から「コト的な要素（動詞）」を抽出し、ユースケースに関連づけて一覧にします。これがユーザーのタスクです（表左列）。そして、それぞれにシステム側のタスクを対応させていくことで（表中列）、ソフトウェアの働きを構造的に示すことができます。実際にはより細かく分類した後（表右列）、ユースケース定義と対応させてタスクの不足・除外を評価します。

やや開発寄りの部分ではありますが、デザイナーにとってはユーザーから見た機能とソフトウェア上の処理を結びつけて捉える材料となり、機能を前提とした概念オブジェクトの視覚化に役立つはずです。

（※）CRUD（クラッド） ： Create（作成）、Read（読み込み）、Update（更新）、Delete（削除）の頭文字を取ったデータベース用語

#2｜UIデザインの方向性を決める「コンセプト」

UIデザインにはもう一つ、デザインの指針を示す「コンセプト」が必要です。コンセプトとは、想定するユーザー体験や設計思想を簡潔に言語化したものです。「提供したいユーザー体験」「設計思想」「何をするものか」「コンセプトイメージ」の4つを柱として定義します。ここでは詳細なプロセスには触れませんが、必然的にUXデザインの成果物に含まれるユーザーの意図が色濃く反映されたものになるはずです。

ここまで、4つのモデル化を通じて、ユーザー体験の実現に必要な要素をUIデザインに取り入れる考え方を解説してきました。実際のモデルベースUIデザインでは、さらにUIの構造設計から表現設計へ至るプロセスがあります。関心のある方は書籍をご参考ください。

また、ここまでの流れでわかるように、UXデザインの過程で得られた成果はソフトウェアの開発・デザイン全体に影響を及ぼします。その意味で、UXデザイナーはまとめた成果物を次の工程に託すだけでなく、積極的に制作フェーズ全体に関わることが推奨されます。

COLUMN｜既存製品の構造を読み解く「リバースモデリング」

モデルベースUIデザインの考え方は、既存のソフトウェアの構造を外側から評価することにも応用できます。これを「リバースモデリング」といいます。ソフトウェアの現物さえあればできるので、競合製品の調査分析や自社製品の検証などに役立ちます。ポイントは、ソフトウェアの見た目や機能から「概念モデル」を推測することです。

具体的には、まずUIに現れるモノ（オブジェクトやメタファー）に着目し、それらを概念オブジェクトの候補としてリスト化します❶。フレーム構造の異なる複数の画面に、見た目を変えながら繰り返し現れるオブジェクトがあれば、概念オブジェクトの可能性が高いといえます。さらに、ユースケースの構文に当てはめたり、タスクから目的語を抽出したりして、“推測上の概念オブジェクト”を定義します❷。それらをUIの各画面に対応させ、相互の関連や表現パターンなどを観察し、具体的に情報がどう扱われているのか、概念モデルの構造を推測します❸。

例えば競合製品の分析から「ユースケースの不足点」や「概念オブジェクトの扱いの違い」などが見つかれば、比較による自社製品のコンセプト補強や改修ポイントの発見に繋げることが可能です。

取材・文：笠井美史乃