筆者はいま、UI/UXデザインやアプリ開発を「頼まれる側」のチームで、エンジニアとして働いています。その前は電力会社で、どちらかといえば「頼む側」の立場でした(経緯は自己紹介にあります)。実際に、あるサービスのWEBページを新規制作するために、WEBコンサルさんに相談し、協働して作った経験もあります。
そんな筆者から質問します。UI/UXデザインを外の会社に頼む、つまり外注するとき、「AIをどこまで入れるか」は、誰が決めるものだと思いますか?
1.頼んだあなた
2.頼まれた会社
3.誰も決めていない
筆者の席から見える範囲では、という前置きつきですが、いちばん多いのは3です。依頼文には「AIも活用すること」と一行だけある。頼んだ側は「プロが考えてくれるはず」と思っている。頼まれた側は「お客さんの意向が分からないから、全部盛りで出しておこう」と思っている。お見合いです。
先にことわっておきますと、この記事はデザイン会社の選び方の話ではありません(会社ごとの違いはUI/UXデザイン会社18社を言葉で解析した記事で詳しく語られていますので、ぜひご覧ください)。ここで考えたいのは、会社を選ぶ前の話です。頼む前に、誰が何を決めておくと、お見合いにならずに済むのか。頼まれる側の席から見えていることを、少々お話しします。
聞き返さなかったAI
筆者がコーディングを始めたてのころ、AIにこう頼んだことがあります。
「ボタンを押した時に、そのボタンが右上にシュっと動いて、ちょっと色が薄くなるようにしてほしい」
アホですねぇ、実に。
頭の中にあったのは、ボタンがほんの少し斜め上に動いて、スッと色が変わる絵でした。返ってきたのは、ボタンが飛行機みたいに画面の外へ飛び立っていくエフェクトです。(自己紹介の記事に書いた話なので、詳しくはそちらに譲ります)
当時の筆者は「伝え方が悪かった」と反省しました。しかしいまは、半分だけ違う感想を持っています。当時のAIは、聞き返さなかったのです。「少しだけ動くのですか? 画面の外まで動くのですか?」と一度聞いてくれれば、飛行機は飛ばなかった。頭の中の絵を言葉にしきれないのは、頼む側としては当たり前のことで、そこを聞き返して汲み取るのが、頼まれる側の仕事なんだと思うようになりました。最終的に頼まれる側の手戻りになって、頼む側の時間を奪う訳ですから、当然と言えば当然ですね。
さて、「この製品にAIも入れてください」という一行です。これも「シュッと」と同じくらい、人によって思い浮かべる絵が違う言葉です。チャットの画面を思い浮かべる人もいれば、裏で入力を手伝う仕組みを思い浮かべる人もいる。ですから、頼まれる側はこの一行を見たら、聞き返さなければいけません。ちゃんとした会社なら、聞き返してくるはずです。
ただ、聞き返されて困るのは、頼む側です。「誰の、どの場面を楽にしたいのですか?」「AIが間違えたとき、どこまでなら許せますか?」「お客さまのデータは、使ってよいですか?」。この答えは、頼まれる側がどれだけ汲み取ろうとしても、社内にしかありません。この記事で書きたいのは、聞き返される前に用意しておくと、提案が速く、比べやすくなるものの話です。
「せっかくだからAIも」
たとえば、こんな会社があったとします。ここから先は、例え話として聞いてください。
給湯器やコンロなどガス機器を中心に扱っている、あるガス設備業者のAさん。契約しているお客さんがスマホから修理を申し込める「修理受付アプリ」を、数年前に作りました。ところが、申し込みの途中でやめて、結局コールセンターに電話してくる人が多い。入力する項目が多く、とくに製品の型番を書く欄で止まってしまうらしい。そこで担当のAさんが、UI/UXデザインを外注して、作り直すことになりました。
稟議を回していたところ、役員から一言つきます。
「せっかく作り直すなら、AIも入れたら?」
Aさんは依頼文に一行足しました。依頼文というのは、複数の会社に「こういうものを提案してください」とお願いする文書のことで、RFP(提案依頼書)とも呼ばれます。足した一行は、「AIチャットボットを搭載すること」。
三社から提案が届きます。
一社目は、アプリを開くといきなりチャット画面です。AIが症状を聞き取って、応急処置の案内から訪問の予約までやります、という案。
二社目は、受付のフォームを整理したうえで、画面の隅に「よくある質問」に答えるチャットを置きます、という案。
三社目は、チャットはお勧めしません、と書いてきました。代わりに、お客さんが撮った製品の写真から型番を読み取って、フォームを下書きします、という案。
見積もりは、一社目と三社目で、倍以上違いました。
Aさんは困ります。どれが良いのか、比べようがない……。三社は「AIチャットボットを搭載すること」という同じ一行を読んで、それぞれ別の問題を解いてきました。三案を役員に持っていくと、今度は
「で、うちはどれやるのが良いの?」
誰も答えられません。三社のうち一社でも、提案を書く前に「どの場面の、誰を楽にしたいのですか?」と聞き返していれば、話は違ったかもしれません。聞き返すのは頼まれる側の仕事です。ただ、聞き返されても、このときのAさんの会社には、まだ答えがなかった訳です。

ここで少しだけ、頼まれる側の席を離れます。筆者が見ているのは、その席から見える範囲だけだからです。UI/UXデザインの外注が一般にどう語られ、何を依頼でき、費用が何で決まるのかを、先に並べておきます。読み飛ばして「AIの目盛り」へ進んでいただいても、話はつながります。
「AIも」の一行を分解する ― UI/UXデザインの外注とは・依頼できること・費用が決まる変数・進め方6ステップ
UI/UXデザインの外注とは|UIデザイン・UXデザイン・Web制作との違い
UIデザインは画面そのものの設計です。ボタンの配置、文字の大きさ、色、入力欄の並び。UXデザインは、その画面を使う人が目的を果たすまでの体験全体の設計で、画面の前後にある「困りごとに気づく」「問い合わせる」「結果を受け取る」までを含みます。UI/UXデザインの外注とは、この二つを、調査から画面の設計、検証までまとめて外部のデザイン会社やコンサルティング会社に依頼することです。見た目を整えるだけのWeb制作とは、調査と検証が含まれる点が違います。本記事の修理受付アプリでいえば、「型番の欄で止まる」原因を調べ、止まらない画面を設計し、実際のお客さんで確かめるところまでが外注の範囲です。
外注で依頼できる業務の範囲
| 工程 | 依頼できること | 成果物の例 |
|---|---|---|
| 調査 | 利用者へのインタビュー、現行画面の問題の洗い出し、問い合わせログの分析 | 課題一覧、利用者の場面の整理 |
| 要件の整理 | 目的・対象者・対象の場面を一文にする。AIをどこまで入れるかの見立て | 要件定義書、スコープ定義 |
| 設計 | 画面の流れ、ワイヤーフレーム、画面デザイン、AIが関わる画面の確認・修正の設計 | 画面遷移図、プロトタイプ |
| 検証 | 試作を実際の利用者に触ってもらうユーザビリティテスト、AIの外し方の観察 | テスト結果と修正案 |
| 実装の伴走 | 開発会社や社内の開発チームへの引き渡し、実装中のデザイン確認 | 設計の引き継ぎ資料、レビュー記録 |
どこからどこまでを頼むかで、費用も体制も変わります。調査と検証を省いて設計だけ頼むこともできますが、本記事の立場では、調査と検証は削らないほうがよい工程です。
外注先の4つのタイプ
UXデザイン専業の会社、開発会社がデザイン部門を持つ会社、事業や戦略の相談から入る会社、見た目の制作に強い制作会社。どのタイプに頼むかは、課題がどの工程にあるかで決まります。「型番の欄で止まる」のような画面の問題なら設計と検証に強い会社、「そもそも誰のためのアプリか」から揺れているなら事業側から入る会社です。会社ごとの違いはUI/UXデザイン会社18社を言葉で解析した記事が詳しく、AI開発まで含めて頼む場合の比較軸はAI開発会社の選び方にまとまっています。
内製と外注の判断基準
社内にデザイナーがいても、外注が合う場面はあります。現行の画面を作った人が社内にいると、問題の洗い出しが甘くなりやすい。利用者へのインタビューや検証を回す手が足りない。AIを入れるかどうかの見立てに、社内の経験がない。逆に、改修が続くプロダクトで、設計の判断を社内に蓄えたいなら内製が合います。判断の軸は内製化とはで5つに整理されています。
外注のメリット・デメリット
メリットは、社内にない視点で問題を洗い出せること、調査と検証の手順を持っていること、短期間で試作まで進めること。デメリットは、社内の事情(データの扱い、審査、責任の所在)が頼まれる側から見えないこと、依頼文が曖昧だと提案が比べられないこと、そして設計の判断が社内に残りにくいことです。デメリットの一つ目と二つ目は、本記事の「三つ・二つ・一つ」で埋められます。三つ目は、提案を受け取るときに「なぜそう判断したか」を聞いて記録することで、ある程度は補えます。
なぜ「AIも」で提案がバラバラになるのか
「AIを活用すること」という一行は、AIの居場所を指定していません。利用者の画面に出すのか、裏で入力を手伝うのか、作る過程で使うだけなのか、入れないのか。本記事ではこの四つを、0(入れない)・1(作る過程だけ)・2(画面の裏)・3(画面の前)の「目盛り」と呼びます。業界で通じる言葉ではなく、この記事だけの比喩です。目盛りが違えば、作るもの、費用、AIが外したときに起きることが別の仕事になるので、同じ一行から別々の提案が出てきます。提案を比べるには、依頼文で目盛りを指定するか、「目盛りを明記して提案してほしい」と頼むか、どちらかが要ります。
AIを入れる場合に増える決めごと
AIを画面に関わらせると、従来のUI/UXデザインの外注にはなかった決めごとが三つ増えます。一つは、AIが外したときに利用者がどう気づき、どう直すかの設計。二つ目は、AIに読ませてよいデータの範囲と、社内の審査。三つ目は、外したときの責任の所在です。一つ目はデザイン会社が設計できますが、二つ目と三つ目は頼む側にしか決められません。AIの出力をどう見せると信頼されるかはAIの信頼性を高めるUX設計に、AIの画面設計の原則はAIプロダクトのUI設計6原則にまとまっています。
費用は何で決まるか
| 変数 | 費用が上がる方向 | 依頼文で揃えておくこと |
|---|---|---|
| 依頼する工程の範囲 | 調査・検証・実装の伴走まで含めるほど上がる | どの工程を頼むかを明記する |
| 画面の数と流れの複雑さ | 画面が多く、分岐が多いほど上がる | 対象の画面と場面を限定する |
| 調査の深さ | インタビューの人数、ログ分析の有無 | 人数と手法の希望を書く |
| 検証の回数 | 試作→テスト→修正の周回数 | 何回まわすかを決める |
| AIの目盛り | 画面の裏(2)より画面の前(3)のほうが、会話の範囲と検証の回数が増える | 目盛りを指定するか、目盛りを明記した提案を求める |
| 使えるデータの範囲 | 社内データを使うほど、審査と設計の工数が増える | 使えるデータと審査の見込みを書く |
費用の相場額は、範囲と目盛りが決まらないうちは、あまり当てになりません。本記事の三社の見積もりが倍以上違ったのは、会社の高い安いではなく、目盛りと範囲が違ったからです。
見積もりを比べられる形にする
三社の見積もりを並べるときは、工程の範囲、画面の数、検証の回数、AIの目盛りの四つを揃えます。揃っていない見積もりは、安いほうが得とは限りません。範囲が狭いだけ、検証が入っていないだけ、目盛りが低いだけ、ということがあるからです。提案に目盛りと理由が明記されていれば、金額の差がどこから来ているかを読み取れます。
依頼文(RFP)に書く6項目
本記事の「頼む前の一枚」の六つが、そのまま依頼文の骨格になります。目的(誰の、どの場面の、何を楽にするか)、許せる間違いと許せない間違い、使えるデータと社内の関門、AIをどこまで入れるかは提案に任せること、手段を指定しないこと、試す順番とAIの範囲を見直す線。RFPの一般的な必須項目(背景、現状、範囲、納期、予算、選定基準)はRFPの書き方にあるので、本記事の六つはその上に重ねる形です。
契約形態と、AIを含むときの注意
UI/UXデザインの外注は、成果物を決めて完成責任を負う請負か、作業時間で契約する準委任かのどちらかが多く、調査や検証のように進めながら決める工程は準委任のほうが合います。AIを含む場合は、「AIの推定が外れたときの修正」が契約上どちらの責任かを先に決めておかないと、検証のたびに揉めやすくなります。契約形態の違いは準委任契約とはが詳しいです。
進め方|6ステップ
- 目的を一文にする: 「◯◯で困っている人が、△△で止まらずに、□分で終えられること」
- 社内の関門を先に確認する: 使えるデータ、審査の手順と期間、責任の所在
- 依頼文を書く: 上の六項目を骨格に。手段は指定せず、目盛りと理由を明記した提案を求める
- 提案を目盛りで並べる: 工程の範囲・画面数・検証回数・目盛りを揃えて比べる
- 試作を実際の利用者に当てる: ユーザビリティテストのやり方に沿って、少人数で早く。AIを入れる場合は外し方も観察する(AIプロダクトのユーザーテスト)
- 見直す線で判断する: 先に決めた線に触れたら、止まった理由を見て、AIが前に出る範囲を狭める(例: チャットでの聞き取り→写真からの下書き)か、広げる(一問ずつ聞く会話に切り替える)かを決めて作り直す
外注で起きやすい失敗
依頼文に「AIを活用すること」とだけ書いて、提案が比べられなくなる。見た目の制作だけを頼み、止まる原因が調べられないまま画面が新しくなる。調査と検証を削って費用を下げ、配ったあとに使われない。提案が出そろってから「そのデータは使えません」と分かり、作り直しになる。作ってしまったあとで、AIが前に出る範囲を狭める相談を誰も言い出せない。どれも、頼む前に決める六つのどれかが抜けています。
——一般論はここまで。頼まれる側の席に戻って、三社の提案を一本の目盛りに並べます。
AIの目盛り
三社の提案を、一本の目盛りに並べてみます。「目盛り」という表現は業界の用語ではなく、この記事での呼び方で、尺度も筆者が決めたものです。AIがどこに居るかを、0から3の四段階に分けただけの整理として、お含みおきください。
| 目盛り | AIの居場所 | 修理受付アプリなら | お客さんから見えるもの |
|---|---|---|---|
| 0 | 入れない | 入力項目を減らす。型番が書いてある場所を写真つきで案内する | いつものフォーム |
| 1 | 作る過程だけ | デザイン案や試作をAIで速く作り、早い段階でお客さんに触ってもらう | いつものフォーム(出来上がるのが速い) |
| 2 | 画面の裏 | 製品の写真や「お湯が出ない」の一言から、型番と故障の種類を推定してフォームを下書きする | 下書き済みのフォーム。確認して直すだけ |
| 3 | 画面の前 | チャットで症状を聞き取り、応急処置の案内から訪問予約まで行う | AIとの会話 |
一社目が目盛り3、三社目が目盛り2です。二社目は、0に小さな3を足した案でした。どれも「AIを入れた」と言えますし、どれも間違いではありません。ただ、0と3とでは、作るものも、かかるお金も、AIが外したときに起きることも、まるで別の仕事です。見積もりが倍違ったのは、会社の高い安いではなく、目盛りが違ったからでした。
ここで考えたいのは、お湯が出ない冬の夜に、このアプリを開く人のことです。その人は、AIとおしゃべりがしたい訳ではないと思います。一刻も早く受付を終えて、「すぐに伺います」とか、「明日の午前に伺います」の一言が欲しい。そう考えると、Aさんの会社に合うのは目盛り2かもしれませんし、0で十分かもしれません。
目盛りは、高いほど偉い訳ではない。 ということです。
チャットだけの画面にすると何が起きるかは、AIプロダクトのUI設計について書いた記事で触れたので、ここでは繰り返しません。
目盛り1についても一言だけ。お客さんの画面にAIが出てこないので地味ですが、頼む側にとっての得は大きいと筆者は思っています。試作が速くなると、作り込む前に「これは型番の欄で止まらないか」を実際の人で確かめられるからです。
ひとつ留保しておきますと、AIの能力は日進月歩なので、この目盛りの中身は、来年には変わっているかもしれません。中身が変わっても、誰かが目盛りを決める必要があるのは同じだと思います。

三つ、二つ、一つ
では、目盛りのどこに合わせるかを、誰が決めるのでしょうか?
筆者は、決めることを六つに分けて、三つ・二つ・一つに割り振るのが良いと考えています(もちろん、案件によって変わりますよ)。
頼む側にしか決められないことが、三つあります。
一つ目は、誰の、どの場面の、何を楽にしたいのか。Aさんの会社なら、「お湯が出なくて困っている人が、型番の欄で止まらずに、三分で受付を終えられること」です。ここまで書けていれば、AIという言葉は一度も出てこなくて構いません。せっかくアプリを改修するなら、あれもこれも解決したいという気持ちは分かります。もちろん、そういった要望を整理しておくことも肝心で、細かい仕様を決める際のヒントになるかもしれません。しかし、今回の改修は「お客さんのスムーズな受付を促す」ことに端を発したものです。そこからブレないようにしないと、目指す製品像がどんどんぼやけてしまいます。
二つ目は、AIが外したとき、どこまでなら許せるのか。AIは毎回同じ答えを返す道具ではないので、外す日は必ず来ると考えておいたほうがよいです。型番の推定を外した。これは、お客さんが確認画面で直せるなら、許せるかもしれません。応急処置の案内を外した。ガス機器でこれをやると事故につながりかねないので、許せない。この線は、製品と、お客さんと、自社が負える責任を知っている頼む側にしか引けません。頼まれる側が勝手に引いてはいけない線だとも思います。
三つ目は、使ってよいデータと、社内で通さなければいけない関門です。過去の修理履歴をAIに読ませてよいのか。お客さんの住所や写真を、外のAIサービスに送ってよいのか。情報システム部門の審査には、どのくらいかかるのか。ここは、頼まれる側からはまったく見えません。提案が出そろってから「そのデータは使えません」と分かると、目盛り2と3の提案は、まるごと作り直しになります。
頼まれる側に任せたほうがよいことが、二つ。
一つ目は、目盛りの見立てです。上の三つが書かれていれば、頼まれる側は「この場面なら目盛り2です」「0で足ります」と、理由をつけて言えるはずです。依頼文には「AIをどこまで入れるかは、入れない案も含めて、理由をつけて提案してください」と書いておけば、きっと各社の判断の理由を聞けるはず。
二つ目は、手段の選定です。どのAIを使うのか。チャットにするのか、写真の読み取りにするのか。名指しされても「別の手段のほうが合います」と言うのは頼まれる側の責任ですが、名指しが依頼文の必須条件になっていると、それを言い出しにくくなります。「AIチャットボットを搭載すること」ではなく「AIをどこまで入れるかは提案してほしい」と書いてあるほうが、頼まれる側は仕事がしやすい訳です。
一緒に決めることが、一つ。
試す順番と、AIの範囲を見直す線です。いきなり全部を作らずに、まず試作を何人かのお客さんに触ってもらいます(試してもらうやり方はユーザーテストの記事に書きました)。そのときに、「五人のうち二人が途中で電話に切り替えたら、AIの範囲を見直す」と、先に決めておく。
見直す先は、二つあります。一つはAIの範囲を狭める方向です。チャットで症状を聞き取る(目盛り3)のをやめて、写真から型番を下書きする(目盛り2)に変える。AIが外した推定を直すのが面倒で電話に逃げたのなら、こちらです。もう一つは広げる方向です。型番が分からなくて止まる人には、フォームより「給湯器のどこかにシールはありませんか? 写真を撮ってください」と一問ずつ聞く会話(目盛り3)のほうが、最後まで行けることもあります。どちらに動かすかは、電話に切り替えた人がどこで、なぜ止まったかを見てから決めます。線だけ先に、向きは理由を見てから、です。
ここで依頼文に書いておきたい約束は、一つだけです。「線に触れたら、AIの範囲を狭める案も含めて見直す」。広げる案は、放っておいても後から出てきます。狭める案は、作ってしまった後だと、頼む側も頼まれる側も言い出しにくい。お金も時間も、もう使ってしまっていますからね。だから、狭める選択肢があることだけは、作る前に文字にしておきます。

依頼文を書き直す
設備業者のAさんの話に戻ります。
最初の依頼文は、こうでした。
修理受付アプリのリニューアル。今どきの使いやすいデザインにすること。AIチャットボットを搭載すること。
三つ・二つ・一つに沿って書き直すと、こうなります。
1.目的: お湯が出ない、火がつかないで困っているお客さまが、型番の入力で止まらずに、三分以内に修理の受付を終えられること。
2.許せる間違いと、許せない間違い: 型番や故障内容の推定が外れるのは、お客さまが確認画面で直せるなら可。応急処置の案内をAIが自動で出すことは不可。
3.使えるデータ: 製品の型番一覧と取扱説明書は可。過去の修理履歴とお客さまの個人情報は、社内審査が済むまで不可。
4.AIをどこまで入れるか: 入れない案も含めて、理由をつけて提案してほしい。
5.手段: AIの種類や、チャットにするかどうかは指定しない。
6.進め方: 試作をお客さま五人に触ってもらう工程を含めること。途中で電話に切り替えた人が二人以上なら、AIの範囲を狭める案も含めて見直す。狭める(チャットでの聞き取りをやめ、写真からの下書きに変える)か広げるかは、止まった理由を見て決める。
長くなりました。でも、この六行を読んだ三社の提案は、今度は同じ物差しの上に並びます。どの会社も「うちは目盛り2を勧めます。理由は〜」と書いてくるので、見積もりの差の理由が読める。応急処置の案内をAIに任せる案は、最初から出てきません。役員の「で、うちはどれやるのが良いの?」にも、Aさんは一行目を読み上げれば答えられます。
ただし、書き直せば良い提案が来る、という話ではありません。提案が比べられるようになる、という話です。三案を同じ物差しで比べられれば、Aさんも役員も、選んだ理由を言葉にできます。

UI/UXデザインを頼む前の一枚
六つを一枚にまとめます。AIが絡まないUI/UXデザインの外注でも、1と5はそのまま使えるはずです。
| 決めること | 決める人 | 依頼文に書く一行 | |
|---|---|---|---|
| 1 | 誰の、どの場面の、何を楽にするか | 頼む側 | 「◯◯で困っている人が、△△で止まらずに、□分で終えられること」 |
| 2 | 許せる間違いと、許せない間違い | 頼む側 | 「◯◯が外れるのは可。△△をAIが自動で行うのは不可」 |
| 3 | 使ってよいデータと、社内の関門 | 頼む側 | 「◯◯は可。△△は社内審査が済むまで不可」 |
| 4 | AIをどこまで入れるか(目盛り) | 頼まれる側が提案 | 「入れない案も含めて、理由をつけて提案してほしい」 |
| 5 | 手段(どのAIか、どんな画面か) | 頼まれる側 | 「AIの種類や画面の形式は指定しない。提案に任せる」 |
| 6 | 試す順番と、AIの範囲を見直す線 | 一緒に | 「◯人中△人が□□したら、AIの範囲を見直す(向きは止まった理由を見て決める)」 |
念のため、、、頼まれる側の人間が「頼み方はこうしてほしい」と書くのは、なんともおせっかいで、手前勝手な話です。しかも白状しますと、筆者自身、頼む側に回ると今でも「いい感じにしておいてください」と言いそうになります笑。
それでも、この一枚があると、頼まれる側は「AIを全部盛りにした提案」を作らずに済みます。その分の時間を、使う人の場面を調べることに回せます。
六つ全部は書けなくても大丈夫です。一つ目の「誰の、どの場面の、何を楽にしたいのか」の一行だけでも、返ってくる提案はずいぶん変わるはずです。
UI/UXデザインの外注のよくある質問
UI/UXデザインの外注では、何を依頼できますか?
調査、要件の整理、画面の設計、試作の検証、実装への引き渡しまでです。見た目を作るだけでなく、利用者がどこで止まっているかを調べ、止まらない画面を設計し、実際の利用者で確かめるところまでが範囲になります。本記事の修理受付アプリなら、「型番の欄で止まる」原因を調べるところから頼めます。どの工程を頼むかで費用と体制が変わるので、依頼文で範囲を明記しておくと提案が揃います。
UI/UXデザインの外注費用は、何で決まりますか?
依頼する工程の範囲、画面の数と流れの複雑さ、調査の深さ、検証の回数、そしてAIをどこまで入れるか(本記事ではAIの居場所を0〜3の「目盛り」と呼んでいます)で決まります。本記事の三社の見積もりが倍以上違ったのは、会社の高い安いではなく、目盛りと範囲が違ったからでした。相場額を先に調べるより、範囲と目盛りを揃えて見積もりを取るほうが、比べられる数字が手に入ります。
依頼文に「AIを活用すること」と書くのは、なぜ良くないのですか?
AIの居場所を指定していないからです。利用者の画面に出すのか、裏で入力を手伝うのか、作る過程で使うだけなのか。この違いで作るものも費用も変わるので、同じ一行から別々の提案が出てきます。本記事では、目盛りを指定する代わりに「入れない案も含めて、理由をつけて提案してほしい」と書くことを勧めています。頼まれる側の見立てを引き出せるからです。
AIをどこまで入れるかは、発注側と受注側のどちらが決めるべきですか?
本記事の答えは「見立ては受注側、材料は発注側」です。誰の何を楽にしたいか、AIが外したときどこまで許せるか、使ってよいデータは何か。この三つは発注側にしか分かりません。その三つが書かれていれば、受注側は「この場面なら目盛り2です」と理由をつけて言えます。どちらか一方に任せると、本記事のAさんのように、提案が出そろってから誰も答えられなくなります。
UI/UXデザインを外注する前に、社内で決めておくことは何ですか?
三つです。誰の、どの場面の、何を楽にしたいのか。AIが外したとき、どこまでなら許せるのか。使ってよいデータと、社内で通す審査は何か。この三つは頼まれる側からは見えないので、提案の前に用意しておくと、聞き返しの往復が減り、提案が速く、比べやすくなります。六つ全部でなくても、一つ目の一行だけで返ってくる提案は変わります。
小さく始めたい場合、最初に何を頼めばよいですか?
試作と、少人数での検証です。いきなり全画面を作り直すのではなく、止まっている画面だけを試作して、実際の利用者五人ほどに触ってもらいます。そのときに「五人のうち二人が途中で電話に切り替えたら、AIの範囲を狭める案も含めて見直す」という線を先に決めておきます。狭めるか広げるかは止まった理由を見て決めますが、狭める案があることを依頼文に書いておくと、作ってしまったあとに言い出しにくくなる相談を避けられます。
この記事は、ARCHECOが運営するメディア「アプリ戦略大学」でお届けしました。ARCHECOは、UI/UXデザインとプロダクト開発を強みに、お客さまと並走しながら「使われるもの」をつくっているチームです。ご相談・お問い合わせはこちらからどうぞ。