株式会社ドワンゴ、デザイン戦略室のデザイナーの宮下と申します。

デザイナーのみなさんはアプリのデザインを行う際に、どのようなワークフローで制作を進めていますか？
すべての仕事がそうであるように、アプリデザインのワークフローについても、制作体制やゴールの違いによって無限の選択肢が生まれます。

ここではわたしが関わったプロジェクトを元に、アプリが完成するまでのデザインサイドのワークフローをご紹介いたします。参考になるかわかりませんが、大まかな流れをつかみたいという場合は、ご一読ください。

STEP.0 普段から

ここでは、プロジェクトにアサインされる前から、日常的に気にかけておきたい項目をあげます。

あなたがもしもアプリのデザインを行ったことがないのであれば、以下の情報を頭に入れておくことをお勧めします。また、すでに経験があったとしてもアップデートの速度は速いので、制作の前に改めてチェックしておくとよいでしょう。

基本情報を収集する

ガイドライン・規約

プラットフォーム側が用意したガイドラインはかならずチェックしましょう。iOSに関しては厳しい（ちゃんとしてる）と評判のAppleによる審査がありますので、どのような内容か先に把握しておくのがよいと思います。また開発対象が、iOSのみの場合でも合理性の高いマテリアルデザインの考え方を知っておくことはとても有効です。（逆の場合も同様です。）

書籍

世に出ている書籍は玉石混合ですが、鮮度が高く、評価の高いものを数冊は読んでおくことをお勧めします。手に入る限り、詳細な情報に触れておくほうがよいでしょう。時節に左右されるものですので、これといってオススメの本はありませんが、アプリのUIのパターンを網羅した「モバイルデザインパターン 第2版」は押さえておきたい1冊です。

人に聞く

モバイルアプリの制作に関する情報の更新速度はとても速いので、近い過去にアプリの開発に関わった人にサービス設計・UI設計・実装上で気をつける点などポイントを尋ねることができれば大きな助けになります。エンジニア・ディレクター・デザイナーなどのロールは問いません。

トレンドをチェックする

常日頃から様々なアプリやサービスの動向には触れ、可能であれば自分なりに情報をまとめておきましょう。

UIデザインの「トレンド」については、おおまかに「一過性のもの」「スタンダードになっていくもの」が混在しています。表面的なトレンドに捉われてしまうと、せっかく制作したプロダクトも「半年後には陳腐化してしまった」という結果になりかねません。

デザインの背後にある論理を読み取ること、デザインを多層的に把えていくことが重要になります。そして経験的に、この部分についてはデザイナーにしか気付けないポイントが多くあります。

また、必ずしも「合理性が高い/ユーザビリティーが高い」UIが未来の主流になっていくわけではありません。わたしはそのトレンドが「半年後、1年後、2年後にユーザーにどう受け取られものになるか」を予想し、ひとつの判断基準にしています。

STEP.1 初期企画

そもそもどんなサービスを始めるかという、初期の企画段階から話を進めます。場合によっては、この段階はスキップしてデザインサイドの仕事が始まる場合もあるでしょう。

ミッションについてインタビューを行う

企画の立案者に対して「形」を作るデザイナーの立場からインタビューを行います。

この段階では、デザイナーの立場からビジネスとして成り立つイメージを持てるところまで質問を重ねることが重要です。その企画案はどんな「ユーザー」を想定しているのか？想定しているユーザーの「ニーズ」はなにか？提供できる「価値」はなにか？それらをつなぐアイディアはどのように競合サービスに対して差別化されているか？などが重要です。分析にはSWOT分析や、バリューポジショニングキャンバスなど俗にいうビジネスフレームワークを使うのもよいでしょう。（このあたりは経験者、専門家の力が必要です。）

掘り下げが甘い状態で、デザインを行うことはプロジェクトにとって非常にリスキーです。開発メンバー間での完成イメージを共有化するためにも、インタビューの結果を「ストーリーボード」などのビジュアルとして形にしておくことをおすすめします。

ユーザーのデータを収集・分析する

可能な限り、前段のインタビューで得られた「ユーザー像」に合致する「質・量」両面のデータを集めて分析します。

様々な手法があり、ここでは詳細には触れませんが、具体的には「アンケート」「フォーカスグループ」「行動観察・エスノグラフィ調査」などになります。ユーザーのデータは、この後の制作各段階において、制作物の評価に利用するため非常に重要です。開発チーム内でオープンな形で共有しましょう。

さて、これらのデータはそのままでは「直感的」に扱うことができません。「直感的」でないデータは取り回しにくいものであり、建設的でない議論の種になってしまう可能性もあります。

そこで、ユーザーのデータを仮に人格化した「ペルソナ」、ユーザーの行動をまとめた「ユーザーモデリング」、その行動を形にした「CJM（カスタマージャーニーマップ）」※などの形式に落としておきます。これらの形式でまとめた「想定するユーザー像・行動」は、初期企画のステップが終わった後も都度都度アップデートすることができますので、まずは完全を求めすぎないことが大切です。

企画書を作成する

ここまでの結果を踏まえて、具体的な戦略を立てていきます。

ターゲットユーザー、主なタッチポイント、主要な機能、ビジネスプランを最小限のサイズでまとめて「企画書」を作成します。

おそらくデザイナーが初期段階の企画書を直接作成することは少ないでしょう。ですが、デザイナーが企画立案者を助ける形で資料を作成することができれば、より「伝わりやすい」「共感の得られる」企画書を作成することができます。企画書に限らず途中段階の資料作成において貢献できる場面は多いので、積極的に参加しましょう。

ただし、特徴的なデザインが企画を牽引するようなケースは除き、この時点ではまだ企画書に作り込んだデザイン案を盛り込む必要はありません。

STEP.2 設計

この段階では、企画を元に開発チームで導線・画面の設計を行います。

「ことば」を定義する

企画段階でターゲットユーザー・主要な機能は浮かび上がってきていることと思います。

その中でサービスの中で使用する独自の「ことば」はなんでしょうか？これを一般的な用語や、iOS/Androidなどのデバイスに依存した用語、さらに開発者間で使用することばから切り離して整理し、一覧表を作成します。

後に変更があっても構いませんが、後半になればなるほど、「ことば」と、ある体験・機能・画面の結びつきと、単語同士の関連性はタイトかつ複雑になっていき、単語の定義を変更することはどんどん困難になっていきます。「ことばの定義」はサービスの根幹に関わる問題ですので、早い段階から慎重に行うことが求められます。

このトピックは開発プロセスにも大きく影響を与えますので、開発チーム全体で共同作業として推進する必要があります。その中でデザイナーはユーザーの視点を代表することになるでしょう。

導線・画面を設計する

ツールを選ぶ

ワイアフレームは手書きでも問題ありませんが、目指す完成状態を視覚化・共有するツールとしては、ワイアーフレームから実際のデザインまで通して使用できるグラフィックツールSketch3をおすすめします。詳細な内容が必要になってきた段階で併せてAdobe Illustrator/Photoshopを利用するとよいでしょう。

UIデザインのパターンを見極める

ここから「ユーザーの体験」をより詳細に設計していきます。具体的には、画面ごとの構成要素と、導線をレイアウトした「ワイアフレーム」を作成していきます。

（Sketch3の場合ですが）まず想定した主要な画面のアートボードをざっくりと、枠だけ作成します。ここで軽く画面のパターンをカテゴライズしておくと、少し考えるのが楽になります。ひとつの例ですが、以下のように分類してみました。

これらのコンテンツの種別ごとに、一般的にどのような「UIデザインのパターン」が適用されているかをまずは調査しましょう。UIによって強くサービスの世界観を押し出す必要がある場合を除き、「一般的なUIの文法」に則ってデザインすることは、ユーザーの認知を助ける意味でも、また実装コストの面でもメリットがあります。やってみると、多くの画面が、「一般的なUIの文法」をマッチさせることで作成できることがわかるはずです。

反面、おそらく上記の「コンテンツ」「プライベート」にあたる部分では、先ほどのことばの定義上、「独自の用語」が使用される比率が上がり、比例してレイアウトも独自のものであることが必要になってくるのではないでしょうか。

詳細度を上げていく

ここからはユーザー体験の流れに沿って、「評価と制作」のサイクルを重ねながら、ワイアフレームの詳細度を上げていきます。主要な導線については比較的初期の段階から、ワイアフレームと後述の「プロトタイピング」は切り離して行わず同期して進行させるとよいでしょう。

プロトタイピングを行う

ツールを選ぶ

プロトタイピングについても様々なツールの選択肢がありますが、この段階では「リアル」な動きを表現する必要がないので、Prottやinvisionなどの1枚の画面を連続で切り替えていくタイプのツールがよいでしょう。

ただし、ケースによっては、一般的でない独自性のあるUIの提案が必要になる場合もあります。その場合は、複数の画面をつなぐ導線の状態を表現することよりも、より複雑な動きをリアルに再現することが求められますので、Prot.ioやPixtate、Framer.jsなどのツールがオススメです。フロントエンドの制作能力が高いメンバーが、チーム内にいる場合は、HTML/JavaScriptで制作するのもひとつの手段です。

制作と評価のサイクル

プロトタイピングの準備が整ったら、チーム内の意見を集約し、導線と画面設計をブラッシュアップしていきます。Prottなどにはモバイルアプリ版がありますので、実機を操作し「評価」と「改善」を繰り返していきます。この繰り返しは、デザイナーが自分で制作して自分で評価する最小のレベルから、チーム全体で、プロトタイプを見ながらレビューを行うもの、ユーザーテストとして被験者を立てて行うものまで様々なスケールが考えられます。のちの実装後のユーザビリティーテストでも同様ですが、費用対効果が高く、かつ結果として確度が高い評価を得られるように計画を立てましょう。（これはとても難しい作業ですが）

また、プロトタイプの精度を高めるために、身近なプロジェクト外のメンバーを被験者にした簡易なユーザビリティーテストを行っていくことは、コスト面で有効な方法です。開発チームのメンバーはプロジェクトについて「知り過ぎている」ため、被験者には適しません。プロジェクトから遠い人ほどすぐれた被験者になります。

プロトタイプは全画面について詳細な部分まで作成する必要はありません。ストーリー上で、重要な点に絞って作成するほうが、効率があがります。また、「決まっている最新の仕様」を常にキープさせようとするとコストが跳ね上がってしまいます。制作の段階ごとに、要所要所で使い捨てていくつもりで運用するほうがよいでしょう。

仕様を確定させる

開発メンバーによる評価とフィードバック、そしてプロジェクトオーナーの承認を得て確定した機能・画面・パーツは、サーバーサイドエンジニア、アプリケーションエンジニアの手による実装が可能になります。その際に、仕様について曖昧な点があると混乱が生じるので、必要に応じて「仕様書」を作成します。

「仕様書」のフォーマットはシンプルなものがよいでしょう。ここには、基本的には「ユーザーにとって見えるもの」だけを記載します。

必要以上に詳細な「仕様書」は、管理・維持にコストがかかるので、チームの現状に沿った最小限の内容にします。小さなチームの場合、仕様書をあえて作成しない手段もあり得ますが、コミュニケーションの問題を起こさないためには、チーム内外で他の手段によって十分共通認識が担保されており、かつ仕様の決定権が開発チームに任せられていることが重要です。

STEP.3 ビジュアルコンセプト

ビジュアルコンセプトを制作する

導線設計・画面設計は建築に例えた場合、基礎部分から、鉄骨、壁、間取までの設計にあたる部分です。壁紙であるとか、ドアノブの形状にあたるような、ロゴデザインやカラーリング、フォントなどの「表面的な意匠」の部分についても、同様に進行させる必要があります。ここでは、ターゲットユーザーにいかにリーチさせるか、また長いスパンで気に入ってもらえるものにできるか、ブランドとして信頼感を損ねないか、などをポイントに、ビジュアルコンセプトの幅をもたせて複数案作成していきます。ターゲットについてきちんと捉えた上で、ポジショニングマッピングなどを使って、特徴を分散させるように複数案を考案します。

具体的な内容としてはここまでの流れで仕様を固めてきた主要な画面数枚にビジュアルコンセプトから作成した意匠を当てはめたもの、よりシンボリックに「空気」を伝えるアプリのロゴなどのクリエイティブです。

また、ビジュアルコンセプト案に対して、ターゲットユーザーに近い属性の人物の感覚的な評価を集めておくことは非常に有用です。20代向けであれば20代の人に、ゲームユーザー向けであれば、普段ゲームをやる人に。身近な人に見せて反応を記録しましょう。それによって内容を修正するケースも多いでしょう。

表面的であることとは「重要でない」ことを意味しません。ユーザーの視線に触れるものは常に「表面」です。

ビジュアルコンセプトを展開させる

開発チームとプロダクトオーナーへビジュアルコンセプトを提案します。プレゼンテーションでは、コンセプトだけでなくそこに至った論理を示すことが重要です。とってつけたようなリクツは必要ありませんが、論理の経路を示すことができなければ、提案を受けた側からみた場合、通常は「デザイナーが直感・感性でデザインを行った」という解釈しかできません。

反面、「論理を示すことが重要」どころか、更なる混乱を生むケースもあります。結果のビジュアルだけをシンプルに提示したほうがよい場合もあるので状況に合わせて提案内容を準備しましょう。

STEP.4 UIデザイン

ここまでの過程で作成した導線・画面の構成案と、ビジュアルコンセプトを基に、実際のデザインを進めていきます。

デザインガイドラインを整備する

デザインを構成する要素を分割して、「レイアウト」「色」や「部品」などの項目ごとに詳細な仕様を定めたガイドラインを制作します。あらかじめ全ての要素に関してガイドラインを作成するよりも、最初は空でもよいのでカテゴリーごとに枠を準備して、画面デザインを進めて行く際に、共通化できる部分を追加していくようにすると効率良く作業を進められます。「部品」のパターンの洗い出しは対象になるOSに左右されるので、アプリケーションエンジニアとの密な連携が必要です。例えば、以下のような単位でまとめていきます。

• カラースキーム
• レイアウトの単位・グリッドのルール
• アイコン
• UI部品

詳細な色や形状はビジュアルコンセプトの確定を待つ必要がありますが、「設計」の段階で、カテゴライズした「枠」だけでも準備すると、アプリケーションエンジニアとの共通言語として機能するので、早い段階でコミュニケーションをスムーズにしていくことができます。

画面ごとのデザインを行う

デザインガイドラインの執筆と同時進行でワイアフレームを基に、実際にユーザーの目に触れる画面ごとのデザインを起こしていきます。その際、写真や文章などの「コンテンツ」の部分に関しては、できるだけアプリがリリースされた後のリアルな状態を想定して進めることが重要です。

また、この段階では「横幅に収まらない文字をどう処理するか」、「画面間の移動はどのように行われるか」など、ワイアフレームのレベルよりもさらに詳細な仕様が盛り込まれることになります。必要があれば仕様書に追記していきます。繰り返しになりますが、仕様書も内容が過剰にならないように読みやすく作成しましょう。

制作と評価のサイクル

完成した画面はProttなどのプロトタイピングツールで実機による確認を都度行うようにします。「設計」の段階ではないため、今回は主に「ディティール」を評価していくことになります。

また、この段階では、より確度の高いユーザーテストを行うことができます。そのためには、「リアル」なコンテンツ（文字、写真など）をレイアウトしておくことが重要です。

最小限のユーザー体験

開発は時間・コストとの戦いなので、「実装上安い」手段が常に選択されがちです。デザイナーは、エンジニアにヒアリングを行い、常に「実装上安い」方法はなにかを把握する必要がありますが、「実装上安い」手段を常に選択していくと「アプリ全体の体験・デザインの統合性」や「ここちよさ」が損なわれる場合もあります。これはユーザーテストなどでも明確には計りづらい質的な評価ポイントであり、デザイナーが主体的にコントロールすべきポイントです。「最小限のユーザー体験」のラインはどこか。どこまでは妥協できるのか。常に考え、開発メンバーと認識を共有していきましょう。

※ 参考: デザインの統合性 > Design Unity
※ 参考: Minimum Lovable Product

STEP.5 実装

アセット画像を準備する

「アセット画像」とはアプリ内で使用するアイコンやイラストレーションなどの画像ファイルのことです。pngやpdfの形式でアプリケーションエンジニアに渡します。画像の名称や、サイズのバリエーションについて事前に打ち合わせておくと、混乱なく受け渡しを行うことができます。

Sketch3を使用する場合は、必要なサイズことに整理して書き出しを行う仕組みを簡単に準備することができます。このファイルは、gitなどで、バージョン管理しておくとのちに変更が生じた場合もスムースにやり取りができます。PSDやSketch3からの切り出し作業をアプリケーションエンジニアに依頼する方法は、制作の終盤でもっとも負荷が高いアプリケーションエンジニアの作業コストが上がってしまいますので、おすすめしません。

レイアウト指示書を作成する

デザイン案からアプリケーションエンジニアが実際の画面を組み込む際に、参考にするためのドキュメントです。

Sketch3のMeasureプラグインを使用すれば、Spec Exportという機能で、パーツ間の間隔、サイズ、色の指定を参照できるレイアウト指示書を自動的に書き出すことができます。ただしこの機能は、誤解を生まないために1ポイント単位で正確にレイアウトしなければならないという点や、その場では必要ない情報まで一律に出力してしまう点などで問題があります。

実際にはアプリケーションエンジニアの状況に合わせて、レイアウト上に指示を書いていく方法と併用するのがおすすめです。指示した内容が実装上、不釣り合いにコストが高かったりしないか。分かりにくい点はないかなど、密に確認して、場合によってはUIデザインまで戻って書き直していきます。

STEP.6 品質チェック

デザインチェック

画面・機能単位で実装が進んでいく段階です。画面ごとに作業が完了した部分についてデザインが正しく実装されているか、実際のアプリを手に確認していきます。さきほどの「レイアウト指示書」と突き合わせることになります。キャプチャを取って、さらに修正な箇所をマーキングしていくことになるので、Mac上で、動くiOS SimulatorやAndroidではGenymotionなどのエミュレーターを併用します。

ここで、エミュレーターだけに頼ってしまうと、「ボタンが指で隠れること」や、「スワイプアクションのスピード」などの、実機でしか体験できないポイントを見逃してしまいます。バグレベルのユーザビリティー上の問題点が発生するケースもあるので、必ず実機でも確認するようにしましょう。

ユーザビリティーテスト

実機をユーザー役の人物に操作してもらい、その様子を観察・記録し、使用上の問題点を洗い出すユーザビリティーテストを行います。一般的な説明は、ここでは行いませんが、ユーザビリティーを検証することが目的の場合は、古くから一般的に5人の被験者がいれば、問題の80%を発見できるとされています。

主に開発側はUIやインタラクション上の問題点を見つけようとテストを設計しますが、実際の被験者は当然のことながら、かなり「コンテンツ」の内容に影響を受けます。お皿より料理を見るのです。「ECサイトで欲しいものを買う」というような、多くの人がユーザーになり得るシンプルなテストケースの場合は、比較的検証は容易ですが、ニッチな内容の場合は被験者のリクルーティングとコンテンツの準備段階の難易度・コストは上がっていきます。この問題を意識して、ケース毎にポイントを絞ってテストを設計すると、より意味のあるテストが行えるのではないかと思います。

このような困難さはありますが「開発メンバーでユーザーがアプリを実際に操作している状況を観察して、改善点を検討する。」という一連の体験は、他に代え難い、言語化できない共通認識のベースになります。

また、たとえたった一人の平均値・基準値から遠いユーザーを対象に行ったテストであったとしても、そこには「生きた体験」があります。長い開発の期間の中で、開発メンバーが「生きた利用者」がいる感覚を持った上で開発を進められることはとても重要だと考えます。

なお、紹介の順番としては最後になってしまいましたが、ユーザビリティーテストは、「完成品」に対してだけでなく、初期のワイアフレームの段階から、コストの許す限り、様々な精度で行っていくとよいでしょう。このことによって、UI・アプリといった「モノを作る」という意識から、生きたユーザーが体験する「コトを作る」という意識へ、デザイナーを含めた開発メンバー全員の視点の転換が行えるからです。

また、ユーザビリティーテストは必ずしもモニタールームなどの設備が整ったラボで行う必要はありません。

参考：5ユーザーでテストすれば十分な理由

品質保証

リリースの前に、専門のチームや企業によって、主に「問題点・バグを発見する」ために行われる品質保証ですが、方法次第では、「デザインチェック」を依頼することも可能です。ただしそのためには「デザインガイドライン」「レイアウト指示書」などのドキュメントの準備が必須です。

STEP.7 運用

改善サイクル

アプリのリリースが終わり、運用に入ってからもデザインタスクは継続します。
開発チームはビジネス上の目標に向かって、得られたユーザーのデータから改善を行うサイクルを廻していきます。デザインサイドでは、主に実際のユーザーの情報をキャッチして、ユーザー体験の改善を行っていきます。

量的データ・質的データ

運用フェーズにおいて、アプリ・サービスのビジネスとしての状況は、数字的に計測されていることと思います。（KGI/KPIとして表される巨視的な数値です。）

例えば、継続利用するユーザーを増やすため多くのユーザーに、ある機能を使ってもらいたいというシチュエーションで、なんらかの原因で利用率が低いことが巨視的な数値からわかっているとします。この場合、より具合的に問題の原因を探していくためには、量的データ・質的データの両面を探っていくことが有効です。

量的データ

特に、デザイナーは、導線やUIを改善するためにより詳しくユーザーの動向を知る必要があります。そこで、Google Analytics などのツールを使い、アプリ内の各画面やアクションに「イベント」を設置して、より微細な数値を集計する必要があります。
これは量的データの一例です。

質的データ

この段階で、再び「ユーザーテスト」を行い、被験者の行動を観察するという方法も有効です。すでにサービスを開始しているので、「本当のユーザー」に使ってもらうことが可能です。自宅で待機しているユーザーに対して「リモートテスト」を行うことができれば、「本物の環境で、本物のユーザー」が行う行動を参考にすることができます。これは質的アプローチの一例です。

次のサイクルへ

新たなユーザーのデータを元に、「STEP.1 企画」から再び改善のための開発がはじまります。「サービス・アプリのデザイン」は、「作ったら終わり」ではありません。「生きたデータ」が得られるようになる運用フェーズの開始が本当の始まりです。

まとめ

以上の7ステップは、キレイに順番通り進行可能なものではありません。常に重複しており、画面・機能単位でパラレルに進行します。時にはユーザーテストなどの評価を経て、かなり以前のステップに戻らなければならないこともあります。

そういった意味で今回のまとめ方は少し乱暴なのですが、少しでもイメージしやすいように簡単に図にしてみした。色の濃い部分ほど、デザイナー寄りのステップになっています。ひとつの例にすぎませんが、参考にしていただけると幸いです。

編集部オススメ

多様化する世界だからこそペルソナを作る

こんにちは、ケチーノです。 普段は、ニコニコ生放送のデザインに携わりつつ、ドワンゴでの新しいデザイン制作の枠組みの推進を行っています。 先日、社内のデザインを評価する会で、こんな一幕がありました。 A...

2016.04.05