UIデザイナーの私がノンデザイナーの友人からプロトタイプのコツを学んだ話
初めまして。UIデザイナーのユニスと申します。
皆さんはボードゲームというものをご存知でしょうか？
ボードゲームとは、ボードの上で駒やカードなど使って遊ぶゲームのことで海外ではカタン（Catan）やドミニオン（Dominion）などが有名です。
日本においては将棋や囲碁なども一種のボードゲームと考えられます。
ボードゲームデザインは専門性や製作コストが高く難しいと思われがちでしたが、近年ではデザインツールやプロトタイプツールなどが普及したことや、クラウドファンディングなどで出資を集めてボードゲームを作るハードルが下がりました。
新作ゲームの数だけでなく、ボードゲームを遊ぶ人口も全世界的に増えてきているため、市場が年々拡大しているようです。
ボードゲームの楽しみ方のひとつとして、自分の世界観を持っているゲームを作る人もいます。
私もそのタイプなのですが、奇遇にも同じように「ゲームを作りたい」と考えている教員の友人とゲームのデザインをすることにしました。
同じ「ボードゲームをデザインして完成させる」という目的を持って取り組み始めましたが、友人とはデザインの進め方がだいぶ違うことに気が付きました。
しかも、デザインスキルやプロトタイプについてのメソッドやノウハウが豊富なはずの私よりも、友人の方が高い精度の仕上がりになっています。
なぜこのようなことが起きたのか考察としてまとめてみました。
そもそも、ボードゲームデザインのプロセスとは？
ボードゲームデザインのプロセスは、サービス・アプリデザインと同じように、デザインシンキングのフレームワークのような、概ね５つのステップに分けられております：
１）リサーチ
２）コンセプト定義
３）アイディエーション
４）プロトタイプ・ユーザーテスト
５）ビジュアルデザイン
ボードゲームとサービス・アプリデザインと決定的な違いは、「ユーザーの行動への制限」です。
アプリにおけるユーザーの行動制限は、画面上のコンポーネントによってなされます。
ボードゲームにおけるユーザー行動への制限は、ルールブックとパーツのみです。
ユーザーへの制限が少ないということは自由度が高くなります。
なのでアイディエーション、プロトタイプ・ユーザーテストをこなす回数やスクラップアンドビルドの回数も、サービス・アプリデザインより圧倒的に多くなります。
上記のプロセスに関して私はもちろん、デザインの知識を一切持っていない友人も同じステップでゲームのデザインを進めていました。
考察の観点
今回は以下の３つの観点で考察をしています
考察① ツールの違い
考察② プロセスの違い
考察③ テスト頻度の違い
【考察①】ツールの違いから考察する
「デザインツールの違いで進め方にどう違いが出るのか？」という観点で考察をしてみました。
私は、普段の業務でもアドビデザインツールを使い慣れているため、ゲームのボード、コマやカードを作る時ももちろん、Adobe IllustratorとInDesign（以下Adobe AI/ID）の組み合わせで制作を進めました。
その反面、友人はIllustratorやInDesignを扱ったことないため、ツールを検討した時は、「Powerpointのスライドマスターで、カードテンプレートを量産できる」という点でPowerpoint（以下PPT）を採用することにしました。
では、Adobe AI/ID と PPT を比べてみます。
プロトタイプの初期アートワーク作成【 PPTに軍配 】
Adobe AI/IDは元々印刷物制作用のデザインツールのため、アートワークやメジャーの精度も高く、サイズや配置への制御が整っています。
対してPPTはプレゼンテーションツールです。
近年ではスライド内のものや配置への制御が飛躍的に進化しましたが専門的なデザインソフトとは比べ物になりません。
本来であればPPTの粗さはデザインにおいてハンデだと思われます。
ですが、実際にはPPTの粗さは作業スピードという面でAdobe AI/IDより優れていることが判明しました。
PPTはデザインツールとしての機能がAdobe AI/IDより弱く、配置やフォントへの制御がうまくできなくても「ソフトの制限だからまぁいいや」というある意味では諦めのつく環境になります。
また、画像やアイコンもPPTでは簡単に作れないため、アイコン機能やWeb上の画像素材を使うことが多くなります。
対してAdobe AI/IDは、フォントスタイルの設置、アイコンの作成、画像のリンク管理など、制御の細かい作業が多くなってしまうため、初期アートワークを作成する時間はPPTよりも多くなります。
アートワーク修正【 PPTに軍配 】
ここでもPPTの粗さが役に立ちます。
プレイテストをする途中で手書きで修正し、その後PPTで修正をするのが容易ですし、修正後の位置調整も大体でオッケーな場合が多いです。
また、PPTはアートワークを追加・削除するのに、スライド自体を増やす・消すだけでできるのでAdobe AI/IDより手軽です。
「いい意味で拘らないでいい」「手軽」という二点によってPPTの方がスピーディーにプロトタイプの修正を行うことができます。
データ作成、修正管理【 Adobe AI/IDに軍配 】
「データ・デザインの変更管理」においては、やはり専門ツールとなるAdobe AI/IDの完全勝利となります。
ゲームデザインにおけるデザイン修正・プロトタイプ作成の量は、普通のアプリ・サービス開発より圧倒的に多くなります。
コンセプトだけ残して、ゲームのコンポーネントやボードを０から作り直すなど、大きな変更をせざるを得ない場合も多々あります。
PPTはファイル内における大幅な変更や別アプリからのデータを取り込む前提で作られたツールではありません。
ですので、データを修正する際はひとつずつ手動でやる必要があります。
InDesignは別アプリからのデータ連携が容易です。特にAdobe IllustratorやAdobe Photoshopなどとのは抜群です。
例えばデータマージという機能があります。
これはページのデザインテンプレートにCSVデータを流し込んで大量のページ作成をすることができるものなのですが、テキストだけでなく画像まで扱えるのが特徴です。
CSVデータという軽量なファイルでデータを作成・修正をすればいいので管理が非常に楽になります。
PPTでもデータを流し込むことはできるのですが画像は扱えないことや、機能の使いやすさはInDesignの方が優れています。
【考察①】まとめ
「プロトタイピングのスピードを重視するならPPTは優秀」
サービス開発、UIデザインの時、プロジェクトの進捗状況に応じて、PPTレベルの粒度とAdobe AI/IDレベルの粒度をを意識的に使い分けて活用することで、より効率的で効果的なテスト結果を得られると思います。
【考察②】プロセスの違いから考察する
次は修正・改善プロセスのアプローチについて考察してみます。
サービスや機能、または組織における検討改善サイクルは、PDCAかOODAが有名です。
PDCAとは
計画（Plan）、実行（Do）、評価（Check）、実行（Action）
OODAとは
観察（Observe）、理解（Orient）、決定（Decide）、実行（Action）
ボードゲーム開発において、プロトタイプのテスト・修正・改善の回数は莫大になります。
なので改善へのアプローチが効率的かどうかは、ゲームのデザイン精度や全体的な進捗状況に非常に大きな影響を与えてます。
私は改善プロセスをシステマチックにアプローチすることが好きなので
１）システムへの変更箇所は計画を立て、想定した結果に仮説を立てる
２）変更箇所を含めたゲームをテストする
３）ユーザーの反応や戸惑いポイントを観察し、仮説と照らし合わせて確認する
４）うまく行った箇所のみ全体に投入する
という、PDCAに近いアプローチです。
友人は私と反対に、改善の進め方はゲーム中やゲームの直後にすることが多いです。
１）ゲームをプレイしている人を観察し、プレイヤーの不満や戸惑いなど、ネガティブな感情になるポイントを探る
２）そのネガティブな感情を芽生えるシチュエーションをその場で分析する
３）ゲームが進行している前提で、ルールやテキストなどを、行っているゲームに大きな影響がない程度の施策をプレイヤーに提案する
４）プレイヤーのフィードバックを踏まえた上、その場で修正を行う
という、OODAに近いアプローチです。
（普段の授業で鍛えられたのか瞬発力と臨機応変力が非常に高い）
その場での修正・改善においては、友人のOODAモデルの方が圧倒的に早いです。
ただし、改善というのはスピードだけではないのでもう少し細かく見てみましょう。
修正・改善サイクルのスピードと量【OODAに軍配】
私の（PDCAの）進め方は、ゲームを一通りやって、そこで得たコメントを全て持ち帰ってから合わせて検討するような形になります。
たくさんのコメントをもらった上でシステム全体を通して再検討することとなり、一つの修正を全体反映するのに時間がかかってしまいます。
それに対して友人の（OODAの）進め方は、ゲームの途中でもすぐに修正をかけているためゲームが終わる時点ですでに修正が終了しています。
そのまま次のゲームを迎えることもできます。
修正する時間も、サイクルも短縮できるため改善のペースが圧倒的早いです。
修正の整合性、変更経緯の把握【PDCAに軍配】
友人の進め方は圧倒的にスピードが速いです。
ただし、この進め方はゲーム進行に影響しない前提でポイントごとに修正することになるので、ゲーム内で触れなかった他の部分や全体に影響してしまうリスクがあります。
また、修正する際に常に発散している状態になっているため、全体像の検討が修正スピードに追いつけずゲームの主軸テーマやゲームの流れもかなりブレやすくなります。
アプリのようにGoogleのMaterial Design guidelinやAppleのHuman Interface Guidelineなどのようなフローや挙動を制限するようなものがあるわけでもなく、紙上でできるならなんでもありの世界ですから。
実際、数々の修正を終えたあと、修正した結果がゲームのコンセプトから離れすぎたため、原点に戻って再設計せざるをえなかったことも何回かありました。
それに対して、私の場合は修正を行うたびにゲームのテーマ、プレイヤーのゴール目的、ゲームの流れなど全体を通して見直しています。
それぞれの修正に対してゲーム全体や各箇所への影響が把握しやすい状態になっています。
また、仮説を立てた上で挑むゲームテストとなるため、検証箇所ももちろん、プレイヤーの反応やその反応の裏にある理由や誤差もある程度想定上のものとなります。
改善をするにあたって、方向性が明確で改善箇所も網羅している状態で修正を行うことができます。
また、プレイヤーの反応やコメントを持って改善をすることで、毎回のフィードバックも記録として残せるため、改善の経由や目的も圧倒的に整頓された状態になります。
ゲームコンセプトの進化【OODAに軍配】
もし私のプロセスが発散⇆収束のサイクルならば、友人のプロセスは常に発散しているとも言えるでしょう。
「常に発散してる」というのは、実際やってみるとそれほど悪くないことが判明しました。
修正を常に繰り返しているため、手間や手戻り、修正回数とテストサイクルも多くなりますが、流れ上では、自然と収束に向かっています。
また、修正の方向性や終着点が定めていないため、ゲームコンセプトの変貌も大きくなります。
実際に友人のゲームはOODAのサイクルをたくさん回したことで、ゲームの流れが当初からがらっと変わりました。
遊んで「気持ちいい」と思える箇所も、当初より多く、そして的確に刺さるようになりました。
また、友人もゲームの進化を楽しんでいて、変化に合わせて柔軟にテーマを調整し、詳細を詰めていくように推進しました。
そして、いつの間にかゲームの遊び心地が、ほぼ市販のゲームと変わらないくらいの粒度になったのです。
【考察②】まとめ
「コンセプトの主軸を柔軟に進化させたいならOODAは優秀」
サービスをコンセプト的な概念からスタートする場合、OODA方式で進める方が、より精度の高い面白そうなサービスを作れるでしょう。
その反対に細かい制限をかけられている、または修正コストが高い既存サービスに対する修正・改善はPDCAモデルの方がよりポイントを絞った状態で調整の意思決定を推進できるでしょう。
【考察３】テスト頻度の違いから考察する
最後に、テストの頻度における影響を見てみましょう。
友人の場合は、修正が非常に早いため１日に２、３回遊ぶのも問題ないのですが、私の場合は１日に一度、そして修正が完了させるのに１週間ほどかかります。
そのため、友人のゲームはほぼ毎週のようにテストをすることができ、私のゲームは月に１回くらいテストをするようなスケジュールになりました。
すると、友人と私のゲームに対するプレイヤーの反応にかなり大きな差が出るようになりました。
プレイヤーの学習負荷【月に１回に軍配】
開発中のボードゲームにて最も大変なことは、自分以外の人にゲームの遊び方を説明することです。
これは修正した分学習コストがかかることになります。
週に１回のペースでテストしたら、プレイヤーが新しいルールや遊び方の変化に慣れるのは平均３回目以降からだったことがわかりました。
慣れたゲームに対する修正が細ければ細かいほど、こまめに学習し直すことが必要になってきます。
また、細かい修正とはいえ修正の範囲と変化の多さによって、一週間経っただけで、「別のゲームをやっているんじゃないか？」と思ってしまうくらい、学習しなおす必要が出てきます。
ところが月に１回の程度で遊ぶ場合、ゲームへの慣れが浅いこともあって修正をかけたとしても、新しいルールや変化に対しても「合間が空いてしまったから、改めておさらいしましょう」という感覚で学習負荷が軽く感じます。
変に慣れてしまうよりも、受け入れやすかったのだと考えられます。
コメントの粒度・質【週一も月一も同等】
週に１回のテストと月に１回のテストにおいて、一番大きな違いは、やはりプレイヤーの着眼点となります。
本来であれば、ゲームデザイナーはゲームに参加せずにモニターとして観察するのですが、コロナの状況もあって人を集めにくいことから今回は私と友人もプレイヤーとしてコメント・評価していくようにしています。
同じプレイヤーグループで週に１回するテストする場合、遊び方に慣れているので色んなパーツの組み合わせやゲーム内の戦略を考えれるようになっています。
そのため、気にするポイントや指摘事項もゲームの全体の流れやシステムの仕組みよりも個別の細かい部分に目がいきがちです。
また、プレイヤーごとに好きな戦略や駒などの傾向も出来上がってしまうので、フィードバックも全体に対するコメントよりもその１回のゲームに対して、自分が使ってた駒や戦略に対するポイントが多くなります。
加えて、ゲームの勝ち負けに左右されてコメントが感情的になってしまうこともあるため、バイアスを見抜ける能力が問われるように感じます。
対して、月１回の頻度の場合は遊び慣れていないために指摘するポイントもゲームの流れや楽しさなど総合的な評価が比較的に多くなります。
また、ゲームへの印象や好みなどのバイアス要素がかかりにくく（思い入れを形成するほどの親しみがない）全体に対する発見も客観的になります。
ですので、週１回と月１回ではコメントの性質が全く異なるため比較しがたいと感じました。
【考察③】まとめ
細かく見たい場合は短期間で多くテストを繰り返す、全体的に評価してもらいたい場合は時間を空けてテストする
得たいコメントの質や粒度に応じて、テスト対象がテストに感じるストレスの原因やレベルを想定し頻度や長さを柔軟に調整するのが良いでしょう。
最後に
いかがでしょうか？
このように私と友人の進め方が違ったため、効率の高さやテスト結果の質、プロジェクト管理の細かさなどだいぶ違いがありました。
また進め方による根本的な違いを理解したうえで、今では
・私がグラフィックやデザイン修正の管理など長期的なゲーム開発の土台部分が役割
・友人がゲームの進化、テスト、ゲームルールやパーツ詳細の粒度向上が役割
となっています。
私と友人の進め方自体に絶対的な正解や不正解はないと思っていますし、状況やその場にあるニーズによってそれぞれメリット・デメリットがあると思います。
業務上でプロトタイプやテストを行う時に、私と友人それぞれのやり方を参考しつつ状況に応じて進め方を変えて柔軟に対応するのが効率的ではないかと感じました。
後日、1 dollar prototypeという本を読みました。
その内容を私と友人の進め方に照らし合わせて確認すると、友人の進め方がより高速プロトタイプの思考に近しいことがわかりました。
UIデザインをするにあたってフレームワークやユーザーテスト従来の「あるべき姿」に拘らずに、臨機応変にやったほうが効率に良いのだなと身を持って思い知らされました。
この記事が気に入ったらサポートをしてみませんか？