AD-Compass

UXリサーチから検証・改善まで設計したMVPプロダクト

AD-Compass

Summary

Challenge

展示会案件でアートディレクションを担い始めたユーザーは、役割や判断基準、確認のタイミングが曖昧な中で、周囲への遠慮も重なり、一人で判断を抱え込んでいた。

Solution

  • 課題を知識不足だけでなく、判断基準と相談タイミングが共有されていないこととして捉え直した。
  • 工程ごとに、自分で進めることと他者に確認することを整理した。
  • 相談相手・確認内容・タイミングを提示し、次の行動を判断できるプロセスガイドを設計した。

Role

UXリサーチ、要件定義、仕様設計、プロトタイプ制作、ユーザーテスト、改善

Type

個人プロジェクト

Time

2026/07 - 2026/08(約1週間)

Tools

NotebookLM

Gemini

Claude

FigJam

Figma Make

Overview

プロジェクト概要

AD-Compassは、展示会案件でアートディレクションを担い始めたユーザーが、判断に迷ったときに適切なタイミングで相談しながら案件を進められるよう支援するプロセスガイドです。

展示会案件を担当するデザイナーへのインタビューを起点に、UXリサーチ、課題定義、要件定義、仕様設計、プロトタイプ制作、ユーザーテスト、改善まで、一連のプロダクト開発プロセスとして取り組みました。

生成AIを工程ごとに活用しながらも、設計判断や改善方針は自身で行い、レビューとユーザーテストを通じてVersion3.2までブラッシュアップしています。

Research

UXリサーチ

展示会案件を担当し、デザイナーとアートディレクターを兼任しているユーザーへデプスインタビューを実施しました。

録音データをNotebookLMで整理し、困りごとや業務の流れ、関係者とのやり取りを抽出。その内容をFigJam上で構造化し、課題の背景や理想状態、要件候補を整理しました。

発言を分析すると、業務知識だけではなく、役割分担や判断基準の曖昧さ、相談しづらい雰囲気など、複数の要因が重なって判断を抱え込んでいることが見えてきました。

この分析から、知識を補うことではなく、判断と相談を支援する仕組みが必要だと考えました。

インタビューで得た発言を整理し、課題定義へつなげたFigJam

Problem

課題の再定義

リサーチを通して見えてきたのは、知識やマニュアルが不足していることではなく、判断基準と相談のタイミングが共有されていないことでした。

そこで本プロジェクトでは、「いつ・誰に・何を相談すればよいか分からず、一人で判断を抱え込んでしまうこと」を解くべき課題として定義しました。

その課題を解決するため、工程ごとに判断事項と確認事項を整理し、迷ったときに次の行動を判断できるプロセスガイドを設計しました。

Requirements

要件定義

リサーチで整理した課題をもとに、GeminiでPRDと要件定義のドラフトを作成しました。

その後、自身でレビューを行いながらMVPとして実現する範囲を整理し、必要な機能と優先順位を定義しました。

相談機能そのものではなく『相談へつなげること』を価値と捉え、Teamsなど既存ツールを利用する構成とし、チャット・通知・共同編集などは対象外としました。

Specification

仕様設計

Geminiで整理した要件をもとに、Claudeを活用して画面構成、画面遷移、状態遷移、データ構造を設計しました。

その後、仕様レビューを繰り返しながら画面仕様やエッジケースまで詳細化し、設計判断をドキュメントへ反映しました。

Version1

Version1 プロトタイプ

仕様設計をもとに、Figma MakeでVersion1のプロトタイプを生成しました。

生成されたUIをそのまま採用するのではなく、要件や仕様との整合性、情報構造、操作導線を確認し、課題を洗い出しました。

Version1は完成版ではなく、レビューと改善を前提とした最初の検証プロトタイプとして位置付けています。

自分で行うことと、他者に確認することを分けて表示したVersion1

Version1 Review

Version1 レビュー

Version1完成後は、ClaudeとGeminiによるレビューに加え、自身でもUX・情報設計・MVPの観点からレビューを実施しました。

仕様との整合性だけでなく、ユーザー課題を解決できる導線になっているかを確認し、相談導線や確認タイミング、状態遷移などの改善点を整理しました。

Version2

Version2へ改善

Version1のレビュー結果に加えて要件漏れレビューを行い、画面上の問題だけでなく、業務フローを成立させるために不足していた要件も見直しました。

Version2では、相談導線や確認タイミングの表現を改善し、工程メモ、過去工程の参照、完了案件の閲覧などをMVPの範囲内で追加しました。

このVersion2を、ユーザーテストに使用する検証版として位置付けています。

レビュー結果を反映し、ユーザーテストに使用したVersion2プロトタイプ

User Test

Version2 ユーザーテスト

Version2を対象に、実際のヒアリング対象者へ非同期のユーザーテストを実施しました。

自己申告だけに依存しないよう、タスク・設問・判定基準を事前に設計し、回答をもとにUX上の課題を分析しました。

得られた結果はVersion3.2の改善へ反映しています。

検証仮説、タスク、設問、判定基準を整理したユーザーテスト計画

Findings

ユーザーテストで分かったこと

テストでは、案件の現在地や次に行うことは概ね理解されました。一方で、相談するタイミングや画面の役割、完了後の扱いなど、一部で認識のずれが見つかりました。

特に、相談ガイドだけで相談まで完結すると誤解されたことや、振り返り画面を第三者へ提出するものと受け取られたことから、画面だけでなく情報設計や文言、状態遷移の見直しが必要だと判断しました。

これらの結果をもとに設計判断を行い、Version3.2へ改善を反映しています。

Design Decision

設計判断

ユーザーテストで得られた意見をそのまま機能へ反映するのではなく、背景にある課題や業務シナリオを整理し、MVPの範囲、実装コスト、既存仕様との整合性を踏まえて改善内容を判断しました。

例えば、「完了したと思った案件が再び動き出した場合に迷う」という課題に対しては、工程を自由に巻き戻す機能ではなく、完了状態を解除して納品工程から案件を再開できる導線として設計しました。

一方、工程単位の巻き戻しなどは、実務フローの検証が必要と判断し、今回は実装せず将来の改善候補として整理しました。

Version3.2

Version3.2へ改善

ユーザーテストで得られた課題に加え、自身でも実機レビューを繰り返し行い、UX・情報設計・文言・状態遷移の観点から改善を重ねました。

改善内容は仕様書にも反映し、プロトタイプと仕様の整合性を維持しながらVersion3.2としてブラッシュアップしました。

Prototype

Version3.2 最終プロトタイプ

リサーチ、仕様設計、レビュー、ユーザーテストを通じて改善を重ねた最終プロトタイプです。

判断と相談の流れを分かりやすく伝える情報設計へブラッシュアップし、MVPとして必要な体験を形にしました。

Reflection

振り返り

本プロジェクトでは、NotebookLM、Gemini、Claude、Figma Makeを工程ごとに使い分け、UXリサーチから要件定義、仕様設計、プロトタイプ制作、ユーザーテスト、改善まで、一連のプロダクト開発プロセスを構築しました。

特に、生成AIの出力をそのまま採用するのではなく、レビューやユーザーテストで得られたフィードバックをもとに、MVPの範囲や既存仕様との整合性を踏まえながら設計判断を繰り返したことが、本プロジェクトで最も大きな学びでした。

生成AIを開発プロセスの加速に活用しつつ、最終的な意思決定と品質の担保は自ら行うことで、仮説検証を繰り返しながらプロダクトをブラッシュアップするプロセスを実践しました。