UI初心者が「出張申請ソフトのデザイン」に挑戦してみた結果 / BONO
はじめまして！現在、UX/UIデザインを勉強している宇山です。
今回は、デザインコミュニティBONOのお題である「出張申請ソフトのデザイン」に挑戦しました。制作期間は一ヶ月半で、要件定義から情報設計、プロトタイピングまで自主制作しました。
長文になりますが、最後まで読んでいただけると嬉しいです！！
（未経験からUX/UIデザインを学びたい方、めちゃくちゃおすすめです！）
サマリー
今回、制作したデザインテーマはこちらです。
「申請」という日常業務は、表面的には単純に見えるかもしれませんが、実際には多くの時間とエネルギーを要します。
そして、申請を完了させるためには、日々の業務の中で申請内容を確認し、承認するという承認者側の作業も必要です。
そこで、申請プロセスの体験を向上させることで、申請をするユーザーのみならず、承認者を含む組織全体に多くのメリットを与えることができるのでは💡と仮説を立ててデザインをしました。
サービス概要
そこで、完成したUIデザインがこちらです。
要件定義
ここからは、出張申請ソフトを利用する想定のユーザーの課題感を特定し、デザインの方向性を決めていきました。
今回は、サービスの方向性がある程度決まっていたため、ユーザー調査を実施を行いませんでした。代わりに、４社の競合他社のサービスを利用し、自身でユーザーになりきり課題感を抽出していきました。
以下が、私自身が考えた２つの問題意識です。
１つ目：申請者側に心理的な作業負担があること
競合サービスのUIに触れて感じたことは、出張申請を提出するまでには多くの情報収集が必要だということです。具体的には、予定の調整、交通手段の手配、宿泊施設の予約、必要な書類の整備など数多くの事前準備をしなければいけません。
また、デザインを考える際に重要な点は、出張を申請することが申請者にとって「メリットがあまりない行為」であり、出張当日の重要な商談やプレゼンの準備に充てるべき時間を、他の業務に振り分けなければならない現実があることです。
以上のポイントを、仮のユーザー像に落とし込み、申請作業が完了するまでの体験マップを作成しました。
上記のマップで赤線で囲んでいる、「入力する～申請する」までのフェーズにおいて、著しく体験価値が低下しているのではないかと考えました。
背景には、日々の業務の忙しさから申請作業が億劫になってしまうことや、申請内容の多さによる先延ばしにしてしまう可能性があると考えたためです。
そこで、申請完了までの理想のフローと現状フローをマッピングし、どのような課題感があるのかビジュアルにしました。
現状のフローでは、申請の締め切り近くで、申請作業を一度で入力する傾向があるのではないかと仮説を立てました。
その背景には、申請作業をスムーズに完了させるためには、上記で記載した通り、出張時の詳細なスケジュールや、提出書類などの出張に関連するすべての情報を用意しなければいけないという認識があるためです。
そのため、「出張申請の締め切りの寸前に、たくさんの内容を記入する必要」になり、ユーザーが望まない体験に悩まされている可能性があると考えました💡
２つ目：業務効率化の障壁があること
次に、承認者を含めた全体フローからユーザー理解をしていきました。
仮に、最初の問題意識である「申請者側に大きな作業負担があること」があるのだとすると、申請の差し戻し対応による影響もマクロ面での組織でも影響があることが、下の全体フローのビジュアルから確認ができます。
再申請のプロセスが発生する場合、組織全体の業務効率化に悪影響を及ぼす可能性があります。なぜなら、申請者は再度内容を入力しなければならず、承認者も内容の再確認する必要が発生するためです。
そのため、組織全体の業務効率を向上させ、従業員が本質的な業務に専念できる環境を整備するためには、申請者だけでなく、承認者側の課題も解決する必要があります。
デザインの方向性まとめ
上記の２つの課題についてまとめ、以下の方向性を決めました。
① サラッと申請作業ができるように🖋
ユーザーが望む体験として、申請作業を手際良く行うことが最重要事項です。 そのためには、申請をする行為に対して、情緒的な価値を提供することで作業感を軽減させることが必要です。
そこで、直感的に使用できるUIの機能やコンポーネントの選定に注力することが重要だと感じました。
② 記入漏れを軽減できるような設計に🌟
申請作業を一度で完結させるのではなく、複数回に分けて入力させることで記入漏れを軽減できそうです。そこで、出張が決まった段階から申請準備ができるようにするため、適切な導線を設けました。
これにより、急いで申請するケースや入力ミスを減らすことができると考えました。
プロトタイピング
まず、UIをデザインする前に情報設計を考えました。また、デザイナーの方からフィードバックをいただき、UIの改善を繰り返しました。
情報設計１：情報の再定義について
出張申請においてどのような内容を記入するのかを理解するために、マネーフォワードさんが提供している申請書のテンプレートを参考にしてみました。
今回のケースでは、オンライン上で申請が完了する仕様にするため、UIに反映させた際の情報の再定義や、要件定義から考慮しなければならない箇所などのメモを書き出しました。
SaaSのUIにおいては、似た内容の情報は１つにまとめて、情報のリンク付けをすることが非常に重要です。なぜなら、UIの性質上、データの適切な整理をしなければ、どこに何の情報があるのか不明確になってしまう可能性があるからです。
例を挙げると、手にとれる紙媒体の書類では、紙の量が多くても前後のページから、どこに何があるのかを大まかに予測することができるでしょう。
それとは対照的に、オンライン上のデータを確認する場合、関連ページをPC画面で一つずつチェックする必要があります。したがって、オンライン上でのデータ整理をしなければ利用者にとって非常に不便になる状況を引き起こしてしまう可能性が生じてしまいます。
そこで、情報設計面で以下の点を考えてみました。
テンプレートでは、「出張のスケジュール情報」と「それに関連する金額情報」の2つの項目がありますが、これらの情報には重複が見られます。UIの設計では、情報をよりシンプルで直感的な形で表示することが可能です。そのため、重複した情報を整理しました。
以下が、今回のプロパティ一覧表です。
情報設計2: 階層構造について
次に、UIの階層構造について考えました。
要件定義に基づき、各画面の情報構成を調節することで、サービス全体の情報構成がより整理され直感的なＵＩになる可能性が上がります。今回は、主に2つのパターンを検討しました。
左側の階層構造が浅いバージョンでは、「入力画面」と「内容確認」の2つの画面で構成されています。一方、右側の階層構造が深いバージョンでは、各ブロックごとに表示するプロパティを分解して表示する設計になっています。
この2つのバージョンをラフに作成し、ユーザーが画面とのやり取りをどのように行うかを検証しました。
最終的には、右側の階層構造が深いバージョンを採用しました。採用した理由は、関連する情報をそれぞれの画面に分割して表示し、ユーザーが行うアクションが明確になるためです。この構造では、ユーザーは一つ一つの情報に集中して画面を見ることができ、情報の整理や操作がスムーズに行える利点があります。
以下が、完成したUIの全体フロー図になります。
ビジュアル: 最終案までのUIの改善
最後に、最終案までのプロトタイピングまでの改善についてです。
UIを独学で学んでいる際に抱えていた悩みは、初心者の立場からの視点ではユーザビリティテストの結果を適切にUIに反映することが難しいと感じていました。 特に、UIの知識が不足しているため、調査結果を適切に解釈し、それをデザインとして具体化することが困難でした。
そのため、BONOの運営者でデザイナーの、カイさんにフィードバックをいただき、ユーザーが使いやすいUIになるように最後まで粘りました！（BeforeとAfterでは、かなりビジュアル面が改善されていて、パターンのつくり方など大変勉強になりました。）
まず、業務系ソフトウェアにおいて、ユーザーが最も頻繁に使用するのはフォームのコンポーネントです。申請内容によっては、画面上に多くのフォームが並んで表示されることもあります。
そのため、フォームの幅を広く確保し、情報のブロックを直感的に認識できるようにしました。また、スクロールしながらフォームをサラッと記入できるようなユーザー体験を実現しました。
これにより、ユーザーはよりスムーズに情報を入力することができます。
今回のデザインでは、階層構造が深くなるため、ユーザーにとってどの情報がどの画面に存在するのかを明示する必要があります。そのため、フローの可視化をサポートするコンポーネントを導入しました。
最終案では、「タッチ可能なボタン」と「ステータス表示コンポーネント」という2つの要素を区別し、それらをヘッダーに表示しました。
この改善により、ユーザーは前の画面に戻るボタンを複数回クリックする必要なく、目的の画面に素早く移動することができます。
UIに表示されるコンテンツと同様に、アクションの導線をどこに配置するかも重要です。初期のバージョンでは、情報設計の反映が不十分であり、アクションの導線を直感的に認識することが難しい設計になっていました。
そのため、最終案では、情報設計を見直し、ユーザーが最も重要と感じる「下書き保存」アクションをどの画面でも簡単に行えるよう、ヘッダーにアクションボタンを配置しました。
また、下書き保存を忘れた場合でも、バックアップが取れるように、「閉じる」を押した場合でも下書き保存ができるように設計しました。
これにより、ユーザーはスムーズに下書きを保存し、情報の損失を防ぐことができます。
この画面の主な変更点は、以下の3つです。
①日付ごとに画面を繰り替えるのではなく、出張対象の日付を１画面で確認できるようにしました。
②経費カテゴリーのボタンから新規スケジュールを追加する方法ではなく、新規のスケジュールを追加するボタンを配置し、モーダル（下記の方法）を表示するようにしました。
③スケジュールをまだ追加していないときは、空の状態を表示し、ユーザーに負担をかけないようにしました。
改善前のデザインでは、経費カテゴリーが他の情報よりも誇張されており、ユーザーがこのモーダルを使用するために多くの学習を必要とするデザインになっていました。
改善案では、ユーザーが普段使い慣れている基本的なモーダルの構成にし、初めてサービスを利用するユーザーでも問題なく入力できるように設計しました。また、経費カテゴリーによっては「往復や片道」や「チェックインやチェックアウト」といった特有の概念が生じる可能性があるため、柔軟に対応できるようにラジオボタンを設置し、詳細な情報を入力できるようにしました。
振り返り
◇オブジェクトを捉えてUIをつくる基礎力
今回のお題を通じて、体験フローの全体像を考慮して情報設計をすることの重要性を実感しました。特に驚いたのは、頭で考えるだけでなく、考えている内容を視覚的に表現・分析することによって、より全体の画面構成を考慮してUIをつくることができるという点です。最終的なプロトタイプでは、要件定義の内容を十分に反映させることができたと考えています。
また、サービスを運営する際に必要な要件内容の達成とエンドユーザーの使いやすさを両立させるために、情報設計の概念が重要であることを学ぶことができました。
◇フィードバックで利用しやすいUIに改善
実際のデザイナーの方からフィードバックを受けて、使いやすいUIに改善することができました。カイさんには計3回のプロトタイプの添削を依頼しました。実際のデザイナーの方からの知見を取り入れることで、自分では見落としていたUIのお作法や、ユーザビリティを向上させるためのアイデアを最終案に反映させることができたのではないかと思います。
(本当に初期のバージョンと比較して、最終案のUIのクオリティに感動しています！！！)
◇SaaSの考察を深める
SaaSのUIは、他のサービスのUIと比較して、顧客のニーズに合わせてカスタマイズできる特徴があります。今回のケースだと、出張申請書を作成することはできるが、今後新たな機能を追加する場合、既存のコンポーネントでは対応できない可能性があります。
そこで、次回以降は、UIの拡張性を重点的にし、既存のUIの機能面の意図を十分に理解することで、より価値の高いプロダクトになるのではないかと考えました。
◇行動や感情を理解する
今回のテーマでは、ある程度のUIの仕様が提示されていたため、定量調査や定性調査は行いませんでした。しかし、実際のユーザーからのフィードバックを反映させることがプロダクトの品質に大きく影響すると考えています。
次回の制作では、より多くの人に利用してもらえるプロダクトを作るために、調査を実施し、その結果をUIに反映させていきたいです。
◇同じテーマを挑戦する
私自身は、日常的に業務関連のSaaSプロダクトに触れる機会が少ないため、デザインの前に参考資料を集めたり、実際にトライアル体験を行って他のデザインの理解度を深めました。しかし、今回の反省点である「UIの拡張性」を考えると、まだ改善の余地があると感じています。
そこで、使いやすさや広く認知されているConcurやSalesforce、Asana、ShopifyなどのSaaSプロダクトを分析し、同じテーマに再挑戦することで、より良いプロダクトにできると考えています。
また時間を設けて、よりユーザーファーストなUIになるように改善をしていきたいです！！！
追記(2023/8/29)
現在、数名の方にユーザー調査を実施しており、サービスデザインの視点からUIの改善ができそうです！近いうちにアウトプットを共有できるように、これからも頑張りたいと思います。
それでは、また次の投稿でお会いしましょう！ありがとうございました🙌