笑天涯說：做產(chǎn)品的過程中，不可避免經(jīng)常遇到改交互的情況，設(shè)計(jì)師們，你們有沒有遇到提需求相當(dāng)隨意的產(chǎn)品經(jīng)理呢？

知乎提問：產(chǎn)品經(jīng)理提需求太隨意，老讓設(shè)計(jì)試試怎么辦？

問題補(bǔ)充：經(jīng)常遇到一個(gè)這樣的問題：

1，產(chǎn)品經(jīng)理提出好幾種交互方案，說要全部做出來放到線上快速測(cè)試看效果。

2，交互設(shè)計(jì)師和視覺設(shè)計(jì)師針對(duì)他的想法一一做了相關(guān)分析并且反饋?zhàn)罱K建議的方案，但是產(chǎn)品憑借自己的主觀感受堅(jiān)持自己的方案，或者所有的都實(shí)現(xiàn)，找理由說要“小步快跑，快速試錯(cuò)，多做幾種方案試試看”。

3，但是我覺得這樣很浪費(fèi)資源啊，而且覺得產(chǎn)品經(jīng)理很不負(fù)責(zé)，我會(huì)讓他們提供相關(guān)的數(shù)據(jù)和證據(jù)來支撐他們的需求，但是他們提供不了我也沒辦法否掉這個(gè)需求；

——————-

不要光評(píng)論對(duì)錯(cuò)或者只是噴PM，說說你覺得作為當(dāng)事人應(yīng)該怎么辦？

知乎用戶@吳亮的回答：

看了一下其他答案，好像都不太到點(diǎn)。題主的問題應(yīng)該是在交互層面，對(duì)方案中的某些要點(diǎn)，產(chǎn)品經(jīng)理和設(shè)計(jì)師都沒有充分的客觀依據(jù)去證明其合理性，而產(chǎn)品方面要求進(jìn)行多方案的測(cè)試，這個(gè)時(shí)候應(yīng)該怎么做？

恰好最近我也在思考這個(gè)問題，并提出了一種設(shè)計(jì)方法。雖然這是一個(gè)初步的想法，未通過實(shí)踐驗(yàn)證。但我覺得它還是有一定可行性的，歡迎大家討論。

在此把全文貼出來。有點(diǎn)長(zhǎng)，湊合著看（原文鏈接：Test-driven Design）。

—————–我是分割線—————–

## 不要說「我覺得…」

很多設(shè)計(jì)師習(xí)慣用自己的經(jīng)驗(yàn)和主觀感覺去提出方案，但經(jīng)驗(yàn)和主觀感覺很可能是錯(cuò)誤的。以用戶為中心的設(shè)計(jì)，需要以用戶心理、用戶行為相關(guān)的客觀事實(shí)為依據(jù)去執(zhí)行，而非以設(shè)計(jì)師的「自我參考」去執(zhí)行。

使用「自我參考」方式的設(shè)計(jì)師，經(jīng)常會(huì)陷入多個(gè)選項(xiàng)的糾結(jié)中，這樣會(huì)浪費(fèi)大量的時(shí)間和精力。若以事實(shí)為依據(jù)去設(shè)計(jì)，我們應(yīng)該收集足夠的數(shù)據(jù)、用研和測(cè)試結(jié)論，并根據(jù)這些事實(shí)去進(jìn)行決策。這么做能夠讓我們不浪費(fèi)時(shí)間而做出正確的決定。

團(tuán)隊(duì)成員對(duì)設(shè)計(jì)的討論和挑戰(zhàn)，通常也是「自我參考」方式的。這個(gè)時(shí)候如果沒有客觀事實(shí)為依據(jù)，設(shè)計(jì)師很容易陷入被動(dòng)的狀態(tài)（這讓很多設(shè)計(jì)師產(chǎn)生了「領(lǐng)地意識(shí)」的可笑觀念），甚至與團(tuán)隊(duì)其他決策產(chǎn)生沖突，影響合作效率。而如果這個(gè)設(shè)計(jì)是依據(jù)某個(gè)事實(shí)結(jié)論得出的，那么這些質(zhì)疑便也不足為懼了，設(shè)計(jì)師也能更好地與其他人協(xié)同工作。

所以，以事實(shí)為依據(jù)的設(shè)計(jì)是我們追求的目標(biāo)。但是在實(shí)際執(zhí)行中，我們會(huì)發(fā)現(xiàn)設(shè)計(jì)師獲取事實(shí)依據(jù)的資源非常有限。已掌握的數(shù)據(jù)和信息很多時(shí)候并不足以對(duì)一個(gè)新的需求提供充分的依據(jù)，在前期進(jìn)行嚴(yán)謹(jǐn)?shù)挠脩粞芯亢蜏y(cè)試又會(huì)耗費(fèi)過多的時(shí)間。

那么在整個(gè)過程中，我們?nèi)绾胃咝У厥占聦?shí)依據(jù)呢？

受軟件開發(fā)中 Test-driven Development 的啟發(fā)，我想到了一種激進(jìn)的設(shè)計(jì)過程，叫做?Test-driven Design，可供嘗試。

在傳統(tǒng)的設(shè)計(jì)方法下，設(shè)計(jì)師會(huì)花很多的時(shí)間在自己的方案上。但 Test-driven Design（測(cè)試驅(qū)動(dòng)的設(shè)計(jì)）需要我們逆轉(zhuǎn)思路，將 90% 精力轉(zhuǎn)到尋求事實(shí)依據(jù)的過程上，將剩下的 10% 用于快速迭代方案，做到零糾結(jié)、零爭(zhēng)論，將時(shí)間省下來放到多方案、迭代和驗(yàn)證上。

## 用最短的時(shí)間做原型

我們的目標(biāo)是用盡可能短的時(shí)間構(gòu)建一個(gè)最小可用化原型（Minimal Viable Prototype，由精益創(chuàng)業(yè)的理念啟發(fā)），以便在設(shè)計(jì)驗(yàn)證中使用。千萬不要在這個(gè)階段輸出完整的、包含所有細(xì)節(jié)的文檔性方案（即使這樣看起來會(huì)比較「專業(yè)」）。

How to do?

1. 首先要快。使用自己最擅長(zhǎng)的工具，維護(hù)一個(gè)高復(fù)用性的個(gè)人模版庫，建立效率最高的 workflow 和工具協(xié)作體系，保持設(shè)計(jì)文件內(nèi)部的干凈和組織性（例如：Visio 的元素分組、PS 和 Sketch 的層次和圖層命名），以便后續(xù)的快速迭代修改。
2. 遇到自己不能確定的設(shè)計(jì)點(diǎn)，或者與其他人有不同意見的設(shè)計(jì)點(diǎn)時(shí)，首先尋找是否有已有的數(shù)據(jù)和事實(shí)支持。若沒有，則避免過多討論，快速輸出多個(gè)可行方案，然后準(zhǔn)備投放到下一步驟的驗(yàn)證過程中。避免任何雙方都無法被說服的爭(zhēng)吵，事實(shí)依據(jù)才是解決一切的鑰匙。
3. 站在客觀的角度，避免「自我參考」或者「老板參考」的設(shè)計(jì)。時(shí)刻提醒自己：「我所知道、所觀察到的，并不一定是對(duì)的」。
4. 避免過度深入地探究未確定的細(xì)節(jié)。要記?。含F(xiàn)在需要的并不是一個(gè)完整的方案文檔，而只是一個(gè)用于測(cè)試和驗(yàn)證的原型。過于精細(xì)可能是有害的，這點(diǎn)需要設(shè)計(jì)師通過主觀的判斷去平衡。

在我的經(jīng)驗(yàn)中，通常交互設(shè)計(jì)可以在1-2小時(shí)內(nèi)完成多方案原型的快速構(gòu)建。對(duì)于小規(guī)模的需求，這個(gè)時(shí)間可以被縮短到分鐘級(jí)別。對(duì)于視覺設(shè)計(jì)，耗費(fèi)的時(shí)間會(huì)久一些，但最長(zhǎng)不要超過一個(gè)工作日。

原型最好是動(dòng)態(tài)的、可操作、高保真的。不過這也視具體的需求而定。

## 邊做邊驗(yàn)證

設(shè)計(jì)師需要接觸數(shù)據(jù)、專家和用戶，對(duì)多方案的質(zhì)量進(jìn)行驗(yàn)證和評(píng)估。設(shè)計(jì)驗(yàn)證需要穿插在方案過程中，作為對(duì)方案的即時(shí)的有力支持。

數(shù)據(jù)搜尋是最簡(jiǎn)單的獲取事實(shí)依據(jù)的方法，能夠解決很多糾結(jié)點(diǎn)。設(shè)計(jì)師應(yīng)有一定的數(shù)據(jù)分析能力，熟悉自己產(chǎn)品的后臺(tái)數(shù)據(jù)系統(tǒng)，并且經(jīng)常去那里尋找有用的信息。

我們可以使用成本最低的啟發(fā)式評(píng)估（Heuristic Evaluation），通過專家和設(shè)計(jì) leader 對(duì)方案進(jìn)行篩選和建議。啟發(fā)式評(píng)估能給設(shè)計(jì)師一個(gè)公開解釋和辨析方案的過程，并且能發(fā)現(xiàn)一些可能忽略掉的要素。

但啟發(fā)式評(píng)估依然是主觀的。在很多時(shí)候，我們依然需要客觀的用戶研究方法。這些用研方法之所以可行，是因?yàn)槲覀儗⒃瓉碛迷诩m結(jié)方案細(xì)節(jié)、進(jìn)行無效討論的時(shí)間節(jié)省了下來。

1. 使用快速、低成本、易執(zhí)行的用研方法，例如用戶訪談、原型測(cè)試等。
2. 需要以對(duì)比的方式去執(zhí)行用研和測(cè)試，不僅可以對(duì)比設(shè)計(jì)師的多個(gè)方案，也可以對(duì)比競(jìng)品。
3. 測(cè)試要圍繞著有與需求目標(biāo)緊密相關(guān)的針對(duì)性指標(biāo)進(jìn)行，例如：某個(gè)流程耗費(fèi)的時(shí)間、某個(gè)分支的短時(shí)間PV統(tǒng)計(jì)等等。方案在針對(duì)性指標(biāo)的表現(xiàn)能夠作為直接的決策依據(jù)。

在設(shè)計(jì)驗(yàn)證完成后，利用得到的事實(shí)依據(jù)修改、精化方案。如果方案內(nèi)還有分歧點(diǎn)，那么就進(jìn)行一輪小型迭代，準(zhǔn)備下一次的設(shè)計(jì)驗(yàn)證。每次的設(shè)計(jì)驗(yàn)證應(yīng)該越來越輕、越來越快，直到分歧點(diǎn)全部被消滅，我們就得出了理想的方案。這就是 Test-driven 的快速迭代過程。

Test-driven Design 與傳統(tǒng)的設(shè)計(jì)方法不同的地方在于：方案不再是用研的目的，相反，用研是方案的目的，就像編程中的 Try & Catch。方案是工具，不是目標(biāo)。目標(biāo)是掌握事實(shí)，得到整個(gè)需求在用戶體驗(yàn)層面的 insight，方案不過是在這個(gè)過程中的附屬品。

## 長(zhǎng)期研究

既然我們已經(jīng)把眼界從方案的層面提升到 insight 的層面，那么我們就能看出：設(shè)計(jì)師的工作并不是一時(shí)的內(nèi)容，而是貫穿在產(chǎn)品生命周期中持續(xù)的工作。

那么在設(shè)計(jì)方案經(jīng)過開發(fā)實(shí)現(xiàn)并發(fā)布后，我們還能做什么呢？

1. 觀察數(shù)據(jù)，看看之前得出的設(shè)計(jì)方案是否成功？如果沒有成功，反思是哪些元素導(dǎo)致的？這些元素是產(chǎn)品上的，市場(chǎng)上的，還是其他方面的？
2. 開始從各種渠道進(jìn)行長(zhǎng)期用戶研究，如：A/B 測(cè)試、數(shù)據(jù)觀察、路徑分析、用戶反饋、社交媒體輿情等等。
3. 試著發(fā)現(xiàn)新的問題！

在整個(gè)過程中，我們所做事情的核心在于：對(duì)產(chǎn)品和用戶形成越來越完善的 insight。每一個(gè)用研、每一次辨析，都會(huì)讓我們對(duì)產(chǎn)品的 insight 加深一分，都會(huì)讓我們對(duì)需求和方案的把握加強(qiáng)一分。

## 總結(jié)

我們發(fā)現(xiàn)：有了足夠的事實(shí)依據(jù)和 insight，方案只是順其自然的結(jié)果！這就是 Test-driven Design 最強(qiáng)大的一點(diǎn)：這不僅是一種設(shè)計(jì)方法，而是一套機(jī)制，讓設(shè)計(jì)師產(chǎn)生 insight，讓解決方案順其自然出現(xiàn)的機(jī)制。所以我們也可以稱其為 Insight-driven Design。

這是一個(gè)初步的、激進(jìn)的想法，尚未通過實(shí)踐驗(yàn)證。但現(xiàn)在的設(shè)計(jì)師們需要快速對(duì)陌生領(lǐng)域建立認(rèn)識(shí)，需要邊打邊走、邊做邊學(xué)的自我更新和協(xié)同心態(tài)。傳統(tǒng)的、以方案為核心的方法已經(jīng)不再適用了。而 Test-driven Design，絕對(duì)是一種值得嘗試的工作方式。

本文整理自：知乎問答，轉(zhuǎn)載請(qǐng)注明原作者@吳亮