システム開発会社のデザインチームがまとめる「デザイン」の進め方
はじめに
われわれはシステム開発会社に所属するデザインチームです。
情報提供を主とする「Webサイト」よりも、ユーザーが検索・入力・購入などの主体的行動をとる「Webアプリケーション」に関わることが圧倒的に多く、コンテンツよりも機能を活かすためのデザインを得意分野としています。
ですので、進め方や考え方について、世の中のWeb制作会社とは違った側面を持っていると思えることがよくあります。
- エンジニアとの連携・会話が日常的に発生する。
- 「キレイなもの・おかしみのあるもの」よりも「わかりやすいもの・効果のあるもの」
- 維持・管理できないドキュメントは極力作成しないかわりに、ドキュメント不要なレベルまで議論を交わす。
- デザインしたら当然のようにコードも書く。
- 「リリース＝終わり」ではなく「リリース＝改善の始まり」
「デザイン」という単語は指し示す範囲があいまいで、ひとり歩きしやすく、とらえどころのない概念になりがちです。そのため「Webデザイナー」の職域や仕事の進め方についても、画一的に規定するのはとても難しいことです。
- 見た目を整える人のことなのか。
- 導線や画面詳細を設計する人のことなのか。
- ユーザーとの接点における問題を発見し解決する人のことなのか。
- プロジェクトのどこからどこまでに関わるべきか。
- デザインが先なのか、機能が先なのか。
- コーディングもできるべきなのか。
- 何をインプットすれば、「いい感じ」にアウトプットしてくれるのか。
当社にとってデザインはシステム開発工程の一部です。デザイナーとエンジニアとの距離がきわめて近いことによるメリットは数多く、デザインへの取り組み方にもその特徴が色濃く出ていると感じます。
そこで当社デザインチームの進め方・取り組み方について、まとめてみることにしました。
- 何をどこまでやっているのか
- 力を発揮するためには何が必要なのか
ここでご紹介するのは、業界としてこういう標準であるべきと訴えるものではありません。
また、会社から強制されたものでもありません。
- 「こういうことを自分ごととして動いているデザインチームがあります」
- 「こんなことに留意いただけると、われわれはより協力しやすくなります」
そんなおはなしです。
5つのフェーズ
われわれはプロジェクトにおけるデザインの進め方を、5つのフェーズに分けて考えています。
- デザインで解決すべき課題を明確化する（デザイン要件定義）
- ユーザーが「分かりやすい」「使いやすい」情報の順番・優先度・表示形式を決定する（ユーザーインターフェース設計）
- 情報がきちんと伝わるように表現のルールを調える（ビジュアル設計）
- デザインしたらコードも書く（UIコーディング）
- 改善の基礎を固める（集客・分析などに関する整備）
このうちの一部だけをお受けすることもあれば、全部を引き受けることもあります。
お客様が社内に抱えるデザイナーと連携することもあります。
どの形態がよいかは一概に言えませんが、すべてのフェーズに参加できているほうが、コンセプトや前提を把握しながら深く動けます。
「ビジュアルは社内デザイナーが作成するので、コーディングだけお願いしたい」
という場合でも、その前からオブザーバー的に参加して全体を把握できれば、のちのちの変化を見越した拡張性の高いコードを書きやすくなります。
社内向けに概略を示したのが以下のスライドです。
▼スライドをタップすると進みます
1. デザインで解決すべき課題を明確化する（デザイン要件定義）
実施するために必要なこと
- ビジネス要件定義の完了
詳しくは「要求、要件定義をする前に、あなたについてしつこく聞くこと」をご参照ください。
ヒアリング
認識している課題と目標を明確化にするために行います。
- 定量的な指標の有無（現在値と目標値のギャップ）を必ず把握しておいてください。あなた（クライアント）のビジネスです。
- 「どうあってほしいか」という理想を大いに語ってください。
- 現状を活かしたいところがあれば教えてください。いいものは残した方が良い場合もあります。
- メインターゲットが誰かを教えてください。
- オンライン・オフライン問わず、競合として認識している相手を教えてください。
- 実際の運用体制なども聞きます。小さい組織であれば、小さい組織なりの進め方があります。
- われわれはあなた（クライアント）の業界に対しては素人であり、ユーザーの目線に近いかも知れません。小さなことや当たり前なことでも、ぜひ教えてください。
競合分析
ヒアリングで得た競合情報を精査するとともに、自社と競合との比較も行います。
- 「ここも競合では？」と思えるところは、こちらでもピックアップします。
- 競合が強みを表現している部分、避けている部分などを見つけていきます。
- 自社にはないが競合にはできていることや、どの競合も実施していないができていると嬉しいことなども見つけていきます。
ユーザー分析
メインとなるターゲットユーザーの行動・心理をシナリオ化します。
- ターゲットユーザーは、どんな時に嬉しくなるか・残念に思うかなどを考えていきます。
- 嬉しくなるポイント（Gain）を伸ばすこと、残念に思うポイント（Pain）を解消すること、どちらも大事です。これからいっしょに作ろうとしているものは、どちらにフォーカスすべきものでしょうか。
- 教科書どおりにペルソナを作っても構いませんが、「本当にこんな人いるの？」という都合のいいペルソナにならないよう注意が必要です。
- 身近な人がターゲットユーザーに近ければ、その人をペルソナ的に扱うと具体性が増します。
- 「普通こうだよね」と片づけてしまうところに、顕在化しにくい不便が眠っているかもしれません。
ユーザーシナリオの作成
どんな状況のユーザーがいて、どんな情報が必要なのかを洗い出すために、ユーザーの行動をいくつかシナリオ化します。
- イレギュラーなパターンを考えすぎると、重要なポイントが見えにくくなったり、冗長なシナリオになるので、代表的な行動に絞って構いません。
- ユーザーの行動が想像できない場合、出口からさかのぼって洗い出すと、屋台骨が見えてきやすくなります。
- ユーザーに達成してもらいたい目標はなんでしょうか。
- その目標を達成するために必要な行動はなんでしょうか。
- その行動を起こすために必要な情報はなんでしょうか。
- その情報を補強する情報はなんでしょうか。
- ユーザーにもっとも訴えたい価値は何でしょうか。
- 何を入り口とするでしょうか。
現状分析
特にサイトリニューアルで実施します。
現在のサイトの課題を洗い出し、あるべき姿とのギャップや仮説を提示します。
ヒューリスティック評価と呼ばれたり、エキスパートレビューと呼ばれることもあります。
- ユーザー目線で「ここが分かりにくいのは」「ここが使いにくいのでは」を見ていきます。
- 同時に、開発者目線で「ここはもっと使いやすくできるのでは」という代案を考えていきます。
- ダメ出しをするための活動ではありません。
- 「これは使いやすいですね」「ここは特長的なので残したいですね」などの評価も行います。
- 数値での裏付けができるとなおよいので、
Google AnalyticsやGoogle Search Consoleなどの閲覧権限をいただけると、より捗ります。
規模感やスケジュール感の把握
- これから考えることや作るもののボリュームを把握し、スケジュールと比較して妥当かを考えます。
- スケジュールの中で重要なマイルストーンを教えてください。
- 期限が短い中で品質を担保する場合、重要でないものを最初のリリースから外すことも大事な進め方のひとつです。外したものは本当に需要があるものだったか、リリース後の反響を見てから再度検討することもできます。
このフェーズが生む効果
- デザインで解決すべき課題と、デザイン以外で解決すべき課題の分別
- ユーザー行動の可視化
デザインで解決すべき課題の例
- 〇〇が使いにくい、分かりにくいのを改善したい。＝ユーザーインターフェース設計で解決したい課題
- 〇〇の価値をもっと伝えたい。＝ビジュアル設計で解決したい課題
デザイン以外で解決すべき課題の例
- 〇〇の処理を効率化したい。＝機能設計で解決したい課題（ユーザーインターフェース設計で解決できる場合もあります）
- どのようなサービスがターゲットにウケるか考えてほしい。＝デザインの話の前に、まずビジネス要件定義を済ませましょう。
詳細は「デザインは何を解決できるのか？」（作成中）
2. ユーザーが「分かりやすい」「使いやすい」情報の順番・優先度・表示形式を決定する（ユーザーインターフェース設計）
実施するために必要なこと
デザイン要件定義の完了
機能要件の収集
「どのような機能を導入することが決まっているか」を把握します。
「形態は機能に従う（Form Follows Function）」という言葉にもあらわれるように、デザインが担う役割のひとつに「機能へのフォーカス」があるからです。
- 機能一覧をもとに把握します。どんな機能があるか決まっていない場合は、まだ要件定義が不足しているかもしれません。
- ただし、デザインを検討するなかで、新たな機能のアイデアが生まれることもあります。
情報の構造整理（情報アーキテクチャ）
必要な情報を見つけやすくするために、分類・階層化・優先順位づけを行います。
- 全体構造の整理
- ユーザーシナリオの確認
- 画面分類
- ナビゲーションの整理
- 情報の階層化・優先順位・並び順
- ラベリング
- 整理した結果にもとづいて、ローレベルサイトマップを作成します。全画面をリスト化したもので、構成に関する情報が詰まっています。
- 大・中・小分類情報
- 階層情報
- タイトルやDescriptionなどのメタ情報
- 検索エンジンへのインデックス有無
- 新旧URL定義
- 301リダイレクト有無
- SEOに関する設計もある程度ここで行います。
（ローレベルサイトマップのイメージをそのうち挿入します）
ワイヤーフレーム作成
どの画面に、どんな情報が、どんな形式で存在するかを示すものです。
いきなりデザインカンプに入ると手戻りした場合のロスが大きいので、ここで最低限の構成について認識合わせをするために用います。
- 具体的なビジュアルに落とし込まれていないワイヤーフレームを見せられても、良否の判断がつかないのはあなた（クライアント）にとって当然のことです。ですので、ここには時間を掛け過ぎず、重要な事項について手早く確認したいと思っています。
- 極端な話、対面で議論しながらホワイトボードにラフ書きしたものをワイヤーフレームと呼んでもさしつかえありません。
- それを清書する時間は、デザインカンプを描く時間にまわしましょう。
- 情報アーキテクチャについてお互いの認識が非常に近いという確信を得た場合、ワイヤーフレームをとばしてデザインカンプ作成をおこなうこともあります。プロジェクトのスピードが上がりますので、そうなるようここまでの議論を充実させましょう。
- 当社デザインチームがワイヤーフレームを作成する場合、そのなかに細かい画面仕様は記述しません。
- 画面表示仕様はUIコード内にコメントで記載してエンジニアに伝達します。
- 仕様経緯を知りたくなったら、Backlogなどのタスク管理ツールで追えます。（そのために議論の証跡はなるべく文字で残しましょう）
- ワイヤーフレームは手戻りの危険性を減らすための合意材料のひとつです。仕様書ではありませんし、もっと柔軟に扱いたいと思っています。
- 管理するドキュメントを減らし、仕様があちらこちらに散在する事態を未然防止することが大切です。
（ホワイトボードに描いたワイヤーフレームのイメージをそのうち挿入します）
ワイヤーフレームの注意点
このようなワイヤーフレームの扱い方は、1人のデザイナーがプロジェクトの最初から最後までかかわる体制だからできることです。
われわれがこのフェーズに関わっていない場合（お客様やPM、エンジニアのみで検討を済ませた場合など）は、デザインカンプをスムーズに組めるよう、高精度のワイヤーフレームを提供いただく必要があります。
- 情報の分類や優先順位について関係者が合意しており、明確な基準がある。
- どんな情報が、どんなページに存在するのかが確定している。
- そのページでもっとも重要な情報や、ユーザーに一番とってほしい行動が何かが、第三者にも判別できる。
- どのパーツが、他ページと共通で使用するものなのか判別できる。
- 見出しやリード文などに、実際に使用する文言が入っている。
- ボタンのラベルなども決定している。
- リンク関係が明確になっている。
- 内容がない場合や、エラーが発生する場合の考慮がある。
- フォーム要素については、各入力要素が適切なものか吟味されている。
- アニメーションやインタラクションの希望があれば明記されている。
- 以上が、原則的には全ページについて網羅されている。
- 最後に、これはユーザーにとって使いやすいものである、という自信がある。
プロトタイピング
前例のない革新的なユーザーインターフェースの場合、以下を事前確認するために、簡単なプロトタイプを実装して画面上で確認します。
- 本当に実装することができるか？
- 本当に使い物になるか？
- もっと使いやすい方法はないか？
このフェーズが生む効果
- 「使いやすいサイト」への進化
成果物
- ローレベルサイトマップ
- ワイヤーフレーム（その必要に応じて）
詳細は「使いやすいサイトを、手戻りなく作るための最小限の方法」（作成中）
3. 情報がきちんと伝わるように表現のルールを調える（ビジュアル設計）
実施するために必要なこと
- ワイヤーフレーム
- または、ワイヤーフレームを必要としないほど精度の高い、画面構成に関する合意
伝えたいメッセージの収集
- 伝えたい価値・特長はなんでしょうか。一言で表せるほど研ぎ澄まされているでしょうか。
- どんな印象を与えたいでしょうか。言語イメージスケール から選んでみましょう。
グラフィック選定
- グラフィックは伝えたいイメージを表現するための強力な手段です。そして、イメージを容易に左右しうる諸刃の剣でもあります。
- オリジナルな画像が手元に眠っていないか、まずは探してみましょう。お仕着せのストックフォトよりも具体的で、ユーザーの好感を得られるかもしれません。
- 画質が悪いものでもザラついた加工をしたり、ボカしたりすると、味わい深くなったりします。まずは集めてみましょう。
- スタイリッシュな写真を用意するのが最善とは限りません。「あなたらしさ」を表現できるものが一番です。
- グラフィックを無理に使わないことも立派な手法であると心得ましょう。
カラー設計
- 色は印象を操作するほか、識別性や誘目性を向上させるのにも役立ちます。
- ユーザーに与えたい印象はあるでしょうか。
- コーポレートカラーなど、あなた（クライアント）を象徴する色はあるでしょうか。
- メインカラーにするのが難しいコーポレートカラーもあります。固執しすぎないようにしましょう。
タイポグラフィ設計
- システムフォントを基本的には使用しますが、Noto SansをWebフォントとして使用することもあります。
- 英文フォントで特徴を出したい場合は、Google Fonts 経由で利用できるものから選定いただいています。
カンプ作成
- おもにAdobe XDで作成します。リンクを貼るのでページ同士の繋がりも確認しやすく、実際の画面にかなり近いものを確認できます。
- 代表的なページはなるべく描きますが、重要度の低いページはUIコーディング時にインブラウザデザインで済ませることもあります。
このフェーズが生む効果
- 「感情に訴えるサイト」への進化
成果物
- デザインカンプ
詳細は「論理でつくるビジュアルデザイン」（作成中）
4. デザインしたらコードも書く（UIコーディング）
われわれがもっとも得意としているフェーズであり、書きたいことがあまりにも多いため、随時加筆していきます。
とりあえず初稿段階にはまったく揃いませんでした。
実施するために必要なこと
- デザインカンプ（インブラウザデザインを行う場合はワイヤーフレーム）の完成
- API仕様が策定済みであること
静的部分のコーディング
APIを利用した動的部分のコーディング
クライアントサイドバリデーションチェックの実装
分岐やイレギュラーパターンに関する指示コメントの明記
このフェーズが生む効果
- エンジニアはサーバサイド開発に集中 ＝ 開発効率上昇
- モック内に表示系指示を網羅 ＝ 指示書類の乱造防止 ＝ 正式仕様の所在明確化
- 完成イメージに近いものを実機で最速で確認＝画面表示仕様系の手戻り防止
詳細は「UIコーディングポリシー 55」（作成中）
5. 改善の基礎を固める（集客・分析などに関する整備）
実施するために必要なこと
- 外部SEO会社の不在
- 分析ツール系の権限取得
SEO関連の定義（META全般、構造化データ、301リダイレクト設計）
Google Analytics、Google Tag Manager、Google Search Consoleの準備・確認
仮説構築
「どんな情報を」「どう表現すれば」、現在値と目標値のギャップを埋められそうかという仮説を立てます。
- 「〇〇が△△になると、ターゲットユーザーは嬉しい」
- われわれも考えますが、あなた（クライアント）も考えると、なおよい仮説構築になります。
- できるだけユーザーの立場を想像し、感情面からも考えてみましょう。数値から導ける仮説ばかりではありません。
- 仮説が妥当だったかという回答はリリース後のユーザー動向で判断します。
- 仮説に違和感を感じたときは、その感覚と向き合いましょう。どこか無理していたり、実は納得できていない内容かもしれません。
このフェーズが生む効果
- 改善体制のスムーズな導入
詳細は「デザイナー視点での仮説構築と改善」（作成中）
詳細は「GTM × 拡張Eコマースの導入ベストプラクティス」（作成中）
あとがき
以上、あくまでひとつのデザインチームの進め方・取り組み方でした。
少人数のチームだからこそできる割り切った部分、システム開発会社ならではの部分なども多く含んでいます。
われわれとお仕事をご一緒する前などに一読いただき、「われわれにご期待いただくこと」「ご自分で頑張っていただくこと」について、お互いに視界良好となればとても嬉しいです。
われわれも、ここで書いたことを最善として停滞するわけではなく、日々よりよい進め方に思いを巡らせています。考えを変えたり、新たにまとまったりしたら、随時内容を書きかえていきます。そのうちいま言っていることと、全然ちがう内容になっているかもしれません。
ですが、それでよいのです。
われわれが関わる周りの人々がより快適になり、われわれ自身も気持ちよく活動できれば、いまの考えに固執する必要はまったくありません。 そんな変化のきっかけになるかもしれない、お仕事やお客様に出会えるのを楽しみにしております。
これからもわたしたちを、どうぞよろしくお願いいたします。
お問い合わせはこちらから
問い合わせる