Triplite
「Triplite（トリップライト）」は、紙の申請業務をオンラインで完結できるように再構築した、出張申請・承認サービスです。入力から承認、進捗確認までを迷わず進められる設計を目指しました。
- Webアプリ
- リサーチ
- コンセプト定義
- 情報設計
- ビジュアルデザイン
プロジェクト概要
- カテゴリー：Webアプリケーション、SaaS
- 制作種別：自主制作
- 担当領域：要件定義、情報設計、ビジュアルデザイン
- 使用ツール：Figma
- 制作期間：1.5ヶ月
どんなプロダクトか？
本プロダクトは、紙で運用されていた出張申請・精算フローをオンライン上で統合し、一気通貫で処理できるように再構築した社内向けワークフローシステムです。 「迷わず・滞らず・一気通貫で完了できる」をコンセプトに、申請作成から承認、精算までの流れを途切れさせない情報設計と、進行状況を把握しやすいUIを重視しています。
最終成果物
以下でプロトタイプとFigmaのデザインファイルを掲載しています。
プロトタイプ
＊拡大推奨
Figmaデザインファイル
TripliteのFigmaファイルはこちら
要件定義、情報設計、ビジュアルデザインのデータを公開しています
設計プロセス
本プロジェクトは、実務を想定した演習として取り組んだ自主制作の UI/UX 設計で、架空の企業を想定し、 「これまで紙で行っていた出張申請〜精算承認のプロセスを、社内の承認フローを踏襲しつつオンラインで完結できるシステムとして再構築する」という前提条件を置いています。
具体的には、「申請 → 上長の承認 → 経理部の承認 → 仮払い → 出張 → 出張終了後の精算申請 → 経理部の精算承認」という既存の社内フローを変えずに、 その流れにフィットする業務システムを新規に設計する、という設定です。 この要件を起点に、実際のプロダクト開発に近いプロセスを想定しながら、要件定義・情報設計・ビジュアルデザインまで一連の設計演習として進めました。
以降で、詳細な設計プロセスを説明します。
1. 要件定義
まず、紙運用で発生しがちな課題を行動フローから抽出し、新システムが目指す状態を整理しました。 そのうえで、競合サービスの分析やペルソナ設定を通じてユーザーの課題や行動を深掘りし、本サービスのコンセプトと要件を定義しています。
1-1. 行動フローの整理
既存の申請・承認に関する行動フローを整理し、課題の整理や、プロダクトが目指す状態を整理しました。
1-2. ペルソナ設定
次に、ペルソナを設定し、ユーザーの課題やニーズを深掘りました。ペルソナは、申請者・承認者・経理担当の3つの役割を中心に設定しました。
- 申請者（一般社員）：記入漏れや差し戻しを避け、短時間で申請を完了したい。
- 承認者（上長）：一目で内容を把握し、迅速に承認判断をしたい。
- 経理担当：不備の少ないデータで正確に処理し、履歴を効率的に管理したい。
以下が詳細なペルソナの内容。
1-3. 課題の整理と提供価値の定義
行動フローとペルソナの内容を参考に、紙での申請・承認業務の課題整理と、プロダクトの目指す状態および、コアコンセプトを定義しサービスの方向性を定めました。
2. 情報設計
2-1. ユースケース洗い出し
まず、行動フローや既存の出張申請サービス（紙・ソフトウェア両方）をベースに、ユースケースを洗い出しました。 ユースケースは、「誰が・何を・できるか」で、利用シーンと合わせて整理しました。
2-2. オブジェクト/アクションの抽出
次に、ユースケースを元に、オブジェクトとアクションの抽出を行いました。
2-3. メインオブジェクトの特定
次に、メインオブジェクトの特定を行い、付随するアクションを整理しました。
2-4. ビューとナビゲーションの検討
次に、各ビューの役割と、それらの遷移関係を整理しました。 申請一覧・詳細・編集・精算・承認といった一連の業務プロセスを画面単位で可視化し、それぞれのビューがどの情報を保持し、どのタイミングで他のビューへ遷移するのかを把握できるようにしています。
なお、この遷移関係は初期案のままではなく、レイアウトパターンの適用やローファイプロトタイプを用いた動作検証を通して、 ユーザーの操作負荷や判断ポイントを分析しながら、何度も改善を重ねてブラッシュアップしたものです。
2-5. プロトタイプ作成
次に、レイアウトパターンを適用し、ワイヤフレームを作成した後、コア機能に絞ったプロトタイプを作成しました。
この段階では、コア機能（申請、承認のフロー）のフローの最適化や、各ページの情報の優先づけ、グルーピングを重視して設計。 プロトタイプを動かしながら、検証改善を重ね、ブラッシュアップしました。
3. ビジュアルデザイン
3-1. ビジュアルコンセプト・トンマナ
サービスコンセプトである「迷わず・滞らず・一気通貫で完了できる出張申請」を視覚的にも支えるため、まずキーワード抽出とブレストを行い、「軽やかさ」「空」「鳥」などのイメージを導出しました。 それらをもとに、操作の流れが明瞭で見通しの良い UI を目指し、配色・タイポグラフィ・形状などの主要なビジュアル要素へ落とし込んで全体のトンマナを構築しています。
なお、フォントに関しては、Web フォントを使用せず、システムフォントを採用しています。 その理由は、SaaS というサービス特性上、フォントの見栄えを追求するよりも表示速度と操作性の快適さを優先する必要があるためです。 Web フォントは読み込みコストが発生し初回描画が遅れる可能性があるため、OS 標準のシステムフォントを用いることで、軽快な操作体験と十分な可読性を両立しています。
3-2. UIビジュアル
ビジュアルコンセプト・トンマナを定義した後は、ワイヤフレームにスタイルを当てはめ、 UIのビジュアルをブラッシュアップするとともに、関連機能などのUIも設計していきました。 基本的に視認性、操作性の観点から、インタラクションコストを最小化するUI設計を意識しています。
以下、申請一覧ページ
以下、新規申請ページ
3-3. プロトタイプと検証改善
UIのビジュアルをブラッシュアップしたら、プロトタイプを作成し、実際のプロダクトに近い挙動で細かいフローや情報のグルーピングなど検証と改善を重ねました。
3-4. コンポーネント設計・スタイルガイド作成
UIビジュアルをブラッシュアップしていく過程で、全体の保守性、一貫性を保てるようにコンポーネントを整理しました。また、合わせてスタイルガイドも整備しています。
工夫した点
工夫した点①：OOUIに基づく一貫した情報設計
本プロジェクトでは、表層的なUIの見た目や操作性だけでなく、アプリケーション全体の情報構造とナビゲーションを設計することに重点を置きました。 業務フローをオブジェクトモデリングによって丁寧に分解し、複雑化しやすい業務フローをシンプルで一貫した構造に落とし込みました。
その結果、ユーザーは画面ごとに意味や操作方法を迷うことなく、自身が行うべきタスクの位置づけを自然に把握できるようになり、 学習コストが低く、メンタルモデルに沿った利用体験を提供できる設計となっています。
工夫した点②：新規申請をモードのステップ式に
新規申請のページは、単一ページ式にするか、ステップ式にするかに関して、両者のUIを作成しプロトタイプを動かした上で、 それぞれのメリット・デメリットを比較し、出張申請の性質（利用頻度・正確性等）や、想定ユーザーから考え、ステップ式のUIを採用しました。 また、新規申請の作成という重要な操作であることから、操作へ集中させるためモードを採用しました。
工夫した点③：ボタンのスタイル、配置、文言に関して
ボタンに関しては、見た目だけでなく「意味」と「挙動の解釈」を間違えさせないことを重視して設計しました。 まず、ボタンやラベルの文言は、ユーザーが迷わず意図を読み取れることを最優先にし、「送信」「登録」など抽象的な表現ではなく、 「申請を提出する」「差し戻し理由を送信する」など、操作の結果が具体的にイメージできる表現に統一しています。
スタイルや配置については、Human Interface Guidelines や Material Design、一般的なユーザビリティの知見を参考にしながら、 「ユーザーが最も選ぶ可能性が高い操作はどれか」「破壊的な操作を誤って実行しないためにはどう見せるべきか」といった観点で検討を重ねました。 プライマリーボタンとセカンダリーボタンの強弱、右左どちらに配置するか、破棄・削除系アクションの色や位置などを整理し、 誤操作を防ぎつつ、自然に優先されるべき操作に目がいく構成にしています。
また、主要なボタンにはテキストだけでなくアイコンを付与し、意味を視覚的にも補強することで、認知負荷の軽減と操作の素早い判断を助ける設計としました。
工夫した点④：ナビゲーションの設計
ナビゲーション設計にあたっては、まず本サービスのナビゲーション情報のグルーピングと優先づけを行いました。
次に、主要なサービス（Youtube, note等）のナビゲーション構造を分析し、ナビゲーションのレイアウトパターンをいくつか作成しました。 それぞれのパターンを比較し、ユーザーの認知や操作性、拡張性を考慮して最適なパターンを選定しました。
工夫した点⑤：申請詳細ページ
申請詳細ページは、ワイヤフレームにスタイルを適用した段階では、情報の一覧性の低さ、情報のグルピングや優先づけ、進捗状況の分かりやすさに課題がありました。 そこで、構造の似たサービスの構造を分析し、情報の優先づけやグルーピングを再定義した上で、現状の課題を解決したUIを作成しました。
工夫した点⑥：承認フロー
承認操作は業務上の重要度が高く、誤操作や見落としが許容されにくい領域であるため、「承認専用のモードを用意するべきか」、あるいは「詳細ページ内で承認を完結させるべきか」をまず検討しました。 UIのまとまりやすさだけでなく、ユーザーが行うべき導線（内容確認 → 承認／差し戻し）が途切れずに進められるかを判断基準としています。
検討の結果、詳細ページを起点として承認専用モードへ遷移するパターンを採用しました。 これにより、詳細情報の確認と承認操作が視覚的にも機能的にも分離され、誤操作を防ぎつつ、承認に必要な情報をしっかり確認してから操作できるフローを実現しています。
おわりに
今回の題材は「架空のサービス開発依頼」という設定であり、主に情報設計と UI デザインを中心に取り組んだため、 実プロダクト開発で重要となるユーザーリサーチやゼロベースのコンセプト策定は十分に行えていません。 実際の業務では、利用者の行動・文脈・制約から課題を抽出し、それをプロダクトの方向性に反映するプロセスが不可欠であり、この部分については今後の課題だと感じています。
また、今回扱ったフローは「申請 → 承認」という比較的シンプルな構造であったため、実プロダクトで求められるような 複雑な機能間の参照関係や、組織構造・権限設定による分岐までは十分に検討できていません。 より大規模な業務システムでは、データモデル・アクセス権・タスクの依存関係など、UI に影響する構造的な要素が増えるため、 そうしたケースに対応できる設計力をさらに高めていく必要があると考えています。
TripliteのFigmaファイルはこちら
要件定義、情報設計、ビジュアルデザインのデータを公開しています