「UXデザイン」を依頼された時に考えること・やること

一時期、バズワードとして飛び交ってましたね。あの頃は「また変な流行り文句が出てきたな」ぐらいでナナメに見ていましたが、今では担当者です。

自分はWebのアプリ開発を5,6年担当してたのですが、気づけば名刺の肩書が「テクニカルディレクター」「UXディレクター」となってました。上司や雇い主からはそう見える（あるいは期待されている）のだろう、と思ってます。

じゃあ、そのUXディレクターたる自分は「UXデザインやって」と言われた時に何をしているのか、書き出してみます。あくまで私個人の例です。

１．ビジネスモデルキャンバスを書く。
本来、クライアントが書くべきもの（UXに含まない）と思ってますが、区別つけづらいと思うので、クライアントの代わりに書くこともあります。
「ビジネスモデルキャンバスって何よ？」て方はググってみてください。書くこと自体はそんな難しいものではないです。

２．インスペクションデッキを作る。
アジャイル開発の資料です。書籍「アジャイルサムライ」を参考に作ってますが、「エレベーターピッチ」「ペルソナ」「ユーザーストーリー（＝機能一覧）」「コンテンツ調達作業」程度の内容です。気をつけることは、ビジネスモデルキャンバスで記載した収益をいかにして実現するか、です。もっと言えば「この内容でホントに競合他社に勝てるの？」「ユーザー（ペルソナ）はこれを使ってみたいと思う？」です。

ユーザーとシステムの関係図、インフラ構成図、運用イメージなど補足するための資料も並行して作りますが、仕上げをエンジニアやクライアントに投げることもあるので、私が仕上げるインスペクションデッキとは分けてます。

３．サイトマップ、画面一覧作成
開発見積もり用の資料です。このあたりからエンジニアにとっては馴染み深いものが増えてきます。ユーザーストーリーを元に作成しますが、サイトマップ作ってる最中に「こっちの方が良くない？」と２に手戻りすることも多々あります。

４．ワイヤーフレーム、データの論理設計作成
ワイヤーを書きながら「このテーブルにはこれだけのカラムが必要」「このデータを更新するタイミングはここ」「このデータをこのタイミングで処理して、ここに表示する」みたいなことが具体化してくるので、そのへんも補足資料としてガシガシ起こします。具体化してきた結果「画面が足りない」「サイトマップの構成が変」となった場合は３に手戻りします。

ワイヤーフレーム作成の指南書には、４のタイミングで「ユーザーの使いたいと思うサービスを云々」みたいなことが書いてあったりしますが、個人的には遅いです。「使いたいと思うか」は、２の時点で完了していて、４は「使いたいと思った気持ちを邪魔しない設計になっているか」ぐらいの温度感で作ってます。

加点を狙うのは２で、４は減点を減らすことを意識してます。

５．開発見積もり
ユーザーストーリーと３と４の資料を開発会社やエンジニアに渡して、見積もりを依頼します。この際に、エンジニア側から「この目的ならこうした方が早くて安い」みたいな提案があれば乗ることもあります。変更が発生した場合は、手戻りして資料を修正します。

６．納品
５までの内容を全部、上司やクライアントに渡して、第一部完！

----

以上が、「UXデザインたのむ」と言われた時の仕事です。だいたい、このあと「引き続き、開発ディレクションもお願い」と大体言われるので、そのまま引き受けます。

2の途中ぐらいで開発会社にコンサルも含めて依頼するケースを見かけますが、少なくともビジネスモデルからワイヤーを起こす作業ぐらいまでは、社内に常駐してもらって進めてもらった方が、こまめに作成・確認・フィードバックが出来るので、手っ取り早いと思います。

「思ってたのと違う」は誰にとっても不幸ですから。

以上、ふわっと書いてみました。