プロダクトデザインを外注すると、実際に何が納品されるのか

発注前にいちばん多い質問が「結局、何が納品されるのか」です。ファイルの一覧を答えることはできますが、それは価値のいちばん低い部分です。実際に買っているのは決定そのものです。

見積もりを検討している段階で、いちばん多く受ける質問はこれです。「結局、何が納品されるのですか」

ファイルの一覧なら答えられます。Figma のリンク、プロトタイプ、コンポーネントのライブラリ。稟議書に書きやすいのもこの部分です。

ただ、正直に言えば、それが価値のいちばん低い部分です。

実際に買っているのは「決定」です

プロダクトが世に出るまでに、誰かが必ず決めています。誰のためのものか。最初に何ができるか。何をあえてやらないか。データがまだ一件もないとき画面に何を出すか。通信が切れたらどうするか。ダッシュボードに並ぶ十二個の項目のうち、ユーザーが本当に見に来たものはどれか。

これらは、担当者を置いても置かなくても、誰かが決めます。デザイナーが席にいなければ、金曜の夜にコードにいちばん近い人が決めます。エンジニアを責める話ではありません。誰も拾わなかった決定が落ちる場所が、そこだというだけです。

プロダクトデザインの発注とは、その決定を、まだ変更が安い時点まで前倒しする行為です。

届く順に、正直に並べます。

ユーザーの動線の地図。 サイトマップではありません。実際に人が通る経路で、離脱する場所も含めて描いたものです。どんなプロダクトにも、静かに諦められている箇所が一つか二つあります。そして、たいていそこは一度も図に描かれていません。

重要なフローだけ、作り込んだもの。 登録、最初の本番利用、課金をお願いする瞬間、そして何かが失敗したとき。この四つをきちんと作るほうが、四十画面を八割の完成度で作るより効きます。

人前に出せるプロトタイプ。 スマートフォンのプロダクトならスマートフォンで動くもの。社内レビューで見栄えをよくするためではありません。会議室の意見は安く、目の前で一人がボタンを見つけられない光景は高いからです。

空・読み込み中・エラーの状態。 飛ばされて、あとから実装側で即興されがちな画面です。そして、ユーザーがいちばん機嫌の悪い日に見る画面でもあります。

会社の規模に合わせたシステム。 五人の会社にデザインシステムは要りません。必要なのはコンポーネント九個と余白のルール一つです。百人の会社なら、入社初日の人が読んで理解できるものが要ります。

いちばん役に立つ納品物は、たいてい一つの指摘です。

たとえば「料金ページが分かりにくいのが問題だと思われていますが、そもそも料金ページまで到達していません。オンボーディングの三番目で従業員数を聞いていて、回答者の半分は会社に所属していないからです」。

一文です。しかしこれは、まさに発注されかけていた料金ページのリニューアルより価値があります。

日本の会社と仕事をしていて気づくのは、稟議を通すために「作るもの」を先に確定させる必要がある、という制約です。だから要件が先に固まり、デザインは装飾の工程として後ろに置かれます。

これは順番が逆です。そして逆であることの代償は、たいてい開発の後半に、仕様変更という名前で請求されます。

現実的な折衷案があります。最初の二週間から四週間を「診断」として独立した小さな発注にすることです。金額が小さいので決裁が軽く、そこで出てきた地図と指摘が、本体の稟議の中身になります。順番を守りながら、決定を前倒しできます。

見た目を気に入ってもらえたかどうかでは判断しません。新しい見た目は、だいたい三週間は好かれます。

最初に動くのはリテンションです。次にアクティベーション、つまり新規のうち、そのプロダクトが約束していることに実際に到達した人の割合です。売上は最後に動き、しかも要因の切り分けが難しい。リニューアルで売上が何パーセント上がると断言する相手がいたら、それは推測です。

だから、始める前に数字を二つだけ決めて書き留めてもらいます。デザインが科学だからではありません。終わったときの会話が、好みの話にならないようにするためです。

十六年やってきて、うまくいった案件とそうでない案件を分けたのは、ファイルの品質ではありませんでした。決定を、ユーザーを見た人間が早い段階で下したか、それとも誰でもない人が、遅く、追い詰められて下したか。その違いです。

納品物とは、そのことです。ファイルは、それが書き留めてある場所にすぎません。