くふうカンパニーAdvent Calendar 2019の6日目！
こんにちは、くふうカンパニーの株式会社Da Vinci Studioに所属している、デザイナーの@sai_fan_3です。
最近は、グループ内のデザインリニューアルや、グループ外のUIデザイン改修をしています。
プロジェクトを進めていくとき（とくに0→1開発）に、検証点を最初に決めるって当たり前では？と思われるかもですが、できてませんでした。検証点を1番初期に計画することの大事さを実感したので、書いてみます。
Wish
去年携わった新規事業というのが、「スマホ(Web)で結婚式をする」がコンセプトのWishというサービスです。
（くふうカンパニーのグループ内に株式会社みんなのウェディングおよび株式会社Da Vinci Studioがあり、新規事業は、みんなのウェディングのデザイナーとしてやったサービスになります。）
(実は、写真のお知らせにあるように、最近諸事情によってクローズしてしまいました。いいコンセプトだったと思うので、またいつか...)
検証点を先に考えればよかった！と実感したこと
リリース時に、 カップルが結婚を報告できる ・ ゲストがお祝いできる の2点をコア機能として、プロダクトを作成していました。
そんなある日のmtg、リリース時の検証ポイントはどこなのか。という話になり、、、考えられていなかったことに気づきました。
そのときに、一番検証したい項目として上がってきたのが、「Wishのコンセプトが受け入れられるか、ニーズがあるか」という点でした。
そこを検証するためだとしたら、プロダクトを作ること以外にも方法があったのかも🤔と、気づきました。
先に検証点を考えることの3つのメリット
手戻りがない
検証点を先に決めておくことで、検証結果が間違っていたときにムダになってしまう工数を削減できる。
次が見える
検証点をかんがえるときには、「その先で何を決定するため」かを考えるので、プロジェクトの次の段階が見えるようになる。
手段が凝り固まらない
プロダクトを作ってからも、もちろん検証できるのですが、プロトタイピングと同じで、モノを作ってしまうと愛着が湧いて、視野が狭くなって手段が限定されていってしまうので、その前に検証をしていくことが大事そう。
Wishの場合
「Wishのコンセプト（スマホで結婚式をする）が受け入れられるか、ニーズがあるか」という点を検証しようとしていましたが、これを検証するなら、コンセプトが当てはまらなかったらやめる、ということになります。けど、このコンセプトには良いという自信がメンバーにはあったので、ユーザーに感じてもらうには、どういう手段が一番適切なのかをもっと検証する必要があったんだなと思いました。
終わりに
「検証して、結果をみて、自信をもって次を進める」その循環を回していけるように、検証をうまく使っていきたいと思います。