Webサービスを開発しても、使われないことがあります。せっかくつくったのに使われないのは、開発者としてとても心苦しい状況です。集客をがんばって一時的にユーザがふえたとしても、なかなか継続してくれません。
この原因のほとんどは、開発する前に解決策を検証していないためです。解決策とはつまり『ユーザの課題をどう解決するか』ですが、この解決策を開発前に検証することで、使ってもらえる可能性を大きく高めることができます。
この解決策の検証に用いるのがプロトタイプです。この記事では、プロトタイプとはなにか、つくる目的やつくりかたについて書いていきます。
プロトタイプとは試作品という意味ですが、プロダクト開発においてはどういう解決策を提供するのかが視覚的にわかるものをいいます。
プロトタイプを使うのは主にユーザインタビューのときです。ユーザがプロトタイプを使ってみて、「このプロダクトは自分のこの課題をこうやって解決してくれるのか」と思えるような、プロダクトの意図が伝わるようにつくります。
プロトタイプにはいろんな種類があります。その中でもかんたんに作成できて修正しやすく、プロダクト開発にもっとも適した手法がペーパープロトタイプです。
ペーパープロトタイプはその名のとおり紙でつくった試作品です。ノートにペンで画面を書いていきます。これだけでも十分『プロダクトがどういう解決策を提供するのか』がわかります。
ペーパープロトタイプをユーザに見せて、必要に応じて修正していくことで解決策を継続的に改善することができます。
プロトタイプは、プロダクトが提供しようとする解決策を検証するためにつくります。
プロダクトのつくりかたとしては、はじめにアイデアを出し、ユーザの課題を検証し、課題の解決策を検証した上で開発に入ります。課題や解決策の検証前に開発に入ってしまうと、「本当にその解決策でいいのか?」がわからないまま開発することになります。
つくっても結局使われなかったら、開発した時間が無駄になってしまいます。
開発に入る前にしっかりと解決策を検証して、「この解決策ならユーザは使ってくれる」ということを確認した上で開発に入るべきです。
この検証をする上で重要な手法がプロトタイプです。
解決策をプロトタイプとしてつくり、ユーザインタビューでプロトタイプを使ってもらいます。解決策に問題があればプロトタイプを修正し、またインタビューします。このプロセスを繰り返すことでプロトタイプの完成度が高まり、開発しても失敗しづらい解決策ができあがるのです。
プロトタイプは、プロダクトが提供しようとする解決策を検証し、実際に開発するときの手戻りをなくしたり、よりよいユーザ体験を提供できるという役割をもっています。
では、プロトタイプの具体的なつくりかたについて書いていきます。
プロトタイプをつくるときは、まずユーザストーリーマップを準備します。プロトタイプは『解決策をどう画面にするか』なので、まずプロダクトがどういう画面をもつかを整理しておく必要があるのです。
ユーザストーリーマップはプロダクトにおけるユーザの行動を整理したものです。これをもとにプロトタイプをつくります。
次にプロトタイプのつくりかたです。ここではペーパープロトタイプのつくりかたについて示します。
ペーパープロトタイプは、紙とペンを用意し、ユーザストーリーマップをもとに画面を書いていきます。
このとき、どの画面を紙に書けばよいのでしょうか。書く画面は、「この画面がないとプロダクトとして成り立たない」というような、プロダクトの主要な画面、主要な機能だけを書きます。
また、画面や機能自体もできるだけシンプルに書きます。すべての画面、たとえば利用規約だったりヘルプページまで書く必要はありません。
プロトタイプでやりたいことは、プロダクトの主要な機能がそれでよいのかどうかを、ユーザインタビューをとおして検証することです。細かいところは一旦無視しましょう。
ひとつだけでなく、いくつかのパターンをスケッチしてみます。もっとも課題をシンプルに解決できているものをプロトタイプとして採用します。
このプロトタイプをユーザに見せて意見をもらい、プロトタイプを修正します。
このプロセスを何度も繰り返します。最初のころは問題がたくさん見つかり大きく修正する必要がありますが、そのうちインタビューをしても修正の必要がないタイミングがきます。ここまでくればプロトタイプは完成です。
ここではペーパープロトタイプについて書きましたが、ほかにもAdobe XDやSketchなどのツールを使ってつくる方法もあります。
ツールを用いると、たとえばPCやスマートフォンなど実機で画面を操作できます。リンクを押したら次の画面に行くなど、画面遷移まで体験できるので、より詳細な検証が可能です。
検証はしやすいですが、その分作成の時間や費用などのコストがかかってしまいます。
どちらに比重を置くかによりますが、プロダクト開発ではスピードがなにより重要なので、基本的にはペーパープロトタイプでよいでしょう。
プロトタイプと似た用語として、モックアップとMVPがあります。ここでふたつとの違いについて整理してみます。
プロトタイプは試作品という意味でしたが、モックアップは模型という意味をもちます。モックアップは実際のプロダクトのような見た目をもちますが、動作はしません。
モックアップは主にデザインの検証のためにつくります。解決策の検証のためにつくるプロトタイプとは、役割が明確に異なります。
MVPは実用可能な最小限の製品をいいます。MVPはそれ単体で実用的である必要があります。つまり動作する必要があるのです。
プロトタイプはあくまで解決策の検証が目的です。解決策さえ体験できればよく、実用的である必要はありません。プロトタイプで解決策を検証した上で、MVPの構築につなげます。
プロトタイプは、プロダクト開発においてユーザの課題をよりよい方法で解決するために重要な役割を果たします。
プロトタイプは、ユーザストーリーマップをもとに紙とペンで画面をスケッチします。ユーザインタビューをとおしてプロトタイプを何度も修正し、よりよいプロトタイプを目指します。
完成したプロトタイプをもとにMVPや実際のプロダクトをつくることで、よりよい体験をもつプロダクトにつながります。