製作
要点
この段階は、 UXD のプロセスに基づいた提供価値をいかにサービスとして継続させ、事業にしていくかを設計していく段階です。
さて、エンジニアの出番のです。
ここでは、エンジニアにとってはあまり新しいことはありません。リーンキャンバス書いて、 MVP 決めて、アジャイルで開発のイテレーションを繰り返す段階です。
強いて言うなら、いきなりコードは書かないってことです。
「製作」のプロセスの後に、「検証」の段階があります。ここで何を検証するかによって、製作物は変わります。
コンセプトを検証したいなら、スケッチブックに書いたストーリーボードで十分だし、簡単な UI や情報構造を検証したいなら sketch で簡単に作ったモックで十分です。とにかく、工数をかけないで早く MVP を実現することを考えると良いと思います。
それでもって、コンセプトや UI や情報構造がユーザーの求めているものになっている時に、初めてコードを書けるということです。ある程度、価値が保証されているので、「無駄なものを作るかも？」という変な心配も最小化できます。
そして、ユーザビリティーを検証したい時に、本番と同じように動くサービスをユーザーに見せて、検証します。
この段階まで来ると、仮説・検証・学習・改善のサイクルが早く回り始めます。
この改善のサイクルを早く回すのに重要なのは、「何を検証したいのか？」と「 MVP ってどこまでだっけ？」を常に意識することだと思います。常に「怠惰」な気持ちを持って工数とコード量を削減すること考えると良いと思います。
この章の残りは下記の点を詳細に書きます。
- キャンバス
- CJM（TO_BE）の作成
- プロトタイピング
キャンバス
ググればたくさんキャンバスについての記事はあります。なので、僕がここでキャンバスのこと詳しく説明する必要はないし、もっと良く書かれた記事を見たほうが良いと思います。
ググって一番上にでてきた記事を下記に示しておきます。
僕はここで UXD の中で書くキャンバスの注意点だけ、記しておこうと思います。
まずは、「調査」と「分析」の段階の結果がキャンバスに反映されていることです。
簡単な対応を下記に示します。
- 独自の価値提案 -> 価値マップ
- 顧客セグメント -> ペルソナ
- 課題 -> CJM
それぞれが、「分析」で得られてアウトプットが反映されているかチェックする必要があります。
ここのつなぎこみをしっかりしていないと、検証後に分析結果のどこを修正すればよいのか分からなくなってしまいます。
突拍子もないアイデアかどうかよりも、それが事実に合っているかどうかがキーになります。あくまでも、この段階は今までのプロセスの続きだということを覚えておいて下さい。
また、エンジニアだからよく起こることなのかもしれませんが、アイディアの発想が機能寄りになっていると利用状況で想像がつかない「ソリューション」になってしまうことがあります。
エンジニアやテック好きの人たちはついつい新しい機能やテクノロジーで解決したくなりますが、それは往々にしてユーザーや提供価値ベースにない、ソリューション発のアイディアになっている可能性が高いです。自分の作っているものが機能ベースになっている時は、ソリューションベースになっている兆候です。
CJM（TO_BE）の作成
キャンバスができたら TO_BE の CJM を作ることになります。
まずは、キャンバスのソリューションから AS_IS の CJM どの部分を TO_BE の CJM にするかを判断します。
この時に、抜き出す TO_BE のエリアは狭くしすぎずに前後を少し広くとると良いです。実際にできたサービスで、使っている最中だけでユーザーの行動が変わることはなく、おそらく使用の前後のユーザーの行動も変わるからです。
TO_BE にする箇所を決めたら、いきなり TO_BE の CJM を作るのではなく、ストリートマッピングを作成します。
ストリーマッピングとは、キャンバスのソリューションがストーリーとしてユーザーの感情を喚起するものなのかを視覚化したものです。
言うなれば、キャンバスをストリートとして理解するものです。自分たちのソリューションがこの曲線を再現できるのかを確認することで、TO_BE の CJM の感情曲線がドラスティックに変化するのを確認できます。
注意することは、 CJM の感情曲線と違い、この曲線はユーザーの感情のポジとネガで上下するものではない。この曲線は良くも悪くも単純にユーザーの気持ちの高ぶりを示す曲線になります。
ストリーマッピングの詳しい説明はこの本を読むと良いと思います。
そして、 AS_IS で作った時のように TO_BE の CJM を作成します。
プロトタイピング
プロトタイピングには大きく分けて３種類あります。
- ストーリーボード
- デザインモック
- プロダクト
それぞれは、検証したいものによって使い分けます。
ストーリーボード
ストーリーボードとは、絵コンテのことです。
ストーリーボードは、提供価値のコンセプトを検証するときに使われます。
簡単なイラストを使って、４コマ漫画などの利用状況や提供価値のコンセプトがビジュアル化されたものを作ります。これは、コンセプトが箇条書きにされた紙を見せるよりも、より詳細にサービスのイメージができます。そのことにより、ユーザーも具体的なフィードバックが得られます。また、手描きなのでほとんど工数がかからず作ることができるのもメリットの１つです。
さらに、社内やチーム内でコンセプトを共有する時にも使われます。
ビジュアル化されているので、お互いが別々の方向を向きにくくなるのが理由のようです。
僕自身、まだストーリーボードを会社で使ったことはないので効果の証明ができませんが、 Airbnb は社内にサービスのイメージを共有する時に、ピクサーのアニメーターを雇ってストーリーボードを描かせたらしいです。
ストーリーボードの詳しく説明した記事を下に貼っておきます。
デザインモック
デザインモックは、 UI と情報構造の整ったモックのことです。
デザインモックだけでは、まだ実際には動かないです。
しかし、最近の sketch のバージョンのおかげリンクを繋げられるようになりました。このバージョンアップのおかげで、エンジニアの僕でも簡単なデザインモックとそれのリンク構造を作れるようになりました。（sketch 様、ありがとうございます！）
sketch を使ったデザインモックのプロトタイピングは、 UI や情報構造の他に、簡単なユーザビリティーテストできます。
また、 UI や情報構造をデザインしていく手法として、構造化シナリオ法というものがあります。
説明部分が少ないですが、僕が参考になったと思う記事を載せておきます。
http://www.standardinc.jp/reflection/article/customer-journey-map-uxdesign/
僕は構造化シナリオ法を使って、 UI や情報構造をデザインして、それを検証するというのよくやります。
構造化シナリオ法は、キャンバスや「分析」のプロセスとリンクしているので、改善を回しやすいというのがあります。
プロダクト
これはもう、エンジニアに説明不要ですね。
主に検証としては、ユーザビリティーの検証の段階で使われます。
あわせて読みたい
- エンジニアによるエンジニアのための UX デザイン開発実践ガイド 導入編
- エンジニアによるエンジニアのための UX デザイン開発実践ガイド 調査編
- エンジニアによるエンジニアのための UX デザイン開発実践ガイド 分析編
- エンジニアによるエンジニアのための UX デザイン開発実践ガイド 製作編
- エンジニアによるエンジニアのための UX デザイン開発実践ガイド 検証編
