「プロトタイプ」の定義と目的について考える｜UIデザイン特訓
本記事では、デザインの過程で気になったプロトタイプの定義と種類についてまとめています。
定義
プロトタイプ(prototype）とは
改めて正確に言葉の意味を把握できるように、まずは整理から始めます。
以下の記事の中で、プロトタイプについてはこのように説明されています。
プロトタイプ(prototype)とは、「試作モデル」の意味です。例えば、新しい製品の開発やゲームなどのソフトウェア開発において、初期段階にプロトタイプを作成します。
また、プロトタイプをもとに操作性、バランス、機能などを確認し、ユーザーからの評価を正式リリース前に反映させる開発手法を「プロトタイピング」と言います。開発途中で確認・修正ができるため、結果的に工程数が減り、問題点を早期に発見できるメリットがあります。
プロトタイプのメリット
プロトタイプを作成することは、私にとって好きな作業であり、プロジェクトを前進させるために重要な役割を果たしていると感じています。
具体的なメリットとしては、以下ではないでしょうか。
・アイデアを簡単に形にして提示するため、自分の考えを先に整理・示すことができる
・初期段階で自分と他者の考えの齟齬を確認できる
・方向感や現時点からの距離を掴みやすくなる
・手戻り（時間のロス）を少なくできる
・フローとしてある程度のイメージがつくので、現実的なフィードバックが得られる
→当初考えていなかった真の課題やニーズが別途挙がることもある
しかしプロトタイプにも難しい点があります。
「方向感を適切に把握し、手戻りを少なくする」ためにプロトタイプのタイミングとどの粒度で作成するかです。
私自身、制作を行う上で、一番注意していることは、自分の我を抑えることと、自分の指針を保つことのバランスです。
一見矛盾しているようにも感じますが、実は一番重要なことかと思います。
自分の我を抑えること
「自分が作りたいもの」ではなく「相手の要望を捉え、それに沿った形で自分のアイデアを加える」こと。
自分の考えが強くなりすぎてしまうと修正が難しくなるため、適切なタイミングで提示すること、方向感を見失わないことが必要になってきます。
一方で、
自分の指針を保つこと については
プロトタイプを用いずに議論を始めると、ユーザーが求めるものや他の人の声を重視しすぎて、自分の考えが制限された環境の中での思考となってしまい、、結果として受動的な行動になりがちです。
私は過去にそのような形で、スランプを経験したことがありました。
結果、まずプロトタイプを作成し、自分なりの課題解決方法を形に落とし込んでから、ヒアリングを行い、改善するプロセスを取り入れるようになりました。
その他の手法
プロトタイプの他にも、フローや設計を検討する際に役立つ手法がいくつかあります。
・スケッチ（ペーパープロトタイプ）：イメージの描写
・ワイヤーフレーム：枠組みの設計図
・モックアップ：枠組み＋色を付けた設計図
・プロトタイプ：クリック可能なイメージ図で、インタラクションやユーザーフローを理解しやすくしたもの
これらの他の手法と比較すると、プロトタイプは複数のページにまたがる遷移を含め、サービスを体験するユーザーの「行動フロー」をより具体的にイメージできるものが求められるとわかります。
【より細かく理解！】プロトタイピングの種類
プロトタイプにも複数の種類があります。
1. ローファイプロトタイプ｜Low-fidelity Prototype
情報アーキテクチャとユーザーフローをテストするもの
手書きや色やコンテンツのない基本的なデジタルフレーム
メリット：時短、低コスト、誰でも作りやすい
↑このようなツールやFigmaを使用しても作成できます。
2. ハイファイプロトタイプ｜High-fidelity Prototype
UI要素とユーザーが最終デザインにどのように関わるかを明らかにするもの
カラーとコンテンツを含むモックアップを使用し、インタラクションやトランジション、アニメーションで没入感のあるUXを描く
メリット：説得力が強く、正確なフィードバックが得やすい
注意点
ここまでプロトタイプのメリットを主に述べてきましたが、場面によっては適さないこともあるようで、その点についても少し引用しながら見ていきます。
こちらの記事では、「プロトタイプのテストをしない」という理由として、以下のような点が紹介されていました。
アジャイルやウォーターフォール型のプロセスでは、UXデザインや反復デザインに対応するための修正は発生しない。
なるほど。
ユーザーフローをもとにゼロからサービスを制作していた時には、プロトタイプ（特にハイファイプロトタイプ）が多いに役立っていましたが、実際の現場ではそうはいかないよ。ということですね。
開発チームによって進め方も異なると思いますが、それぞれの違いについてまず理解してみようと思います。
（その上で、開発方法によって適切なプロトタイピングを用いられるような選択スキルが向上すればいいなと考えています…！同じような知識レベルと感じられた方は、是非この後も目を通してみてください。）
補足：開発手法について（備忘）
以下は、プロジェクト管理ツールを提供するAsana社の解説記事を基にした開発手法の備忘メモです。詳細は原文やその他の参考サイトをご確認ください。
①ウォーターフォール開発
要件定義〜運用までの一連の工程を上流から下流まで順番に進めるシンプルな手法。方向感を保ち続けたり時間管理・進捗管理はしやすいが、一つ一つのプロセスを順を追って取り組むため、柔軟性に欠け変更には適さない。
②アジャイル開発
設計→開発→テスト→リリースの小さな開発サイクルを何度も繰り返す手法。ウォーターフォール型の対抗手段で、変更に対応しやすい柔軟なアプローチと継続的な納品を実現するために誕生した。通常2週間程度の短いスプリントで作業を完了させる手法で、バックログ管理、スプリント、振り返りが反復して行われる。
△スコープクリープに悩まされ、予算や時間が予想以上にかさむ可能性もある
スコープクリープ（Scope creep）：
プロジェクトが当初の目標や境界を超え、膨張し始める時に起こる現象を表す言葉
バックログ：
スプリント期間中に取り組む可能性のある全てのタスクを含んだリスト
③スクラム開発
アジャイルフレームワークとしてよく利用される手法。語源はラグビーのプレー手法であるScrumとされており、チームで反復と継続的な改善に集中できる手法として人気が高い。リーダー格となるスクラムマスターがチームリーダー、PM、プロダクトオーナー等から任命され、進行を管理する。
1. スプリント計画：〜2週間でどのように動くか計画。スプリント中に達成すべき仕事をバックログとしてまとめる。
2. デイリースクラムスタンドアップ：スクラム期間中に、毎日15分のMTGを行い、進捗確認・業務確認等を行う。
3. スプリントの振り返り：スクラムが終了したら、スクラムマスターはレトロスペクティブを開催し、行われた仕事の評価ややり残しタスクをバックログに戻し、次のスプリントに備える。
スプリントレトロスペクティブ（Sprint Retrospective）：
「スプリント全体の現状認識の共有、課題や改善案を話し合い、次のスプリントの効率向上を行うイベント」
△チームのキャパシティやスキルを超える可能性がある点に注意。
④かんばん
アジャイル型から派生した手法。「かんばんボード」を使用し、一目でプロジェクトの進捗状況が把握できるため、チームがより能動的に仕事に取り組めるようになる。スクラムマスターのようなポジション（PMなど）の配置は必須ではなく、タスクは全ての参加者から提案可能。
△タスク間の依存関係の把握が難しい
△長いスパンのプロジェクトには不向き
以上が開発手法の違いについてでした。
ここは違う！とお気づきになられた方は、コメント等でご指摘いただけると幸いです。
まとめ
ここまででプロトタイプとは、メリット・デメリットについて、注意すべき点などを記載してきましたが、正直、自分の中でも毎回学ぶことばかりだな、と感じています。
ですが、理解できるとある程度チーム内での動き方も変わってくると思うので、今後もテーマを決めて記事にしてみようと思います。
参考になった！という方や、これからも頑張れ！と応援してくださる方、
ぜひいいねを押していただけると嬉しいです。かなりの励みになっています…笑☺️
最後までご覧いただきありがとうございました！
この記事が気に入ったらサポートをしてみませんか？