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

2021年現在、ベイジの柱の事業はウェブ制作事業とウェブアプリデザイン事業です。ウェブ制作事業は会社設立の2010年からの主力事業で、サービス品質の平準化を目的に2014年頃からワークフローの整備を進めてきました。

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

基本的な進め方は国際規格（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）】を作成します。新規に作ることは少なく、契約前段階で作られた素案を調整して仕上げることが多いです。新規作成する場合も、すべてのワークフローを網羅したテンプレートが社内Wikiで配布されているため、30分～1時間程度で、WBSを作ることができます。ベイジではディレクターが担当します。

この段階で細かいWBSを作成することで、クライアントに進め方をイメージしてもらいプロジェクト開始後の認識齟齬を防ぎます。

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

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

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

WBSが決まったら管理ツールを準備します。ベイジでは、全体の進捗状況の把握に【プロジェクト管理シート】を、細かなタスクの管理に【backlog】、細かな連絡にはチャットツールの【Typetalk】を使用しています。

プロジェクト管理シートとは、プロジェクトの進捗状況をタスク毎に細分化したシートです。WBSに似ていますが、WBSがクライアント提示用であるのに対し、プロジェクト管理シートは社内管理用で、進捗状況の更新に特化しています。週次で更新され、毎週金曜日に行うプロジェクトミーティングで共有されます。WBS同様にテンプレートが存在し、30分程度で作成可能です。ベイジではディレクターが担当します。

さらに、クライアントとの間で利用する管理ツールの調整もここで行います。基本的にはクライアントの要望に合わせますが、問題なければ社内のbacklogプロジェクトにクライアントも招待し、社内の設計状況を常にオープンにしています。

1-5. 開発環境の準備

プロジェクト開始が社内周知されると、担当エンジニアは、サブドメイン申請や開発環境、ファイル共有環境に関する設定などを行います。開発環境は主に実装後のモックアップ動作確認のために利用し、クランアントにもアクセス・操作してもらいます。ファイル共有に関しては、近年はクライアント指定のクラウド環境を利用することも多いです。クライアントからの指定が特になければ、ベイジで契約しているGoogle Workspaceを利用します。

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

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

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

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

2. 要求理解

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

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

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

2-1. ヒアリング

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

まずは関係者へのヒアリングからスタートします。契約前の打合せ内容、RFP、現行システム、エンドユーザーの改善要望などを元に、Excel/Googleスプレッドシートで作られた【ヒアリングシート】にヒアリング項目をまとめます。これをキックオフミーティングの約2週間前にクライアントに提出し、回答してもらいます。

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

業務システムのUIデザインのためにビジネス特性をお伺いすると不思議に思うクランアントも少なくありませんが、画面のスタイリングの方向性を決める貴重な材料となります。

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

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

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

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

• 全利用デバイス（SP/PC/タブレット/大型モニター）とメインデバイス
• 利用デバイスの最小解像度
• 前提となるフレームワークやライブラリ
• フロントエンドを覗く開発の体制とスケジュール

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

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

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

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

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

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

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

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

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

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

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

2-2-4. ログ解析

現在のアプリケーションのアクセス解析から、利用している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デザイナーは前段のユーザーリサーチにも参加するため、設計前にプロジェクトの前提を知っています。しかし、中にはリサーチを行わず、簡易的に現行画面の確認とエキスパートレビューのみを行い設計を開始するプロジェクトもあります。その場合は、社内ブリーフィングを通して、コンサルタントからUIデザイナーに改善方針とその経緯の情報共有をします。

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

クライアントのセキュリティ要件や環境などに合わせて、設計情報とそのレビュー管理の方法などをクライアントと合意します。設計情報そのものにはAdobe XDを使います。進捗・課題管理については、基本的にbacklogを使いますが、クライアントの環境で利用が難しい場合は、ExcelファイルやGoogleスプレッドシートでのやり取りなど、管理方法を柔軟に検討します。

4-3. 画面フロー設計

基本画面フロー構成検討で合意したルールに則り、メニュー全体の画面遷移とグローバルナビゲーションのメニュー構成を検討します。ここでの成果物は【画面遷移図】です。
このタスクで画面のラインナップが出揃うため、併せて管理用の画面一覧をExcelもしくはGoogleスプレッドシートで作成し、URLやタイトルなどを定義します。

4-4. 主要画面設計

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

ベイジではAdobe XDで作られたワイヤーフレームのテンプレートが用意されており、UIデザイナー以外でも完成度が高いワイヤーフレームをすぐ作れるようになっています。また必要に応じて設計意図や動線を言語化した図表を添付し、ユーザー視点で画面設計の議論ができるようにします。

ワイヤーフレームの制作は、他のデザイン会社ではディレクターが担当することも多いですが、ベイジでは基本的にUIデザイナーが担当します。

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

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

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. UIコンポーネントリスト制作

展開画面のスタイル適用までに登場した、UIコンポーネントのラインナップを網羅するデザインデータを作成します。主要画面のスタイル適用の時点でUIコンポーネントが網羅できている場合は、早めにルール化し、展開画面の制作前にUIコンポーネントリストを準備しておきます。これはコアデザインシステムの基礎となります。

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

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. 開発環境準備

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

6-2. HTMLコーディング

6-2-1. 基本コーディング

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

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

6-2-2. ストーリーブックコーディング

利用するUIコンポーネントを管理するカタログを実装します。UIデザイナーが作成したUIコンポーネントリストを網羅できるよう作成します。画面実装を進める前にストーリーブックを作成し、各画面でのUIコンポーネントの実装がばらつくのを防ぎます。

ストーリーブックはクライアントにも納品し、リリース後の改修や画面追加の場合にもスタイルを継承していただくために活用されます。

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

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

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

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

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

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

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

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

6-4. 動作検証

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

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

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

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

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

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

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

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

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

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

7. 納品

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

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

7-1-1. スタイルルール

アプリケーションの画面全体に適用する基本のスタイルルールを定義します。例えば、以下のような内容をまとめます。

• 使う色のバリエーションと利用シーン
• 文字に関するルール（フォント、文字サイズ、行間、太さ）
• 装飾（枠線、シャドウ）
• アイコン（利用できるアイコンとその意味合い）

7-1-2. レイアウトルール

画面内のゾーニングのルールを定義します。ヘッダーエリア、ナビゲーションエリア、コンテンツエリア、フッターなど全画面共通のレイアウトおよび、一覧画面、情報照会画面、編集画面、モーダル画面などの画面パターンごとのレイアウトを定義します。

7-1-3. UIコンポーネントルール

見出し、ボタン、入力フォームなどUIコンポーネントごとのスタイルルールを定義します。通常の見た目のみではなく、非活性時、フォーカス時、エラー時などの状態ごとに定義をします。

7-1-4. アクセシビリティルール

背景色・文字色のコントラスト、最小フォントサイズ、カラーユニバーサルデザインなど、アクセシビリティ要件を満たすために定義しているルールを記します。

7-2. 開発指示書制作

クライアントの開発担当者向けに、モックアップを実開発に転用にする際に必要な情報を共有します。フォルダ構成や必須ライブラリ、コンパイル方法などが主です。エンジニアが担当します。

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

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

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

7-4. 納品作業

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

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

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

8.納品後の支援

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

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

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

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

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

さいごに

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

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