紙ベースの出張申請をオンライン化する社内向けSaaS「SUSUMU」を設計しました。
※コロナ禍(2020〜2023年)を想定した設計です。
担当範囲
情報設計・UIデザイン
制作期間
2026年4月〜2026年6月
使用ソフト・技術
Figma
プロトタイプ
背景
ユーザー
佐藤健太郎 30代・営業職
月に複数回の出張があり、移動中や訪問先のすきま時間に申請を済ませたい。
入力項目が多く何をどこまで入力すればいいか把握しにくい現状に不満を感じている。
承認待ちのステータスが見えないため、差し戻しに気づくのが遅れることも。
制作の流れ
各工程を行ったり来たりしながらデザインを作成しました。
サービス調査
勤務先でこういった申請をする機会が少なかったため、出張申請がどういうものかを知るところからスタートしました。
仕様の整理
以下の3つを使ってサービスの構造を整理しました。
UIリサーチ・ラフ作成
業務系UIは実際に触れるものが限られていたため、B to C向けのECサイトやファイル管理サービスの管理画面を参考に調査しました。
全体の構成は手書きでラフを起こし、画面のイメージを掴む段階ではFigma Makeも活用しました。
デザイン
配色は青系統を採用しました。理由は2つあります。
出張申請は大量処理する業務ではないため、情報を詰め込むより余白を広く取る方が適していると判断し、Linearというサービスを主に参考にしました。余白を意識することで画面が整理され、見やすさが向上することを実感しました。
FB修正:行動計画について
「行動計画」という項目を設けていましたが、そもそも経費申請のサービスに行動計画は必要なのかと指摘を受けました。
また何を入力すればいいかユーザーに伝わらないという問題もあったため、最終的に「出張目的」だけに行動の内容を入れるようにしました。
モーダルを開いても「行動計画」という見出しがあるだけで、何を入力すればいいかの説明がありませんでした。
入力欄だけが並んでいる状態では、ユーザーは何を書けばいいかわからないまま入力を求められることになり、それだけで負担になってしまいます。
また経費申請がメインのサービスとして行動計画自体を記入させる目的自体も曖昧でした。
行動計画を削除した代わりに、出張目的の入力欄1つにまとめました。
出張の内容は目的を一言書けばおよそ伝わるため、細かい行動を別途入力させる必要はないと判断しました。
振り返り
情報設計について
情報設計で特に難しかったのは何を表示して何を省くかの判断と、項目の順番や構造の整理でした。
機能を追加することよりも、本当に必要なものだけに絞る判断の方が難しいと感じました。
行動計画の削除もその一つで、あった方がいいかもしれないという迷いを持ちながらも、サービスの目的に立ち返って判断しました。
今後は設計の早い段階で「この項目は誰のために・何のためにあるか」を一つずつ確認しながら進めることを意識したいと思います。
出張申請全般について
出張申請システムを使った経験がほぼなく、イメージを掴むのに時間がかかりました。
他の受講生の作品を参考にしていましたが、本当に使いやすいかを自分で考える視点が不足していたと感じています。
また架空のユーザーではなく実在の人物をユーザーにすることで、設計の判断がより明確になると感じました。