【UX定義〜UI設計まで】アプリ開発にデザイナーとして関わって学んだこと

以前、新規アプリ開発（iOS、Android）の案件に、デザイナーとして携わった際に学んだことや、実際のプロセスなどを自分用の備忘録として、この記事にまとめてみました。

その中で抑えて置きたいポイントや、勉強になった考え方や記事（書籍）などを大まかな開発のフローに沿って紹介したいと思います。

もっと勉強できていれば良かった・・！と感じた部分をメインにまとめていますので（反復学習の意味も込めて）、アプリ開発の案件にこれからはじめて関わる方などへ参考になれば幸いです。

今回はUXの定義から開発のデザイン部分まで関わっているのですが、私が主に担当した「UI設計」と「デザイン」の2つについては、その中でも特に共有したいトピックスに分けて紹介したいと思います。
「サービスのUX定義」「アジャイル開発」に関しては、今回の案件のプロセスを要点のみまとめていますので、技術的な面の話しではなく概要的なお話になります。
飛ばしたい方は、目次から飛ばしてお読みいただければと思います。

1.サービスのUX定義

UX（ユーザーエクスペリエンス）の定義をどのように行ったのか、今回のアプリで実施されたプロセスを紹介します。
プロセスについては、「UXにおける5段階モデル」という考え方がわかりやすかったため紐付けてお話したいと思います。

UXにおける5段階モデルとは
UXの5段階モデルとは、Jesse James Garrett 氏が考案した概念であり、氏の著書「Elements of User Experience」において具体的に解説されています。

UXの5段階モデルについては、Goodpatchさんの「UXデザインにおける5段階モデルとは？」一連記事がとてもわかり易く参考になりました。
記事の内容を引用して説明させていただきたいと思います。

引用：https://goodpatch.com/blog/elements-of-ux/

上の図から、下部2つの「戦略」と「要件」の部分が、UXを考える上での大本に当たる部分ではないかと思います。

今回の案件でも、
【戦略】では、まずは「サービス/プロダクトビジョン」「ビジネスモデル」「ペルソナモデル」などを共有いただき、どのようなサービスを目指し、どのようなビジネスを考えているのか、プロジェクトチームでインプットしました。

【要件】では、戦略で共有いただいた情報を元に、ストーリーボードの作成、ユーザージャーニーマップの作成を行い、ユーザーが体験するストーリーから、プロダクトに必要な機能仕様や要件などを設計しました。

・ストーリーボードの作成とレビュー
・ユーザージャーニーマップの作成とレビュー
　→それを元にしたユーザータイプにあわせたHOME画面の提案とレビュー

上記を繰り返し行い、合わせて、サービスにおけるアプリの体験価値を一言に言語化したステートメントを設定しました。
それにより、判断基準の指標（ものさし）ができ、またプロジェクトメンバー全員で共通認識を持つことができます。

また、今回開発したアプリは、ハードウェアと連携して使う前提のものだったため、ハードウェアのPR戦略によって、アプリのジャーニーマップの体験も変わってしまうため、想定できない部分が多くアプリ単体だけでの体験を想像しにくい点が難しかったです。

そのため、PR戦略の方も交えて、UXの体験価値を定義するのに時間を要しました。この部分だけにおよそ密度の濃い1ヶ月がかかりました。

上記のUXの定義を進める上で、下記の書籍をがとても参考になりました。

マッピングエクスペリエンス ―カスタマージャーニー、サービスブループリント、その他ダイアグラムから価値を創る

デザインスプリント ―プロダクトを成功に導く短期集中実践ガイド

2.アジャイル開発／スクラム

今回の案件では、開発はアジャイル開発（＋スクラム）を行いました。
まず、「ウォーターフォールモデル」「アジャイル開発」という言葉をご存知でしょうか？
これらは、システム開発における有名な手法の名称です。

ウォーターフォールモデルとは？

上流工程から下流工程へ順次移行していく開発手法で、水が下に落ちていく様を模した名前となっています。
「要件定義、外部設計（概要設計）、内部設計（詳細設計）、開発（プログラミング）、テスト、運用」を各工程を順番に完了していくのがウォーターフォールモデルの特徴です。
Webサイトの制作などはこの手法が多いと思います。

アジャイル開発とは

引用：https://backlog.com/ja/blog/what-is-agile-and-waterfall/

その言葉のとおり、アジャイル開発ではイテレーションと呼ばれる1〜4週間程度の期間内で一つの機能を開発・リリースしていきます。イテレーションの期間は開発チームによって設定が変わります。

イメージとしては1つの機能に対してイテレーション期間内にウォーターフォールモデルであげた各工程を実施していく感じになります。

アジャイル開発のメリット
・動くものを早い段階で触ることができる
・要求が変更になったときに応えやすい（柔軟性が高い）
・無駄な機能を開発するリスクが低い

アジャイル開発デメリット
・全体像を把握しにくく、スケジュール管理が難しい
・各月での成果物が不明瞭
・アジャイル開発に精通している人が必要

──次に、スクラムについて説明します。

スクラムとは？

アジャイル型開発手法の1つです。『スクラム』開発の語源は、ラグビー等スポーツの『スクラム』から来ています。
この開発技法は、アジャイル型開発技法の中でも顧客も巻き込んでチーム一体となってプロジェクトを遂行して行くことに重点を置いている、という特徴があります。

スクラムでは、チーム一体となって活動するために、以下の様なプロセスが定義されています。

・デイリースクラム（朝会）
・リリースプランニング（プロダクトバックログ）
・スプリントプランニング（スプリントバックログ）
・スプリント（イテレーション開発）
・スプリントレビュー（デモ）
・ふりかえり

特にふりかえりは、基本的に毎スプリント終了時に行い、KPT法などが用いられます。今回のスプリントの良かったこと、問題点、挑戦したいことをメンバー全員で出し合い、次のスプリントでさらにチームメンバーが高い価値を生み出せるように、メンバー同士話し合いを行い、確認しあいます。

今回初めて取り組んだのですが、問題点が肥大することなく最小で進められることにもメリットを感じました。

引用文献
・「ウォーターフォールモデル」「アジャイル開発」って何？二大開発手法のメリット・デメリットをまとめました

・アジャイル開発とウォーターフォール開発の違いは何？アジャイル開発の手法や意味も要チェック

・アジャイル開発～顧客を巻き込みチーム一丸となってプロジェクトを推進する～ （前編）

アジャイル開発／スクラムを
実際やってみて良かった面・ツラかった面

よかった点
・無駄になる作業が少ない。
・開発ベースでスケジュールが進むため、スプリント内のタスクは明確化される。
・短期的に目標を持って取り組み・振り返ることができるので、課題がうやむやなままだらだらと可視化されず進むことがない。

ツラい点
・チーム全員の集中力を要する。1日の遅れにインパクトがある。
・アジャイル開発に精通している・スクラムマスターの力量が必要。
・ワイヤー設計、デザイン、実装が一緒に進んでいくため、仕様や要件の詳細が決まっていない部分が多く、初期段階でアプリの全体像を把握しづらい。
・ある程度の画面数を制作してからベースとなるデザインルールを設計することが難しいため、先を見越してコンポーネントを設定しつつデザインする必要がある。

フローとしては個人的にシステム開発的に合理的でよい印象があるのですが、全貌が見えない中で全体のデザインのルールを考えながら進めていくのは経験値がないとツライな、、というのは実感しました。
今回紹介した手法はあくまで一例のため、興味がある方はいろいろと調べてみてください。

3.要件定義・UI設計

さてさて、ここまでですでに大分長くなり恐縮ですが…
ここからが本題です！

要件定義・UI設計に関して、特に設計に関わる部分で抑えておきたいポインや、勉強になった考え方や記事などをピックアップして紹介したいと思います。

3-1.iOSとAndroidのデザインガイドラインの違い

iOSとAndroidでは、デザインガイドラインが大きく違います。iOS「HumanInterfaceGuideline」、Android「Material Design」が有名ですね。

各OS上で、アプリをストレスなくユーザーに使ってもらうためには、各OSの出しているガイドラインを無視することはできません。
各ガイドラインに則ることで、「操作性の一貫性」「ユーザビリティ担保」ができることからユーザーにとっても使いやすいものを提供できますし、　開発者の負荷を下げることもできます。

そのため、iOSとAndroidの標準機能を使わずに実装する場合、各OSのガイドラインを考慮した設計・デザインが求められます。

HumanInterfaceGuidelineとMaterial Designの違いについては、下記の記事でわかりやすく説明させています。
ガイドラインの違いについてや、日本と世界のマーケットシェア変動など、頭に入れておく必要があります。

今回開発したアプリはデザインに関してはiOSがメインで、Androidは基本エンジニアさんに任せて実装いただくような流れでした。
また、標準機能を使用する部分は、ガイドラインで定められている名称で会話・データを作成することで、開発者とも共通言語で話すことができ負担を下げることができます。

参考文献：
iOS／MATERIAL DESIGN 比較
・独学でUIデザインはじめた方へ。デザインガイドラインについて語ろう！｜ゆい｜note
・これからAndroidアプリをつくるデザイナーのための基礎知識
・【デザイナー向け】これからAndroidのデザインをする人へ

iOS／HumanInterfaceGuideline
・iOS Human Interface　Guideline
・iOS ヒューマンインターフェースの原則
・ヒューマンインターフェースガイドラインをニホンゴで解説！iOS Apple15の原則
・iOSの標準UIについて勉強会を行いました
・iPhone/iPad/Apple Watch解像度(画面サイズ)早見表

Android／Material Design
・Material Designの設計思想を探る
・【翻訳してみた】マテリアルデザイン - モーションデザインを理解すること

3-2.モーダル／モードレスという考え方

モーダル、モードレスという考え方をご存知でしょうか？
モーダルと聞くとUIのモーダルを思い浮かべてしまっていた私ですが、根本の考え方について紹介します。

モーダル
モードがある状態。つまり、システムが特定の機能の使用に制限された状態。
ユーザーが自由に操作を行えなくなることと、モード別に機能の意味や振る舞いが変化することから、ユーザーインターフェースのデザインでは、できる限りモードを設けないほうがよいとされる。

モードレス
モードがない状態。
ユーザーインターフェースをデザインする際に目指すべき状態。状況に依存した機能制限がなく、自由な手順でタスクを進行することができ、かつ特定の操作がシステムによって常に一定に解釈される状態。

引用：モーダルとモードレス

ツイッターの画面に例えると、HOME画面はモードレス、投稿画面はモーダルという区別になります。

UIのデザインでは、ユーザーが自由に操作を行えなくなることと、モード別に機能の意味や振る舞いが変化することから、基本的にモードレスであることがよい、とされています。一方モーダルは、会員登録等などそれ以外の操作が行えることがユーザーの操作を妨げる場合等に適しています。

また、モーダルなGUIは「タスク指向のUI」であり、モーダレスは「オブジェクト指向のUI」であるそうです。

下記記事では、モードレスとモーダルの考え方の比較がわかりやすく説明されています。非常に面白いので興味のある方はぜひ。

また、モーダル、モードレスの間をとるような存在もiOSには存在します。
現在のiOS標準のモーダルビューは、フルスクリーンでない場合は下に引き下ろすことで閉じることができるため、半モーダルビューとして、モーダレスの余地を残している様に感じます。

半モーダルビューのメリット
フルスクリーン型モーダルビューではモードを終了しないとそこから脱出することができませんが、半モーダルビューではモードを終了させずとも一時的にそこから退避することができるようになります。

少し古い記事になりますが、下記記事がとてもわかりやく解説されれています。勉強になるのでぜひ。

参考文献
・モードレスデザイン
・iOSにおける半モーダルビューの解釈

3-3.UI Stack

UIスタックという考え方をご存知でしょうか？
アメリカのプロダクトデザイナー Scott Hurff さんが5年ほど前に世に出した考え方で、UI の考慮すべき5つの側面を示したものです。

引用：How to fix a bad user interface

原文の記事では、「UI の考慮すべき5つの側面」を下記のように示しています。

・Blank State（空っぽの状態）
・Loading State（ローディング状態）
・Partial State（部分達成状態）
・Error State（エラー状態）
・Ideal State（理想状態）

この5つを分けて考えることで、UIの考慮漏れが起きにくくなり、それぞれの側面（状態）について最適なユーザー体験を考えることができます。

詳しくは下記記事に書いてあります。アプリに関わらずwebのUIでも使える考え方なので、一読いただけると、エンジニアさんにもやさしいデザイナーになれると思います。

3-4.他細かいUIの考え方で参考になった文献

上記でご紹介した内容以外に、参考になったUIの考え方の記事を下記にまとめました。実際に役に立ったものをまとめているので、興味のある方は参考にしてみてください。

UIに関する参考文献
・UIをデザインする前の心得
・テキストだけのボタンは、なぜスマホでのユーザビリティを損なうのか
・キャンセルボタンに色をつけてはいけない理由

3-5.アプリの導入画面の手法

アプリの画面設計をする上で、必ず必要な導入画面の手法や名称について、ご存知でしょうか。

「スプラッシュ」「ウォークスルー」「オンボーディング」「コーチマーク」などの手法があります。参考事例などをまとめている記事を幾つかピックアップしたのでご紹介します。記事が長くなりすぎているので、詳しくは書きませんが、興味のある方は見てみてください。

アプリの導入画面参考文献
・UIデザイナー必見！ アプリの導入画面で使われる主な４つの手法
・スマホアプリの効果的なオンボーディング 参考になるサインアップ画面の海外事例を画像付きで紹介
・定番パターンだけじゃない！サービスに最適化されたUser Onboarding
・アプリのウォークスルーを観察してまとめてみた
・アプリのコーチマークの観察
・新規UI登録まとめてみた

4.デザイン

やっとデザインまできました・・！
思っていたよりも記事が長くなってしまい、恐縮です。

デザインでは、「ダークモード」「アトミックデザイン／コンポーネント管理」について紹介させていただきます。

4-1.ダークモードの色彩設計

iOS 13 からOSレベルで搭載されたDarkMode設定ですが、普段好んで使われている方も多いと思います。ダークモードには「目が疲れない」「バッテリーの節約にもなる」といったメリットがあり、Appleが推奨している機能の一つでもあります。

今回ダークモード対応する上で、iOSのDarkMode Colorの設計をまず参考にしました。

Color - Visual Design - iOS - Human Interface Guidelines - Apple Developer

iOSでのダークモードの実装は一つの色に対して、LightModeとDarkModeのそれぞれの場合の色を定義するようなイメージで作られています。

例えばTextColorという色があったとしてLightModeではRGB: 51, 51, 51、DarkModeではRGB: 204, 204, 204というようにそれぞれの色を定義するような感じです。

また、色のコントラストや、明度を利用した視覚効果を考慮したカラー設計を行う必要があります。
ダークモードの持つメリットの「目が疲れない」という点は、色のコントラストに配慮しなくてなりません。
真っ黒（RGB: 0, 0, 0）や真っ白（RGB: 255, 255, 255）は、コントラストが強くなりすぎてしまい、目を疲れさせてしまうため、グレーの濃淡を使って見極めながら設計を行うことが大切です。

また、MaterialDesignに通じる点もあるのですが、手前にあるUIエレメントほど明るくするルールに則ることで、エレメントの重なりが視覚的にもわかりやくすることができます。

こちらの記事がとてもわかりやすく、詳しくか書かれているため、参考になりました。

DarkModeのデザインを中心とした色彩設計の考え方 - くらげだらけ

また、背景やテキストの明度を下げた際に、ボタンなどの他の配色が明るすぎるように感じてしまう場合があります。その場合はボタンカラーの濃淡を濃くするなど、ダークモードの配色と調和する様に調整する必要があります。
ダークテーマでより適切に機能するように、それらのカラーも調整しましょう。

こちらの記事もデークモードのデザインをする際に気をるけることを具体的に詳しく書かれており、とても参考になりました。

UXデザイナーに学ぶ、ダークテーマをデザインする時に気をつけたい5つのポイント

参考文献：
・Human Interface Guidelines　Color
・DarkModeのデザインを中心とした色彩設計の考え方
・アルのiOSアプリをダークモード対応したときの知見
・UXデザイナーに学ぶ、ダークテーマをデザインする時に気をつけたい5つのポイント

4-2.アトミックデザイン

アトミックデザイン（atomic design）をみなさんご存知でしょうか？

アトミックデザインはアメリカのWebデザイナーBrad Frost氏が考案・提唱したデザインシステムです。画面要素を5段階に分けて、これらの要素を組み合わせることによって、最終的に画面のUIが作られます。

Atomic Design Methodology | Atomic Design by Brad Frost

パーツの最小単位から「原子」(Lv1)からデザインしていき、「分子」(Lv2)、「生体」(Lv3)、「テンプレート」(Lv4)、「ページ」(Lv5)の順にデザインを進めていく手法になります。

引用：Atomic Design を分かったつもりになる

アトミックデザインでは、各コンポーネントが簡単に再利用、編集、統合できるため、プロダクトの拡充が容易に行えます。したがって、個人や少人数で行う小さなプロジェクトから、大規模のウェブプロジェクトまでさまざまな規模・レベルのプロジェクトで用いることができます。

今回はアトミックデザインでコンポーネント管理しながらデザインデータを作成していきました。
普段のデザイン手法で画面全体を作成した後、パーツに分解・共通化して行き、原子を定義するように進めました。
完全にアトミックデザインのフレームワークに則ることは難しかったのですが、原子レベルの分解・共通化を考えて進めることで、パーツ単位での考慮の抜け漏れなどは防げたと思います。

また、パーツを設定する際に、デバイスごとに流動的に可変するデータの作り方にも配慮しました。
XDやsketchなどで、各コンポーネントの動作に対して様々なレスポンスをテストし、パーツをどのように固定するか設定し、より汎用性が高く、エンジニアさんにもわかりやすいデータを作るように心がけています。

引用：アトミックデザインとは？ コンポーネント単位で創るUIデザイン手法

アトミックデザインに関して下記記事を引用・参考させていたきました。

参考文献
・アトミックデザインとは？ コンポーネント単位で創るUIデザイン手法
・Atomic Design を分かったつもりになる

5.まとめ

今までアプリ案件に、デザイン面だけで局所的に関わる機会はあったものの、UXの定義〜設計、開発まで通して関わることが初めてだったので、設計する上での思慮しなければならない範囲の広さを実感することができました。

デザイナーは表面のスタイリングだけできればいいという話ではなく、サービスのビジネス的視点・体験価値を理解した上で、設計の視点を持たずに「デザイン」できることがない、と痛感しました。

それはなんのデザインであっても同様だと思いますが、よりユーザーが使うことを考える想像力と、ベストな最適な解を実現するための、さまざまな知識を身につけていくことが必要だと改めて感じました。

これからアプリ開発の案件に、はじめて関わるんだよな‥という方に、少しでも参考になれば幸いです。

非常に長くなりましたが、最後までお読みくださりありがとうございました！