企画を元にゲームのUIを作るときの流れ
「Game Graphic Design Advent Calendar 2019」の初日の記事です。
ゲーム制作に関する素敵な記事がたくさん公開されると思いますので、私自身もワクワクしてます。
言い出しっぺとして、初日としてまず何を書こうかなと思ってたんですが、以前Twitterでチラッとつぶやいた「普段ゲームUIを作るときってどういう工程があって、どういう流れで作っているか」をまとめてみたいと思います。
というのも、いろいろな方から「何から手を付けていいのか…」「デザインが上手くまとまらない」「デザイナーが社内外注みたいになってしまって…」みたいな話をよく聞きまして。
そのアンサーになるかは分かりませんが、自分の場合はこういうフローで、こういうことを意識してますよ。というのを書いてみたいと思います。
もちろん組織や人によってやり方は様々だと思いますので、こんな風にやってる人もいるんだ、ぐらいに読んでもらえればと思います（予防線…。笑）
※比較的マクロなフローの話です（各フェーズの詳細はまたいずれ…）
※小規模〜中規模な組織向けかなと思います。
UI設計の構造
まず大きく分けて３つの工程に分けて考えます。
1. 画面と構造の設計
2. トンマナ／ビジュアル設計
3. ブラッシュアップ／ガイドライン化／実装方法の相談
（本当はもっと細々と分けてますが、今回はざっくり３つにします）
個人的な経験では、アート出身の方やサービス系出身の方で 「ゲームのUIの進め方がわからない」 となる人が多いのは、この３つの工程を混ぜて行おうとしている事が多いです。
情報設計とビジュアル設計を混在させていきなり具体的な画面を作り始めてしまうことで、どちらも中途半端なまま進んでしまう…みたいなケースが多いように思います。
時間が無いときや数人で行うような小さなプロダクトの場合は、複数のセクションを一気通貫で行うことは出来ますし、経験を重ねていくと、その方が効率的に面白いものが出来る可能性もあります。
ただ、そうでない場合は工程を分けて考えた方が捗ると思います。
では順を追って流れを説明します。
【0】 ゲーム体験（コンセプト）の理解
さて少し上の方で「３つです」と言いましたね？
嘘です。
いや、すいません、嘘じゃないです。UIデザインの工程は大きく３つです。でも、その前にやることがありますよね？
それは、ゲーム体験（コンセプト）の理解 です。
このゲームはどういうゲームで、どんな体験をさせたいのか、そのためにどんなゲームにしたいと思っているのか をきちんと理解する必要があります。
チームでプロダクトを作っていく上では必須です。
ここをしないまま仕様書やプランナーからの指示だけを元に「さあUI作るぞー」となっても絶対に上手くいきません。
---
では企画理解のために何をするのか？
まずは企画書を読み込みましょう。全部書いてあります。（当然）
・・・でも企画書って結構フワッとしたことしか書いてなかったり、
逆にたくさん色々書いてあるんだけど、それ故に企画の軸が掴めなかったりしますよね？（凄い細かな育成システムが書いてあるけど、この企画何が大事なの！？みたいなこと、ありません？）
なのでこの「どういう体験をさせたいのか」を理解するためには、チーム内の他の職種の人たちと話しましょう。
• プロジェクトリーダー（DなのかPなのか別なのかは組織による）
• メインプランナー
• コンテンツプランナー
• （プロジェクトよってはアートディレクター的な人）
ただしそこで「さあ答えを教えていただこうか」という姿勢だと、うまくいかないです。話を聴いても、おそらく人によって思っていることや言葉にちょっとずつズレがあります。
それぞれの立場から「なんとなくこういうゲームにしたい」というビジョンはありながら、言語化できていない状態。
プロジェクトの初期にありがちです。というか、プロジェクトによっては中終盤でもこんな感じのことが往々にしてあります。
まずはヒアリングを通し、ユーザーに伝えたいゲーム体験を整理して、デザイナー自身が理解しましょう。
例えば上記の例だと、
「作品世界の中に生き生きと存在するキャラたちを一歩引いた目線で眺めながら、指揮官として指示をだし、チームとして一緒に成長していく体験」が大事とかになるかもしれません。（あくまで例です）
そのためには、
「キャライラストの絵柄をリアル系で揃えて、実在感をあげよう」とか、「キャラ連携のために、指揮官の能力を上げるフローゲーム設計をしたい」とか言葉を具体的なものに整理していくのが大事です。
ここが言語化でき、理解し、チーム全体の意識の共有が出来るとUI設計は２５％ぐらい完成です。
---
Q.それってUIデザイナーがやることなの？
A.うーん、まあ別にUIデザイナーがやらなくても良いですよ（＾＾；）
ここが最初の段階でハッキリしてる（プロジェクトリーダーが言語化し明言しているなど）とめちゃめちゃ楽です。
それを聴くだけで理解できる状態ならもう最高です。そんなプロジェクトに入ったあなた、ラッキーです。業界的にもレアケース。
ただ多くの場合は「抽象的な言葉を束ねた、それぞれの立場からの言葉」になってますので、デザイナーとして自分の言葉で理解する工程が大事です。
あと、個人的には色んな職種の言葉を翻訳して手を繋がせ合うのもデザイナーの仕事だと思ってて、この部分が 「UXデザイン」（体験設計）と呼ばれる領域の最初の一歩 と認識しています。
（理想はデザイナーもちゃんと企画の段階から入っておくと、ヒアリングの手間が少なくて楽です）
まあ、それ以前に「企画がボンヤリしている」みたいなケースも往々にしてあって、その場合はチームで議論を重ねたり、企画者が企画を練りまくる必要があるとは思いますが、そこまで来るともはやデザイナーがどうこうとかではないので・・・
【１】 画面と構造の設計
ここまで読んでいただきありがとうございます。やっとここから本編です。
既に読むのに疲れた方は一度大きく伸びでもしてください。
さて、では３つのフェーズの最初の１つ目、画面と構造の設計のお話を。
１−１．最初に
あなたも既に読んだであろう企画書を元に、プランナーかディレクターあたりがゲームのサイクルや仕様を色々考えていると思います。（企画書よりもう少しブレイクダウンされたやつですね）
なので一度それらの資料も読み込んでから、一緒にユーザーの行動を話し、機能を整理し、遷移を考えていきましょう。
場合によってはコンテンツプランナーも一緒に話すと良いと思います。
（勿論他のメンバーがいても大丈夫です。最低限これくらいで出来るよという感じ）
この時は、プランナーに画面仕様書みたいなのは用意してもらわなくても良いです。
あっても、企画書を元にした超ざっくりとした、話の取っ掛かりになるものであれば良いと思ってます。
（少なくともガチガチに作った画面仕様書と呼ばれるものは思考ロックの原因なので基本的には無いほうが良いかと思います）
というかこの時点でプランナーの方にキレイな画面仕様書を用意してもらう時間がもったいないので。
まずは大まかなゲーム仕様・サイクルを元に、ホワイトボードなり紙なり付箋なりで、全体像／流れの把握を行うのが良いと思います。どうせ細部は変わるので。
理想はこのミーティングまでに資料を読んで、デザイナーの方でUIの雑なイメージを作って持っていけると、会話がしやすいと思います。
ワイヤーフレームにすらなってないやつ。自分は勝手に「雑コラUI」とか呼んでます。会話の取っ掛かりになればいいです。
これをデザイナー自ら「画面とか無視して考えましょう」ぐらいのことを言って、全員の思考をロックしない方向に話を持っていけると良いと思います。（マクドナルド理論に近いやつです）
これはあまりゲーム作りになれてない人が多い現場に有効で、「デザイナーがこんなに雑なのを出してきてるんだから、俺も一緒に考えていって大丈夫だ」と思ってもらえます。
１−２．画面の流れを作る
まず参加する全員が読み込んだ企画／仕様／コアサイクルの資料から、
ユーザーの行動ベースでゲームの流れを作っていきましょう。
「キャラを強化する」「バトルを行う」などの流れを追うイメージです。
ここではまずはゲームの全体の把握ができれば勝ちです。 どういう流れがあって、どれくらいの規模感なのかの把握をするのが大事です。
自分がよくやる具体的な順序としては、まずゲームを起動した直後にプレイヤーがする行動から考えます。
例えば 「まずはバトルをしたがるよね」 となったら、
「次はどのクエストかを選ぶよね」や「じゃあ最初の画面には『クエスト』への遷移が一番見つけやすいところにある必要があるよね」などと会話ができます。
そういう会話をしながらホワイトボードにガシガシ書いていきましょう。間違ってたら消せばいいので、遠慮なく。
この時、最初に確認した 「ユーザーに体験させたいこと」 に基づいて判断するのが大事です。
そこベースで話すと、「ちょっと画面に表示されるクエスト数は減るけど、世界を冒険させている感覚にさせたいから、ワールドマップ風の画面にしたほうが」といった話もできます。
この時にUIのアニメーションも頭の中で意識できているとベストかと思います。
「あれ？これ情報設計だよね？そんな具体的な画面イメージの話しして良いの？」って思いましたよね。
いいんです、アイデアはどんどん出しましょう。とりあえず体験設計に基づく行動ベースで全貌を形にしていくことが何より大事です。
その先の遷移を考えていくうちに不都合が出たら「やっぱりこっちのほうが」と戻せばいいんです。
体験設計とユーザー行動の認識がプランナーとデザイナーで合っていれば、細部の修正なんて毛ほどの影響もありません。
---
注意点
注意点としては画面ありきで作らないことです。
「まずカード強化画面から〜」とかやっちゃいがちですが、それだと「カード強化は手軽にできるべきなので、画面遷移ではなくカード詳細からアクションシートUIでやろう」みたいな視点が抜けます。
後から「なんでここってモーダルな画面遷移なんですか？オーバーレイじゃだめなんですか？」って聞かれた時に「特に理由はないんですがもう実装までしちゃったので…」はみんなが辛いのでなるべく減らしたいですよね…
---
めっちゃ余談ですが
ラノベ「ブギーポップは笑わない」シリーズの原作あとがきで「２択で迷ってるときはそもそも２択になっている時点で失敗している」というのがあって、思考ロックされないための名言だなと思ってます。
（閑話休題）
---
この「体験と行動に基づいて画面遷移を設計する」をUIデザインの最初の時点でやっておけば、変化に強い製作フローを築けます。
あとから仕様が変わっても、「ユーザーの行動にどう影響するか」が理解しやすく、画面や情報をどう変えていければいいかが判断しやすいからです。
思考ツール
この時に以下を勉強しておくと考えが整理しやすいです。
• デザイン思考、インタラクションデザイン
• オブジェクトベースUI or タスクベースUIの思考
• ユーザージャーニー
• その他各種心理学
※それぞれの説明については長くなるので割愛。個人的におすすめの記事をいくつか貼っておきます。
１−３．具体的な画面の要素を決めていく
そうやって大きな流れを作ったら、具体的に「どのような画面が必要か」「どんな要素／操作で遷移するのか」「どういう情報があると便利か」を考えながら必要な要素を洗い出していきましょう。
この時に一緒に画面内での優先順位をつけたり、インタラクション（操作に対して何がどう変化するのか）まで考えられると良いと思います。
初期からデザイナーがプランナーチームのメンバーも兼ねて、企画から入るとここが結構早くできます。何の要素が大事かを共有しやすいので。
---
プランナーとデザイナーが一緒に考えるために
• 画面の情報を整理するのはプランナー／デザイナーどちらかの仕事というよりも、認識を揃えるために、最初に一緒にやったほうが良い。
• 仕様の不明点や矛盾も一緒に確認しよう
• まず全体像が把握をしてアプリの規模感をつかもう。
• 複数の画面で共有する要素や、フローの類型化を意識して設計しよう
---
１−４．全体のワイヤーフレームを作る
１−３で確認した全体設計を元に、各画面のワイヤーフレームを作ります。
個人的なオススメはAdobe XDですが、慣れてるものでいいと思います。
大切なのは「実機で遷移が確認できること」なので、ProttでもStudioでもFigmaでも。
このとき、「PCの画面だけで見る」のはダメです。必ず実機で遷移まで確認できる形にしましょう。
この記事でも引用しましたが、自分が（面識も無いのに勝手に）尊敬するの方の名言を貼っておきます。
「これPCの画面だけで設計して、実機確認しなかったでしょう？」というUIデザインを出す人は、目からビームを出して攻撃しますので、よろしくおねがいします。
— TANAKA U ゲーム系フリーランス (@TANAKA_U) July 4, 2014
ビーム出します
各画面に必要な要素と、その優先度が決まっているはずなので、
それを元にまずは素直に配置しましょう。
この時、AppleのHuman Interface GuidelinesやGoogleのMaterial Designを参照したり、既存アプリから市場のデファクトスタンダードを意識しながらやると良いと思います。
まだこの時点では細かいデザインまで意識しなくて大丈夫です。
だいたいの位置やサイズ感が分かって、優先度通りに認識できればOKです
---
ダーティ・プロトタイプを作ろう
１−１で定めた「その画面でさせたいこと」をブラさないように、「何故そのUIが存在するのか」を意識しながらやるとよいかと思います。
特に工業デザインだと「クイック＆ダーティプロトタイプ」などという言い方で、「考えをざっくりと表現するためのプロトタイプ」を作ったりします。
ワイヤーフレームはデッサンにおける「あたり」です。
神経質にやらなくても、実際にヘビーユースしないと見てこない問題もあるので、3割ぐらい「わからないな…」という部分があっても良いと思います。
特にスマホゲーだと、ユーザー体験にとって致命傷にならなければ、後から改修してもいいです。どうせ想像もしない使い方をされたり、運用する中で要素が増えていって改修することになるので…。笑
そこよりも「本当に届けたいユーザー体験がちゃんと作れているか」に神経を注ぎましょう。
そうやって、モックを触りながら随時ブラッシュアップをしていけばOKです。進捗は随時プランナー、エンジニアとも共有をしながらやってきましょう。
---
【２】ビジュアル設計
２−１．ビジュアルイメージの方針を決める
さて、そんな（１）の情報設計をしながら、どこかで並行してビジュアルの設計もはじめましょう。
こちらはアートディレクターと一緒に進めていくことになると思います。
最初に定めた「ゲームの体験」をベースに、「コンテンツとしての魅せ方」を意識して詰めていきます。
アートディレクターがいる場合「このゲームはこういうアート方針で行きたい」というのがあるはずなので、それと「体験させたいこと」を元にトンマナを作っていきましょう。（ゲームによっては自分がADを務めることもあると思いますが、その場合もやることはかわりません。自分の中のアートディレクターと話しましょう）
場合によってはコンテンツプランナー（会社によってはシナリオライターとか、ようは世界観や設定を考えている人）も入ってもらえると良いと思います。
トンマナを作るといってもいきなり具体的なものを出すのは難しいともうので、まずはキーワードから出していくのが良いと思います。
---
例えば 『古代中国の英雄たちが戦う現代高校生バトルロワイヤルゲーム』 みたいな設定があったとすると、
• 登場人物は古代中国の仙人や導師
→ 硬質で石や木などのネイチャーな質感？
• 現代の学園を舞台にした殺伐バトルもの
→ 現代的なクール・モダンかつ、ダークな印象？
キーワードで言うと、
・岩壁
・雲
・紅
・筆文字
・つや消し感
・学校
・制服
…などなど。（マインドマップなどを使うと整理もしやすいと思います）
これらの要素を レイアウト／フォント／色／装飾の要素などに変換していきます。
例えば、
「古代中国っぽさは目立つところに草書体を使用して、アルファベットは現代的なサンセリフにしよう」
「赤系を使うと中国っぽいけど、現代感がなくなるから、ベースはモノトーンで、アクセントに赤系が映える配色にしよう」
「岩肌っぽい印象を、荒廃／殺伐とした世界観をUIで表現できないか」などといった感じです。
それらを元に、ムードボードを作るとイメージが共有しやすいです。
ここで、フォントや色の知識があると役に立ちます。
• フォントの歴史的背景
• 配色によって受ける心理的印象
• 美術史／デザイン史
２−２．実際に画面を作っていこう
【１】で定めたワイヤーフレームをベースに、トンマナを意識しつつ画面を作ってみましょう。
最初は「一番コアとなる画面」と「汎用的な要素が多く、ほどほどにコアに近いところ」から作るとやりやすいです。
例えば前者は「バトル画面」、後者は「ストーリー一覧画面」とか。
（注意しないといけないのは、3Dのキャラやイラストの力に頼りすぎた画面づくりをしてしまって、後々「汎用性がない…」「キャラが居ないと全然イメージと違う…」とならないように気をつけましょう）
先程も書いたように、ワイヤーフレームはデッサンで言う「あたり」なので、そこまで強く意識せずにグラフィックを作ると良いと思います。
ワイヤーで確実に意識したほうが良いのは２つです。
• ユーザー体験に基づく行動フロー（その画面で何をさせたいのか）
• 要素の優先順位
先に出したキーワードやムードボードなども見つつ、楽しくデザインしていきましょう。
「とはいえ何から始めれば…」というかた、とりあえずボタンから作ってみてはどうでしょうか？
ムードボードなどを使って言語化したトンマナを元に考えるとデザインがしやすいと思います。
---
ゲームのUIを作っている！という意識を常に持つ
「ツール」ではなく「娯楽のデザイン」をしていることを意識するの大事です。有名な任天堂のUI Cruchの発表でもありましたが、「娯楽脳」と「UI脳」を行き来しながら作るのが大事だと思います。
「UI脳のみだとアイディアが制限される」
「娯楽脳のみだとアイディアが溺れていく」
※UIデザインする人は１０回ぐらい見ましょう。
---
デザインをしていて迷ったら
実際に画面を作っていると、「ああ、このワイヤーだと前後の画面とのテンション感がおかしくなる」とか「決めたカラースキームだと画面が暗くなりすぎる」とか出てくるかもしれません。
というか１００％出てきます。
ですが、この段階では「何故そのワイヤーになっているか」の意図がわかっているはずなので、逆にいうと「何を変えても大丈夫か」がわかっているはずです。
ということは前後の画面も含めて調整が可能です。
カラーなどに関しても、あくまで最初に決めたカラースキームは仮説なので、いじっていって大丈夫です。
目的は「ユーザー体験」をぶらさないことと、「アートの方向性」をブレずに表現できることです。アジャイル（？）に行きましょう。
---
ここまでのまとめ
• コンテンツプランナー、アートディレクターと見せ方の認識を合わせる
• いきなり画面を作り出すのではなく、キーワードやムードボードを作って、イメージの認識を合わせる
• 装飾や配色に説得感をだすために、歴史的背景や知識を身に付ける
【３】ブラッシュアップ／ガイドライン化／実装
３−１．チームに共有しながらブラッシュアップ
そうやって４〜５画面ぐらい違う構成の画面を作ってみると、画面全体のテンション感のバランスや、パーツのルールが見えてくると思います。
この時点でチームに確認をしてもいいと思います。
４〜５画面ぐらいあると確認する側もイメージのズレが分かりやすいので、
「ちょっとテンションが違うねー、もっと強く、神々しさを出してほしい」 などの意見が出てきます。
自分の中で立てた仮説とのズレが認識できたら、どうズレていて、どう変えていくのかを（自分の中だけでも）言語化して調整すると良いと思います。
３−２．デザインガイドはアップデートして作る
その中で、各パーツ（レイアウト、ボタン、リスト、タブなど）のデザインルールが見えてくるはずなので、ちょっとずつデザインガイド化していきましょう。
昨今「デザインガイド」という言葉がバズってて「とりあえずデザインガイドを〜！！」となっちゃう人が結構いますが、デザインガイドは作りながらアップデートする。で良いと思ってます。完全な制定はUI全部がある程度完成するのと同タイミングで良いと思います。
３−３．実装方法を検討・相談する
作っているデザインをエンジニアにも見せつつ、具体的な実装方法を相談します。
例えば「ここはスワイプでも切り替えられるようにしたい」や「こういう演出の切り分けをしたい」などなど。
デザイナーにも実装の知識って必要？
デザイナーが自分で実装するかどうかはチーム方針もあったり、メリットデメリットもあるので難しいところですが、多少なりとも実装側の知識はあったほうが良い…と考えてます。
具体的にはUnityの場合だと、
・uGUIのクセや、Hierarchyの構造によるアニメーションへの影響
・画像で用意したほうが良いもの、Unity側で処理したほうが良いものの違い
・シェーダーの考え方
などなど、パッと思いつくだけでも、知っておいたことが多そうですね。
具体的な知識もなのですが、やはりUIデザイナーである以上、多少なりともエンジニアと会話ができるのは必要だと思います。
少なくともWebの実装がわからないWebデザイナーが減っていっているように、ゲームの実装に無関心なUIデザイナーは今後業務範囲が狭まっていく…と思います。（勝手に思ってるだけです）
---
あとは細かなブラッシュアップを重ねていきましょう
ブラッシュアップを重ねて画面を作って行けば、あとは細々とした調整／クオリティアップをしていけばOKです。
ここまでくればもう後は「作るだけ」なので作業分担もしやすいですし、問題なく完成すると思います。
---
ここでのまとめ
• ワイヤーフレームやトンマナはあくまで「仮説」として置く、それをなぞりすぎない
• 全ては最初に決めたユーザー体験や行動に基づいてデザインする
• チームにデザインを共有する。目指している体験とズレがないか、認識をあわせに行く。
• デザイナーも実装に興味を持とう
【最後に】
長々とありがとうございました。
おそらく普段からUIの仕事をしている方は「なんだ、こんな普通のこと…」と思われるかもしれません。
まあでも、その普通も忙しいと忘れることって、多いですよね。
実際自分もミニマムなプロダクトだったり、それなりの規模のアプリなのにUI制作の期間がタイトある場合じゃないと、このフローを全部やるのは…正直難しいです。
１ヶ月とかしかなかったら、ほとんどすっ飛ばすか、自分の中だけで完結してゴリゴリ作ったりしますし。
---
大事なのは「体験ベースの設計」をブレさせないこと。
そういう場合でも、「目指すユーザー体験」と「行動設計」さえ抑えておけば、大崩壊はしないです。
特にスマホゲームなどの場合、表面のグラフィックは後からいくらでも変えたりブラッシュアップできるのですが、コアの体験や行動設計が変わるとそもそもユーザーが期待している体験と変わってしまいます。
「昨日までタントやったのに、急に左ハンドルのレクサスになっとるがな！こんなもん運転できるかい！」となってしまいます（？）
それくらい体験や行動の設計は「後から変えづらい部分」なので、逆にそこの設計させしっかり作っておけば大丈夫です。
UIの形状やトンマナにこだわり過ぎて、体験を見失うことのないように、デザイナーはデザインを作っていかないと…と常々思っています。
もちろん組織やプロジェクトの規模、メンバーによって進め方は変わりますが、全体で見るとこういう感じで進めることが多い、というお話でした。
---
本当に長々とお付き合いありがとうございました。
明日以降もアドベントカレンダーは続いていきますので、お楽しみに！
この記事が気に入ったらサポートをしてみませんか？