【2024年6月版】ベイジの業務システムUIデザインワークフロー（100のタスクを徹底解説）

ベイジは2010年の創業以来、ウェブ制作事業を中心に事業を展開してきました。この事業では、サービスの質を統一するために2014年頃からワークフローの整備に取り組んできました。

一方ウェブアプリデザイン事業については、事業拡大したのがここ数年で、まだワークフローが整備されておらず、各人の裁量に委ねた進め方になっていました。そこで今後の事業拡大とメンバー増員を想定し作成したのが、業務システムやSaaSのUIデザインに特化した「ベイジの業務システムUIデザインワークフロー」です。

基本的な進め方は国際規格（ISO 9241-210※）の人間中心設計プロセスに基づいて組み立てていますが、細かいタスクの順序や内容は、今までベイジで培ってきたノウハウをふんだんに盛り込み、組み換えています。

そして、様々なプロジェクトでこのワークフローを実用しながら、今もアップデートを続けています。

また今回のワークフロー整備では、クライアントごとの多様な開発プロセス(ウォーターフォール、アジャイル、デザイン思考など)に順応できることを重視しました。システム開発のプロセスを前提とするウェブアプリデザインでは、この多様性を無視できません。

このワークフローには私たちの組織特性が色濃く反映されていますが一方で、普遍的・汎用的なUIデザインのノウハウも多く含まれています。このワークフローは同じ業界で働く人たちの役に立つのではと思い、一般公開することにしました。ぜひご覧ください。

※ ISO 9241-210:2019 Ergonomics of human-system interaction Part 210: Human-centred design for interactive systems：https://www.iso.org/standard/77520.html

1. プロジェクト設計

契約締結後、最初に行うのがプロジェクト設計です。チーム編成からプロジェクトのルールを定義して社内外に共有し、スムーズなプロジェクト進行の土台を作ります。

1-1. プロジェクトチーム編成

プロジェクトチームの編成時には、メンバーの空き状況、適性、希望などを総合的に考慮します。ベイジは要求理解から納品まで一貫したプロジェクト体制をとるため、社内にはそれを実行できる全職能が揃っています。そのため、プロジェクト開始時にほぼ全工程の担当者を決定します。

主な編成は以下の通りです。

• コンサルタント：対象システムとユーザー体験についてリサーチを行い、改善方針の立案とシステム設計を担当。具体的にはユーザーインタビュー、アンケート、現行システム分析などを行います。
• ディレクター：進行管理、コンサルタント業務のサポートおよびクライアントとのコミュニケーションを主に行います
• UIデザイナー：リサーチの結果を基に画面の情報設計、スタイル設計、および実装の品質チェックを行います。
• ライター：UIデザイナーが作成した情報設計に基づき、UXライティングの品質向上を目的にラベルや説明文のレビューを行います。
• フロントエンドエンジニア：UIデザイナーの設計を元に実装を担当。Angular、React、Vueなどのフロントエンドフレームワークを使用して開発を進めます。

メンバーの適性は、案件の難易度とスキルセットから総合的に判断されています。

1-2. WBS作成

プロジェクト全体の現実的なスケジュールを把握するため、Microsoft Projectというプロジェクト管理ツールで【WBS（Work Breakdown Structure/作業構造体系）】を作成します。WBSとは、プロジェクト全体の作業を階層的に細分化し、詳細に管理するための構造体系のことです。通常は契約前の段階で素案が作られているため、その素案を調整・仕上げることが多くなります。新規作成が必要な場合も、すべてのワークフローが網羅されたWBSテンプレートが社内で配布されているので、30分~1時間程度で作成できます。WBSの作成はディレクターが担当しています。

新規に作成することは少なく、契約前段階で作られた素案を調整して仕上げることが多いです。新規作成する場合も、すべてのワークフローを網羅したテンプレートが社内Wikiで配布されているため、30分～1時間程度でWBSを作成できます。ベイジではコンサルタントが担当します。

詳細なWBSを事前に作成することで、クライアントに対して進行方法を具体的にイメージしてもらえます。プロジェクト開始後の認識の違いを防ぐことができます。ディレクターはWBS作成時に、各作業の詳細やスケジュールを確認しながら必要な調整を行い、プロジェクトの円滑な進行とクライアントとのコミュニケーションの円滑化を図ります。

1-3. プロジェクト開始連絡

プロジェクトチームが決まった段階で、新プロジェクトの開始が社内にアナウンスされます。プロジェクト内共通で使用されるプロジェクトコード、クライアント名、アプリケーションの概要、予算、納期、スコープ、開発サーバ、セキュリティ関連の設定、プロジェクトメンバー、プロジェクト固有の前提条件など、プロジェクトに関する様々な基本情報を全社員に共有します。ベイジではディレクターが担当します。

1-4. プロジェクト環境の準備

WBSが決まったら管理ツールを準備します。ベイジでは、以下のツールを使い分けています。

• プロジェクト管理シート（スプレッドシート）：全体の進捗状況の把握
• Backlog（プロジェクト管理ツール）：細かなタスクの管理
• Slack（チャット）：お客さまとのコミュニケーション
• Googleドライブ：ファイルの管理、受け渡し

プロジェクト管理シートとは、プロジェクトの進捗状況をタスク毎に細分化したシートです。WBSに似ていますが、WBSがクライアント提示用であるのに対し、プロジェクト管理シートは社内管理用で、進捗状況の更新に特化しています。このシートには進捗状況を常に更新し、プロジェクトの現状を一目で把握できるようになっています。

一方のバックログは、個々のタスクの詳細な状況を管理するためのツールです。メンバー個人の作業内容や期限を細かく記録し、スムーズな作業フローを実現しています。

Slackはプロジェクトメンバー間での日々の細かな連絡に使われています。簡単な相談から重要な通知まで、チャットで素早くやり取りできます。

ファイル共有に関しては、近年はクライアント指定のクラウド環境を利用することも多いです。クライアントからの指定が特になければ、ベイジで契約しているGoogle Workspaceを利用します。

さらに、クライアントとの間で利用する管理ツールの調整もここで行います。基本的にはクライアントの要望に合わせますが、問題なければSlackとbacklogに招待しています。

1-5. 開発環境の準備

プロジェクトが開始されると、まず担当エンジニアが開発に必要な環境の設定を行います。サブドメインの申請や使用する技術の選定を行い、実装後のモックアップ画面を確認するための開発環境を用意します。この開発環境はクライアントにもアクセスしてもらえるようにします。

1-6. プロジェクト定義書の作成

社内におけるプロジェクト準備が一通り完了したら【プロジェクト定義書】を作成します。プロジェクト定義書とは、プロジェクトの目的、スコープ、成果物、メンバー、セキュリティ関連情報、コミュニケーションルール、リスクや補足事項などをまとめたドキュメントです。プロジェクト定義書もフォーマットが用意されており、30分ほどで作成可能です。ディレクターが担当します。

1-7. キックオフミーティング

契約締結後にクライアントと行う最初のミーティングです。プロジェクト定義書とWBSを中心に、プロジェクトの前提条件・スケジュールなどの説明を行います。説明自体は質疑応答も含めて、15分程度で終了します。当たり前のことを改めて確認することも多いですが、このような事前の認識合わせやリスク共有の有無で、クライアントの心理的ハードルが変わり、その後のプロジェクトの進めやすさに大きな違いが生じるため、私たちはこの工程を重要視しています。プロジェクト定義書の説明が終わった後は、そのまま要求理解フェーズのヒアリングを実施します。

最近はベイジでもキックオフミーティングをオフラインで実施することが増えてきています。リアルで顔を合わせる場を設けておくと、その後のオンラインでのコミュニケーションがやりやすくなるなど、一定の効果を感じています。

プロジェクト設計についてはこちらも併せてご覧ください
成功を導く「プロジェクト計画」の実践ガイド

2. 要求理解

業務システムに関わるユーザーの要求を理解するフェーズです。多くの業務システムが抱える「使い勝手をよくしたいが、どうすればいいか分からない」という問題に対して、具体的に何を改善すれば使いやすくなるのか、そのためにはどのようなリサーチをすべきかを計画し実行します。

簡易的に現在の業務システムの問題を洗い出したい場合は、ユーザビリティの専門家評価に基づいた改善を行います。一方、抜本的な見直しを行いたい場合は、利用者の観察やインタビューをじっくり行い、操作フローを定義した上で、対象システムに閉じることなく幅広く改善アイデアを提案します。

このフェーズは、ほぼすべてをコンサルタントがメインで担当します。被験者を必要とするリサーチでは、クライアントの担当者にも積極的な参加を促します。さらにUIデザイナーも参加し、リサーチ結果を設計へスムーズに反映します。

2-1. ヒアリング

2-1-1. 概要ヒアリング

まずは関係者へのヒアリングからスタートします。リサーチ前にヒアリングを行うことで、お客さまがお持ちの既知の情報を効率的に情報共有していただきます。プロジェクト開始後に判明するとコストに影響が出るような前提条件もこのタイミングで可能な限り漏れなく洗い出し、不明点は課題として継続的に管理します。すべてのヒアリングの設問は、Excel/Googleスプレッドシートで作られた【ヒアリングシート】にまとめてキックオフミーティングの約2週間前にクライアントに提出し、回答してもらいます。

ヒアリングシートのテンプレートには、ビジネス特性、システムの目的、主な利用フロー、利用環境を中心に設問があります。さらにSaaSの場合は、市場特性、顧客特性、マーケティング施策、ブランディング、競合などの設問もあり、クライアントの個別事情を反映してカスタマイズして用います。

業務システムのUIデザインを適切に行うには、ビジネスの特性を理解することが不可欠です。クライアントには不思議に思われるかもしれませんが、ビジネス特性を把握することで、画面デザインの方向性、ユーザー要件、必要機能、使いやすさ、業務フローの最適化、セキュリティ要件など、様々な観点から適したUIを実現できます。

2-1-2. 詳細ヒアリング

ヒアリングシートの回答内容に従い、キックオフミーティングで追加ヒアリングやディスカッションを行います。1回のヒアリングで次工程に進むこともありますが、大規模システムの場合、利用者の属性が多く、業務フローも複雑なため、複数回のヒアリングを実施することもあります。またこの詳細ヒアリングを元に、後続タスクの手順を調整します。

2-1-3. システム要件ヒアリング

システム上の要件として以下の内容をヒアリングします。

• 全利用デバイス（SP/PC/タブレット/大型モニター）とメインデバイス
• 利用デバイスの最小解像度
• サポート対象のブラウザ

2-1-4. 開発体制ヒアリング

開発を進める上での基本的な体制やルールについてヒアリングします。

• 使用を想定しているフレームワークやライブラリ
• フロントエンドを除く開発体制とスケジュール
• 準拠すべきコーディング規約やガイドライン
• 成果物の管理方法及び利用ツール
• 開発環境における課題
• 想定しているフロントエンドの実装範囲

2-1-5. アクセシビリティ要件ヒアリング

利用者のターゲットに則り、WCAGを参考として対象システムが満たすべきアクセシビリティの達成基準を定義します。この要件の中にはカラーユニバーサルデザインにおける達成基準も含みます。

※ WCAG（Web Content Accessibility Guidelines）：ウェブアクセシビリティに関する世界基準のガイドラインで、様々な障害のある人に対して、コンテンツをアクセシブルにすることを目的としている。最新は2023年勧告の2.2

※ カラーユニバーサルデザイン：色覚多様性（遺伝子タイプや目の疾患により色の見え方が異なる様）に配慮して、全ての人に情報が正確に伝わるようにしたデザイン

2-2. 現行システムの確認

2-2-1. アプリケーション操作確認（テスト環境の提供）

テスト環境またはテストアカウントを提供していただき、実際に現行アプリケーションを操作することで、仕様や操作に関する理解を深めます。マニュアルや仕様書でも内容を理解することは可能ですが、各ドキュメントが最新であることは少なく、実際に操作して現状の仕組みを自分たちで資料化することも多いです。

2-2-2. マニュアル確認

現行アプリケーションの利用マニュアルを確認し、ユーザーにさせたいことの意図を理解します。実際にアプリケーションを触ったあとにマニュアルを確認するため、サービス提供側とユーザー側の考えの乖離も把握することができます。

2-2-3. システム仕様書確認

現行システムの仕様書を確認し、画面には現れないロジックやデータ構造、システムの制約を理解します。これにより、UIデザインによる改善アイデアの難易度・コストを評価しやすくなります。

2-2-4. ログ解析

現在のアプリケーションのアクセス解析から、利用しているOSやデバイス、ブラウザなどを把握し、リニューアルでカバーすべきシステム範囲を確認します。またアクセスの多い機能などを把握し、リサーチの対象の判断にも活用します。

現在のアプリケーションのアクセス解析を通じて、利用されているOSやデバイス、ブラウザを把握します。これにより、リニューアルでカバーすべきシステム範囲を確認します。また、アクセス解析を行うことで、利用者が頻繁に使う機能がわかります。この機能に関する利用者ニーズを重点的に調査対象とするなど、リサーチ対象の選定に活用できます。

2-3. リサーチ対象の機能・画面選定

リサーチ対象の主要な機能と、それに関わる画面を選定します。大規模システムの場合、数百の画面が存在することが多いため、すべての機能と画面を網羅してリサーチすることは難しいです。しかし、その中の10～30画面程度の主要機能を中心にリサーチを行えば、全体の問題傾向と改善方針が見えてきます。このリサーチ対象をクライアントと合意して次タスクに進みます。

2-4. ゴール設定

ライトな仮説検証を繰り返すデザインスプリントやアジャイル開発のプロジェクトの場合、ヒアリングでリサーチや機能の範囲が見えてきた時点で、具体的な課題とプロジェクトの目標を設定します。これは、プロジェクトの進行中に焦点を合わせるべき具体的な問題と、その解決に向けた明確な目標を持つためです。

キックオフミーティングでも、プロジェクトの方向性となる抽象的なゴールは共有されますが、ここで設定する課題と目標はより具体的なものです。

2-5. スプリントプロトタイピング

デザインスプリントやアジャイル開発のプロジェクトの場合、前段のタスクで設定したゴールを達成するために、必要な機能アイデアをこの時点で上げ、アイデアを具体化したラフ画のプロトタイプを作成します。ラフ画はプロトタイプツールで作成した簡素な画面、または紙に手書きしたペーパープロトタイプでも構いません。

後続のユーザーリサーチは、一般的に現行アプリケーションに対して行われます。しかし、ラフアイデアのスプリントプロトタイプを利用する場合、ユーザーリサーチで事前にアイデアの有効性を検証できます。

2-6. ユーザーリサーチ

2-6-1. エキスパートレビュー

私たちユーザビリティの専門家が、現行アプリケーションの使い勝手を評価します。実際のユーザーではなく、一般的な評価軸（ヤコブ・ニールセンのユーザビリティの10のヒューリスティックス※）と専門家の経験則から評価を行うため、思いがけない問題点が出てくることは少ないですが、広く網羅的に問題点を洗い出すことができます。

簡易的に行う場合、問題点と改善案のリストアップのみ行いますが、クライアントの要望により報告書を作成することもあります。

実際のユーザーに対してリサーチするプロジェクトでも、問題点の仮説設定のために、エキスパートレビューは必ず行います。

※ 10 Usability Heuristics for User Interface Design：
　  https://www.nngroup.com/articles/ten-usability-heuristics/

2-6-2. エスノグラフィ

現行アプリケーションを利用する現場を訪問し、利用環境を観察します。主に以下のような発見を目的に観察します。

• 操作マニュアルと現場の実態との乖離
• ユーザーの無意識に行う予期しない操作手順
• アプリケーション以外に使うもの（メモ、封筒、電卓、他ツールの参照など）
• 関係者（作業協力者、レビュー者、電話相手など）
• ユーザーの慣れによって見過ごしている問題点

事前に合意したリサーチ対象の機能・画面が含まれるよう、観察対象のユーザー、場所、操作手順などを定義した計画を立てます。計画と日程をクライアントと調整して、最終的な計画書が完成します。

観察後には、簡単にユーザーにインタビューできる時間を確保しておきます。インタビューでは、観察で得られた気づきや、行動の根拠を聞き出します。観察が終了したら、観察者の記録をまとめ、特徴的な行動を中心に整理します。

2-6-3. As-Is業務フロー整理（仮説）

ここまでのリサーチで分かった内容をもとに、現行アプリケーションでの操作フローを定義します。この操作フローは、UXデザインで活用するカスタマージャーニーマップをアレンジしたベイジ独自のテンプレートです。このテンプレートには、各操作フローでのタスクのキッカケ、ユーザー心理、手順、欲しい情報、情報の入手先、アプリケーションの役割、問題点を網羅的に書けるようになっており、その後のリサーチでさらに深堀りすべきポイントが明らかになります。

2-6-4. アンケート

ユーザー数や属性が多く、リサーチの深堀りポイントを絞れない場合は、事前にアンケートを行い、統計データを収集します。ユーザー数や属性が限られる場合はアンケートを行う必要はありません。実施には以下のサブタスクが発生します。

〇アンケート対象者の選定
ユーザーの属性を細かく定義し、どの属性のユーザー何名に対してアンケートを行うかを決めます。アンケートの実施人数は多いため、近しい属性のユーザーに対してまとめてこの後のリサーチを行います。

〇設問の設計
アンケート回答率を上げるため、無理に仮説検証のための細かい設問は入れません。回答しやすい設問内容、設問数を設定します。また、その後のユーザーインタビューの対象者をアンケート回答から選別することが多いため、選別の根拠となる設問も入れています。

〇アンケート実施・集計
アンケートを実施し、集まった情報を集計し、不明点が解消したり、新たな傾向がみえたものは、業務フローのなかに反映します。アンケート回答者の中でアプリケーションの利用頻度が高い人、上手く使いこなしている人は、その後のユーザーインタビューの対象候補者にします。

2-6-5. ユーザーインタビュー

ユーザーインタビューでは、既知の行動、発言、課題感などの顕在ニーズの裏にある、本質的な潜在ニーズを引き出します。少人数に対して1対1のデプスインタビューを60分～90分ほどかけて行います。実施には以下のサブタスクが発生します。

〇インタビュー対象者のリクルーティング
ユーザーインタビューの対象者は、現行アプリケーションの利用頻度が高いベテラン、利用を開始して間もないビギナーなどターゲットを定めて選定します。ベイジが多く担当する業務アプリケーションやSaaSに関するリクルーティングは、クライアントにしていただくことがほとんどです。

〇インタビュー設計
ベイジではインタビュー設問テンプレートを準備しているため、それをもとにプロジェクト固有の設問に書き換えて作成しています。設問は事前にクライアントに確認いただき、追加で質問したい内容についてコメントをもらいます。

〇インタビュー実施
インタビューはインタビュー担当とメモ担当の2名以上で行います。メモはユーザーが口にした事実をそのまま書き留めます。最近ではzoomなどのツールを使ってリモートインタビューを行うことも多くなりました。録画が容易でありユーザーの反応もうかがいやすく積極的に活用しています。

インタビューでは現行アプリケーションの操作方法に関する質問をユーザーから受けることが多いため、必ずクライアントの担当者も同席させます。

〇インタビュー結果の分析
インタビューで拾ったユーザーの声は、業務フローにもれなく反映します。また内容に応じて分類し、問題の深刻度、ニーズの大きさなどで解決すべきものの優先度を決めます

2-6-6. ユーザビリティテスト

被験者3～5名を対象に、事前に設計したシナリオに合わせてアプリケーションを実際に使ってもらい、フィードバックを得ます。現在はzoomを使ったリモートユーザーテストがほとんどです。実施には以下のサブタスクが発生します。

〇ユーザビリティテスト設計
テストの目的、対象機能、ユーザーの行動シナリオ、前提条件やゴールを設定します。この内容はクライアントと事前に合意します。リハーサルを行い、設計した手順でスムーズにテストができるかを確認し、内容をブラッシュアップします。

〇ユーザビリティテスト実施
ユーザーテストはファシリテーション担当とメモ担当の2名以上で行います。メモはユーザーが口にした事実をそのまま書き留めます。zoomなどを使う場合、ユーザーの操作画面を共有してもらい、マウスの動きなども観察します。

クライアントの担当者も同席し、ユーザーからの質問に対応します。

2-7. 競合分析

SaaSのリサーチでは、競合サービスを複数選定し、市場におけるリニューアルに向けての方向性をクランアントと合意します。競合サービスが存在しない場合や、競合を意識せず事業展開している場合、分析してもあまり意味がない場合には、最小限度の分析に留めるか割愛します。

2-7-1. 競合サービス選定

サービスのカオスマップや、クライアントからのヒアリングをもとに、競合分析を行うサービスの対象を選定します。

2-7-2. 競合ビジネス分析

導入企業の規模や業種、ユーザー属性により、マッピングやマトリクスでサービスの立ち位置を可視化します。入手できる情報が少ない場合には、営業担当者などのヒアリングを中心に進め、明らかにしていきます。

2-7-3. 競合機能分析

各サービスの機能を比較します。競合固有の機能を対象サービスに取り込むべきか検討し、競合優位の機能に対して対象サービスの機能をどのように強化するべきかを判断します。

2-7-4. 競合ユーザビリティ分析

メインの機能に対して各サービスのユーザビリティを比較し、対象サービスが必要とするユーザビリティの水準を定めます。これは、競合サービスに対してもエキスパートレビューを行うことで比較します。

3. 要件定義

要求理解の中で行ってきたリサーチの結果を踏まえ、アプリケーションの現実的な利用者の属性、業務フローと抱える課題、対応案をより細かく定義していきます。

3-1. ペルソナ作成

〇関係マップの作成
大規模システムでは、様々な関係者が関わっています。利用者だけでなく、利用者の周りにいる人々との関係性を可視化するため、「関係マップ」を作成します。

例えば銀行の窓口システムには、窓口担当者だけでなく、事務担当、レビュー担当、営業担当などの関係者がいます。彼らとの関係を意識した運用が重要になります

〇ペルソナの対象を選定
どういう属性のユーザーをペルソナとして定義するかを決めます。利用デバイス、利用環境、リテラシー、アプリケーションの経験値、問題が大きい機能の利用者かどうかなどの属性を細分化して決めます。ペルソナは多すぎると運用が難しくなるので、基本は1種類、多くても2種類(メインとサブ)に絞ります。

〇ペルソナ作成
ベイジでは、業務システムにおける業務フロー改善に特化したペルソナのテンプレートを準備しています。利用者の価値観、操作ルーティンの特徴、ITリテラシー、抱える課題など大まかな項目は決まっており、その中身はプロジェクト固有に定義しています。ペルソナを活用することで、誰のために何を改善するのかが明確になり、効果的な改善につながります。

3-2. ジャーニーマップ作成

ジャーニーマップについても、ベイジでは業務システムに特化したテンプレートを準備しています。「As-Is業務フロー整理（仮説）」で記載した内容に対して、リサーチを通して判明した内容で上書きしたものです。

3-3. ユーザーストーリー

ジャーニーマップには業務フローを抜け漏れなく網羅的に記載するため、情報量が膨大になります。そこで、端的にユーザー行動の流れを掴むために、別途ユーザーストーリーを作成します。

ユーザーストーリーでは「誰が」「何を目的に」「何をしたい」をシーンごとに定義します。プロジェクトが進むにつれ、目的から外れた機能が設計されることがありますが、ユーザーストーリーを作ることでプロジェクトメンバーが目的に立ち返りやすくなります。

3-4. 改善方針立案

リサーチやユーザー定義を通してアプリケーションの現在の利用実態（As-Is）を把握できるようになったので、それに対してリニューアルの方針立て（To-Be）を定めます。

3-4-1. アイディエーション

関係者が一堂に会して、アイデアや問題解決方法を議論します。基本の方法は、ペルソナとジャーニーマップを通して課題となったポイントに対して、改善アイデアをジャーニーマップの時系列順に出していきます。参加人数は5名～40名まで様々ですが、人数が多い場合、4～5人で1つのチームを構成し、チームごとに議論した後、チーム間でアイデアを共有しフィードバックを行うラウンドロビン方式を採用します。一度のワークショップで議論が収束しない場合、複数回にわたって実施することもあります。

ワークショップの目的は大きく2つあります。1つは有益な問題解決法を導き出すことです。グループで2時間のブレインストーミングをすると、1人では不可能な量のアイデアが出てきます。これこそワークショップ最大の効果といえるでしょう。

もう1つは、関係者間の目線合わせです。改善方針がどのような経緯で導き出されたのか関係者が把握できていると、プロジェクトが進行した時に異なる視点からのフィードバックが混乱を招くリスクを減らせます。

ワークショップの実施には、以下のサブタスクが発生します。

• 参加者の選定、会場の手配
• 進行資料の作成
• ワークショップの実施
• アイデアの取りまとめ

Miroなどのオンラインホワイトボードを活用してワークショップを行うことで、より多くの関係者に参加していただけるようにしています。

3-4-2. 基本画面フロー構成検討

アイデアの中にはアプリケーションの機能配置についての議論も含まれるため、方針立ての時点で、対象アプリケーションはタスクベースUIが適切か、オブジェクトベースUIが適切かの方向性を決めます。

※ タスクベースUI：利用者の作業手順(タスク)に沿ってメニューが構成されます。 例:「メニューを追加」「メニューを削除」「料金を変更」など

※ オブジェクトベースUI：利用者が管理する対象物(オブジェクト)ごとにメニューが分かれます。 例:「メニュー管理」「顧客管理」「料金設定」など

機能ごとに画面遷移のルールが変わらないように、タスクベースUI・オブジェクトベースUIそれぞれの適切な画面遷移についてクライアントと合意します。ただし、特定の機能に特化した例外的な画面遷移を禁止するものではありません。

3-4-3. 改善提案

リサーチの結果、アイディエーションの結果から改善の方針をまとめた【改善提案書】を作成します。ここで定義する方針とは、アイディエーションを通して挙がったアイデアを機能毎にグルーピングし、共通化できる単位で落とし込んだものです。アイデアは優先度、難易度、影響範囲などを整理し、以降の設計フェーズの計画にも活用します。

改善提案書の合意をもって、要件定義フェーズは終了となります。なお、以降の設計からはUIデザイナーの職務範囲となりますが、引き続きコンサルタントが支援し、要件定義で定めた改善方針がUIデザインに反映されているかを細かく確認していきます。

3-5. 設計準備

3-5-1. WBSの更新

設計以降の作業範囲が見えた段階でWBSを更新します。プロジェクト開始時に作成したWBSを元に、最新のアプリケーション改善方針に合わせてタスクを細分化して、現実的な作業スケジュールに調整していきます。クライアントの確認期間が必要十分になっているかも確認・合意しておくことでスケジュールの再調整リスクを防ぎます。ディレクターが担当します。

3-5-2. コスト算出

要件定義フェーズで理想像を描いた結果、コストが当初の契約時点と乖離することがあります。そこで、要件定義フェーズ終了時点の仕様に基づき見積書を改めて作成し、予算を超える部分については、追加予算を確保いただくか、元々の予算に収まるように仕様を削るか、次の別プロジェクトを計画するかなどをクライアントと検討します。ディレクターが担当します。

3-5-3. クライアントフィードバック

ベイジの進め方に対する要望や率直な意見を把握するために、要件定義フェーズ終了時点でクライアントからフィードバックを受ける機会を設けています。満足度の5段階評価やベイジへの要望、不安に感じていることがないかなどを確認し、【フィードバックシート】に記載してプロジェクトに共有します。

このクライアントフィードバックは以下のタイミングでも実施し、プロジェクトに対するクライアントの不満や要望を常時キャッチアップできるようにしています。

• 改善提案ミーティング
• 開発前ミーティング
• 納品後ミーティング

4. 設計

アプリケーションの骨組みを決めるのが設計フェーズの主な目的です。設計という言葉は幅広い業務を指しますが、ベイジでは情報設計や画面設計、画面の仕様設計を対象とします。主にUIデザイナーが担当します。

4-1. 社内ブリーフィング

これまでの要件定義フェーズは、主にコンサルタントが担当し、プロジェクトの全体像を把握してきました。設計フェーズに移行する際、UIデザイナーやエンジニアとプロジェクト情報を共有するため、社内ブリーフィングを実施します。

プロジェクト概要、システム概要、リサーチから導き出された改善方針。これらを関係者全員で確認し、プロジェクトに対する共通認識を持ちます。

4-2. 設計情報の管理方法検討

クライアントの要件と環境に合わせて、設計情報の作成とレビュー方法を決めます。設計情報とレビューにはFigmaを使用します。プロジェクトの進捗と課題管理は、基本的にbacklogを活用しますが、クライアント環境でbacklogが使いにくい場合は、ExcelやGoogleスプレッドシートなど、柔軟に代替手段を検討します。

4-3. 画面フロー設計

基本画面フロー構成検討で合意したルールに則り、メニュー全体の画面遷移とグローバルナビゲーションのメニュー構成を検討します。ここでの成果物は【画面遷移図】です。

このタスクで画面のラインナップが出揃うため、併せてExcelまたはGoogleスプレッドシートで画面一覧を作成し、各画面のURL、タイトルなどを定義します。この画面一覧は画面の管理に使用します。

4-4. 主要画面設計

4-4-1. ワイヤーフレーム作成

主要機能に関わる画面について、表示情報やコンポーネントの配置を定義します。この作業の成果物【ワイヤーフレーム】です。検索画面、一覧画面、情報照会画面、編集画面、モーダル画面など、一般的な業務システムで重要な画面が網羅されるようにします。

ベイジではプロトタイピングツールのFigmaを使いワイヤーフレームを作成します。自社で制作しているテンプレートを活用することで短時間で高品質なワイヤーフレームが作れます。

また、設計意図や動線を図示し、ユーザー視点での議論を可能にします。例えば、ユーザーがどのような流れで画面を操作するのかを示す動線図を作成することで、ユーザー体験を改善するための具体的な議論が可能になります。

他社ではディレクターがワイヤーフレーム作成を担当することが多いですが、ベイジではUIデザイナーが専門知識を活かし、ユーザビリティの高い画面設計を行います。

4-4-2. 設計会議

ワイヤーフレームが完成したら、それを基にして顧客と設計会議を行います。この会議では、ワイヤーフレームをたたき台として顧客と議論を重ねながら必要な調整を行います。これにより、顧客の要望やフィードバックを反映させた、最適な画面設計を実現します。

4-5. 主要画面の仕様設計

画面の見た目だけでは把握できない、ボタンを押したときの動作や表示の切替え処理などフロントエンド実装およびサーバーサイド実装に関わる仕様を補記します。仕様の箇所がわかりやすいようワイヤーフレームのFigmaに直接書き込むことが多いです。

4-6. 表記ルールの設定

「お客様」と「お客さま」、「サーバー」と「サーバ」など、企業によっては表記ルールが定められていることがあります。そこで、ベイジ側で【表記統一ガイドライン】を作り、アプリケーション内、プロジェクト内での表記ルールをあらかじめ定義しておきます。これもテンプレートがあり、案件固有の条件だけを更新していきます。クライアントからの指定がない場合には、ベイジ標準の表記ルールに従ってUXライティングを進めます。ルールの設定はライターが担当します。

4-7. UXライティング

制作したワイヤーフレームに対して、専任のライターが文章表現を確認します。ユーザーの立場に立ち、操作手順が理解しやすいかや、ユーザーのモチベーションが維持できるかなどの観点から、ラベルや説明文の分かりやすさをチェックします。 また、言葉遣いの一貫性、トーン、ブランドメッセージとの適合性についても確認し、ユーザー体験を最適化します。

4-8. 展開画面設計

主要画面を除く全画面のワイヤーフレームを作成します。主要画面のワイヤーフレーム作成後で、基本の型は決まっているため、アプリケーション全体の操作の一貫性を意識して作成します。展開画面のワイヤーフレームに対しても、主要画面と同じように仕様を補記します。開発の全体コストを知る上で必要な情報です。

4-9. WBSの更新

アプリケーションはワイヤーフレームと仕様が確定してから開発ボリュームが把握できるため、当初想定したコストに収まっているかをエンジニアが確認します。

開発ボリュームがスケジュールに収まらない場合、スケジュールを伸ばすか、ロジック流用が可能な箇所を一部クライアントの開発チームに実装依頼するなどの調整を行います。その上で、現実的な作業スケジュールに調整していきます。ディレクターが担当します。

5. プロトタイピング

5-1. スタイリング

5-1-1. スタイルの方向性検討

スタイルの方向性について、担当UIデザイナー以外に、コンサルタント、クライアントも交えて、ワークショップ形式で議論します。スタイルを決める上で、どのようなイメージを大切にするか、どのような印象でアプリケーションを使ってもらいたいかなど、スタイリング決定までの論理的な流れをクライアントに伝えながら議論します。

このようなワークショップにより、クライアントとのイメージの乖離を最小限に留め、担当者や意思決定者の好みによって制作直しが繰り返されることを防ぎます。ここで合意したイメージが担当UIデザイナーに委ねられ、スタイリングの提案の方向性となります。

5-1-2. スケッチング

スタイリングは感覚的な判断を必要とする領域が多いため、明確なイメージなく着手すると多くの時間を浪費する可能性があります。そのため事前に類似アプリケーションを模写し、スタイリングの感覚を掴んでから制作に着手しています。タイミングとしては、基本スタイリング制作の前に行うこともあれば、スタイルの方向性検討の前に行うこともあります。模写を担当するは当然UIデザイナーですが、その選定にはコンサルタントやディレクターが関与することもあります。

5-1-3. 基本スタイリング提案

アプリケーション全体のトーンを決定するスタイルの制作です。スタイルの方向性をある程度合意して開始するため、基本的には1案、意見が分かれそうな場合は2案提示します。メインで利用するデバイスを前提にホーム（ダッシュボード）、検索一覧画面、詳細画面など主要画面のいくつかにスタイルを適用し、イメージの合意が取れた時点でこの工程は終了し、次の工程に移ります。UIデザイナーが担当します。

ベイジではUIデザイナーの制作品質を上げるために「デザインレビュー制度」を設けています。クライアント提案前にスタイリング（途中段階でも可）を専用チャットに投稿すると、他のデザイナーからのフィードバックがもらえます。これをヒントに、担当UIデザイナーはスタイリングのブラッシュアップを行っていきます。

このようにベイジでは、アートディレクターのような職能長がデザインの最終意思決定をするのではなく、各UIデザイナーが自ら考えて最終決定を下します。自立した状態を維持しながら、お互いが協力しあって1つのプロジェクトを作り上げていくような組織設計となっています。

5-1-4. スタイルコンセプト定義

制作した基本のスタイルについて、どのような考えに基づき導かれたのか、論理的に説明したコンセプト定義を資料化します。クライアントのご担当者とは、前段のタスクでスタイリングの方向性を合意しているため、必ずしもこの資料を作成しなければいけないわけではありせん。

しかし、大規模プロジェクトの場合、プロジェクトに参加していないクライアントの決裁者がいることもあるため、クライアント社内での合意形成として必要があれば、コンセプト定義の資料を作成します。

5-1-5. 主要画面スタイル適用

基本スタイリングでトーン＆マナーについて合意が得られたら、基本スタイリングで対象としていなかった残りの主要画面に対して、スタイルを適用させます。多くの場合は、複数回に分けて制作を進行し、都度クライアントと合意を取っていきます。

5-1-6. プロトタイプユーザーテスト

スタイルを適用した主要画面が実際にユーザーに使いやすい画面になっているか、実際にユーザーに操作していただきテストします。基本的には現行アプリケーションで行ったユーザーテストと同じシナリオで行い、どのような改善効果があったのかを検証します。ここで見つかった新たな問題点はすぐに改善し、実装前に可能な限り問題点を減らします。

5-1-7. 展開画面スタイル適用

基本画面のスタイルが決まると、レイアウトやスタイルのルールがほぼ網羅されるので、一貫性を意識し展開画面へも同じルールでスタイルを適用できるようにします。全画面のスタイルは再現させず、新たに必要となる必要最小限のテンプレートだけを制作し、残りはHTML上で展開します。

5-1-8. アクセシビリティチェック

デザインがアクセシビリティ要件を満たしているかを確認します。例えば、以下のような内容です。

• 背景色と文字色のコントラスト比が水準を満たしているか
• 複数の画面で共通して用いられる構成要素はすべての画面で同一のルールで統一されているか
• クリックやタッチに反応するサイズが十分な大きさになっているか

アクセシビリティ要件によってチェックすべき項目が異なるため、それに合わせて検証期間を設けます。

5-1-9. UIコンポーネントリスト制作

展開画面のスタイル適用までに登場したUIコンポーネントのラインナップを網羅するデザインデータを作成します。配色、文字サイズ、行間などの基本ビジュアルやコンポーネントを定義し、Figmaに登録することでデザイン制作時の一貫性を保ちます。

また、エンジニアが効率的に作業できるよう命名規則を定め、各コンポーネントの状態（デフォルト、フォーカス、hover、エラー、非活性など）に応じたデザインを作成します。

5-1-10. マイクロインタラクション設計

UIコンポーネントを操作した時のマイクロインタラクションを設計します。ユーザー体験に大きく影響するため、実装後もUIデザイナーとエンジニアで適切なマイクロインタラクションを追求します。

5-2. クリエイティブ制作

基本的に業務システムでは図版などの制作はありませんが、ビギナー向けコンテンツのイラスト制作やサービスロゴなどの制作が必要な場合があります。その際は別途クライアントにご要件を伺い、対象アプリケーションに組み入れます。

感覚的な領域が多く、作りこんでしまった後の修正が容易ではないため、以下のように段階的なプロセスで進行します。

• 方向性の確認
• 基本的方向性の決定（基本デザイン制作）
• ラフスケッチ制作
• 制作
• パターン展開
• 画像化（SVG/PNG/JPEG）
• HTML反映

ラフスケッチで出てきた捨て案などもすべてクライアントに開示し、認識相違がおきないようにしています。

5-3. 画面仕様書作成

各画面の操作仕様はワイヤーフレームがあれば把握できるので、実装自体は可能です。但しクライアントのご要望により、完成したスタイル画面での仕様書が必要な場合、ご希望のフォーマットで画面仕様書を作成します。

6. 開発

フロントエンドモックアップの実装を行うフェーズです。ベイジではダミーデータが入ったモックアップの実装を担当するケースが多いです。クライアントや協力会社の開発担当者と協議し、開発の役割分担を決めながら進めます。基本的には1名のフロントエンドエンジニアで進めますが、大規模システムの場合、複数名のフロントエンドエンジニアでチームを組んで実装します。

6-1. 開発準備

6-1-1. 開発ブリーフィング

設計フェーズ以前の内容を元に、エンジニア向けの社内ブリーフィングを行います。プロジェクト概要、システム要件、開発体制、ワイヤーフレームの設計情報をエンジニアに共有し、進め方やクライアントに追加で確認すべき前提事項を確認します。

6-1-2. UIライブラリ調査

ワイヤーフレームの設計情報から、必要に応じてUIライブラリを使用する箇所を確認します。例えば、ダッシュボードのデータビジュアライゼーション、ドラッグ＆ドロップUI、カレンダー、地図、データテーブルなど、独自に実装するより開発効率やメンテナンス性が高いUIコンポーネントについては、UIライブラリの活用を検討します。これにより、開発スピードの向上やバグの減少、保守作業の簡素化を図ります。

6-1-3. コーディングガイドラインの作成

プロジェクトの要件に合わせて、HTML、CSS、JavaScriptの記述方法、ライブラリ利用ルールなどをガイドライン化します。クライアント側からの要望があれば反映しますが、特に指定がない場合、ベイジで保有している標準ガイドラインをそのまま用います。エンジニアが担当します。

6-1-4. 開発成果物管理方法検討

実装進捗・課題管理については、基本的にbacklogを使いますが、クライアントの環境で利用が難しい場合は、スプレッドシートやエクセルファイルを利用するなど管理方法を柔軟に検討します。この段階で納品物と納品方法などについても改めてクライアントと確認します。

6-1-5. UIの仕様詳細化

設計/デザインで検討した仕様に対して、実装観点で詳細化します。ここで定義した内容をもとに、コンポ―ネントごとの単体テストにて仕様を満たすかどうかを確認できるようにします。

6-1-6. 開発環境準備

モックアップを配置する開発サーバの初期設定や、ファイルのバージョン管理に使用するGitの準備を行います。開発環境の情報は【サーバ情報シート】にまとめて、プロジェクトメンバーに共有します。場合によっては、クライアントの開発環境やGitに招待いただき共同開発をすることもあります。

6-2. コーディング

6-2-1. 基本レイアウトコーディング

ホーム（ダッシュボード）、検索一覧画面、詳細画面、編集画面など、代表的な3～4画面をピックアップし、コーディングガイドラインに従って実装を進めます。レスポンシブ対応などもこの段階で行い、アプリケーションの全体におけるレイアウトの基本構造をこの段階で決定します。

デザイントークンをソースコードに反映させるなど、後に続くコーディングをスムーズに行うための準備を整える作業もこの中で行います。

ソースコードをゼロから書くことは少なく、過去案件のソースコードを積極的に再利用したり、独自作成した共通ライブラリを用意するなどして、実装の効率化、品質の向上を目指しています。より多くの案件で同じソースコードが活用できるよう、さらなるテンプレート化を進めています。

6-2-2. UIコンポーネント実装

利用するUIコンポーネントを実装します。UIデザイナーが作成したUIコンポーネントリストを網羅できるよう作成します。

実装の際は「Storybook」を利用することで、コンポーネントをカタログ化すると同時に、開発者が一目でコンポーネントが持つ状態やプロパティを実装レベルで一覧できるようにします。

Storybookでカタログを作成しておくことで、リリース後の運用や改修の際に実装担当者でなくてもコンポーネントの把握が容易になるメリットがあります。

6-2-3. マイクロインタラクションコーディング

マイクロインタラクションを実装します。デザイナーとエンジニアで議論しながらソースコードを改修し、約1～2日かけて調整します。マイクロインタラクション実装はこの一度の工程だけで完全に終わることは少なく、後述するデザインチェックでもブラッシュアップを行います。

6-2-4. 主要画面コーディング

基本レイアウトコーディングで実装しなかったその他のレイアウトパターンの画面を実装します。UIデザイナーが作成したデザインデータをもとに密にコミュニケーションをとりながら進めます。ここまでで難易度の高い複雑な画面の実装をやりきり、残りの画面はコードの流用中心で進められるようにします。

6-2-5. 展開画面コーディング

主要画面と同テンプレート・データ違いの画面を実装します。ここからは基本的にワイヤーフレームや、画面項目のみを定義した資料をインプットとして実装します。画面数が多い場合は、複数人のエンジニアで同時に作成します。

6-3. スタイリングレビュー

ベイジではコーディングの進捗は毎日報告され、プロジェクトの全メンバーが常時確認できるようになっています。コンサルタントは計画していた改善方針やコンセプトが反映されているか、UIデザイナーはUIデザインが意図したとおりに実装されているかをその都度確認し、必要であれば随時フィードバックできるようになっています。「スタイルや仕様がドキュメント通りにHTML化されていればよい」と安易に判断せず、ブラウザで表示された時に最適なUXが提供できるという観点から、ブラッシュアップをしていきます。

6-4. 単体テスト

操作仕様に関わる実装に問題がないかをコンポーネント単位で検証します。例えば、以下のような内容です。

• カレンダーの動作が正確か
• 入力操作による項目の表示／非表示／非活性の切り替え処理が正確か
• データテーブルのソートやページネーションの動作が正確か
• バリデーションチェックのエラー動作が正確か

ウェブアプリケーションでは動作検証の確認観点が多いため、モックアップでどこまでの動作を保証するかはクライアントと入念に確認します。

6-5. 品質チェック

6-5-1.ブラウザチェック

単体テストが終わり、不具合の反映がすべて完了した後、網羅的なブラウザチェックを実施します。標準的な対象ブラウザは、PCはWindowsのEdge、Chromeと、MacintoshのSafari、スマートフォンはiOS最新版のSafari、Android最新版とし、後は案件特性に合わせて追加・削除を行います。

ブラウザチェックはディレクターもしくはエンジニアが作る【テストシート】を用いて実施します。納品までは品質を少しでも高めていきますが、多様なブラウザでの完璧な表示に固執するのは時間・コストの面で非現実的なため、ある程度の表示差異、挙動の違いは許容し、重篤な不具合があれば納品後に対応します。

6-5-2. アクセシビリティチェック

アクセシビリティ要件を満たす実装になっているかを確認します。例えば、以下のような内容です。

• スクリーンリーダーの妨げになるような、画像で作成されたテキストがないか
• 背景色と文字色のコントラスト比が水準を満たしているか
• Tabや上下キーなどのキーボード操作のみでも利用可能か
• ブラウザのズーム機能に応じて文字サイズが変更されるか

アクセシビリティ要件によってチェックすべき項目が異なるため、それに合わせて検証期間を設けます。

6-5-3. シナリオテスト

ユーザーが行う一連の流れに沿って、問題なくシステムを利用できるかを確認します。同時に、当初の課題を意図通りに解決できているかについても評価します。

7. 納品

7-1. コアデザインシステム

実開発でスタイルを他画面に展開する際や、その後の改善アップデートでもデザインを継承するために、UIデザインで定めたルールを簡易的なデザインシステムとして定義します。クライアント自身が運用管理しやすいフォーマットで作成します。UIデザイナーが担当します。

7-2. 開発指示書制作

クライアントの開発担当者向けに、モックアップを実開発に転用にする際に必要な情報を共有します。コンパイル方法、ディレクトリ構成、命名規則などの注意点をまとめた資料を作成します。エンジニアが担当します。

7-3. 納品物確認ミーティング

実開発にUIデザインを組み込むため、モックアップのソースコードの他に、デザインデータ、コアデザインシステム、開発指示書を納品します。

デザインデータとコアデザインシステムは、運用に慣れていないクライアントが多いため、どのようなシーンで参照し活用するかを説明します。また、開発担当者にはソースコードと開発指示書をご確認いただき、その他に共有すべき情報がないかを確認します。

7-4. 納品作業

納品物確認ミーティングでのクライアントからのフィードバックをうけて納品物を修正し、正式に納品します。UIデザインのプロジェクトとしては一旦完了しますが、効果の検証、保守や改善など、引き続きクライアントを支援します。

7-5. クロージングミーティング

納品後1～2週間以内に、社内のプロジェクトメンバーを集めてクロージングミーティングを実施します。プロジェクトメンバーがプロジェクトを振り返り、感じた課題や問題点が【クロージングミーティングシート】にまとめられます。このシートをもとに話し合い、解決するための具体的なアイデアを導き出します。アイデアには明確な期限やタスクを設定し、ワークフローやドキュメントに反映していきます。このように、プロジェクトの中で失敗や課題を見つけるたびに、自律的に仕組み、組織、人が成長していくというのが、ワークフロー化することの最大の価値であり、それを実現しているのが、このクロージングミーティングです。

8. 納品後の支援

8-1. 開発中のUIデサイン保守

納品以降はクライアントや開発会社でのシステム開発が主役になります。UIデザインを開発に組み込んだ場合に発生する様々な調整を、リリースまで支援します。主な支援内容は以下の通りです。

• 追加画面開発による不足UIコンポーネントの制作
• 後に発覚したシステム制約や追加要件による設計変更
• UIデザインが正しく再現されているかのレビュー
• 実データが画面に入った際の微調整

8-2. リリース後のUIデザイン改善

サービス開発はリリースしたら終わりではありません。真にユーザー視点のデザインを目指すなら、リリース後の改善も不可欠です。継続的にログによる定量分析、ユーザーリサーチによる定性分析を交えた支援を継続し、最適なUIデザインの改善を提案します。

さいごに

今回公開した業務システムUIデザインワークフローは、ベイジにとっては初版であり、現在のワークフローが完璧ではありません。特に、システム開発のプロセスは時代とともに急速に変化しているため、頻繁にアップデートしていく必要があります。我々のワークフローも継続的にアップデートを行っていきつつ、変更点がある程度まとまった段階で、また皆様に情報共有させていただきます。

2024年6月27日追記
最初の公開から3年が経ち、今回の記事内容をアップデートしました。今後もワークフローの改善や新たな知見を反映させながら、この記事を随時更新していきます。引き続き、最新の情報をお届けできるよう努めてまいりますので、どうぞご期待ください。

そしてベイジでは、今後も業務システムのUIデザインに関するノウハウを紹介する『業務システムUIデザイン手帖』を連載していきます。次回もご期待ください！