中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

笑天涯說：做產品的過程中，不可避免經常遇到改交互的情況，設計師們，你們有沒有遇到提需求相當隨意的產品經理呢？

知乎提問：產品經理提需求太隨意，老讓設計試試怎么辦？

問題補充：經常遇到一個這樣的問題：

1，產品經理提出好幾種交互方案，說要全部做出來放到線上快速測試看效果。

2，交互設計師和視覺設計師針對他的想法一一做了相關分析并且反饋最終建議的方案，但是產品憑借自己的主觀感受堅持自己的方案，或者所有的都實現，找理由說要“小步快跑，快速試錯，多做幾種方案試試看”。

3，但是我覺得這樣很浪費資源啊，而且覺得產品經理很不負責，我會讓他們提供相關的數據和證據來支撐他們的需求，但是他們提供不了我也沒辦法否掉這個需求；

——————-

不要光評論對錯或者只是噴PM，說說你覺得作為當事人應該怎么辦？

知乎用戶@吳亮的回答：

看了一下其他答案，好像都不太到點。題主的問題應該是在交互層面，對方案中的某些要點，產品經理和設計師都沒有充分的客觀依據去證明其合理性，而產品方面要求進行多方案的測試，這個時候應該怎么做？

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

在此把全文貼出來。有點長，湊合著看（原文鏈接：Test-driven Design）。

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

## 不要說「我覺得…」

很多設計師習慣用自己的經驗和主觀感覺去提出方案，但經驗和主觀感覺很可能是錯誤的。以用戶為中心的設計，需要以用戶心理、用戶行為相關的客觀事實為依據去執行，而非以設計師的「自我參考」去執行。

使用「自我參考」方式的設計師，經常會陷入多個選項的糾結中，這樣會浪費大量的時間和精力。若以事實為依據去設計，我們應該收集足夠的數據、用研和測試結論，并根據這些事實去進行決策。這么做能夠讓我們不浪費時間而做出正確的決定。

團隊成員對設計的討論和挑戰，通常也是「自我參考」方式的。這個時候如果沒有客觀事實為依據，設計師很容易陷入被動的狀態（這讓很多設計師產生了「領地意識」的可笑觀念），甚至與團隊其他決策產生沖突，影響合作效率。而如果這個設計是依據某個事實結論得出的，那么這些質疑便也不足為懼了，設計師也能更好地與其他人協同工作。

所以，以事實為依據的設計是我們追求的目標。但是在實際執行中，我們會發現設計師獲取事實依據的資源非常有限。已掌握的數據和信息很多時候并不足以對一個新的需求提供充分的依據，在前期進行嚴謹的用戶研究和測試又會耗費過多的時間。

那么在整個過程中，我們如何高效地收集事實依據呢？

受軟件開發中 Test-driven Development 的啟發，我想到了一種激進的設計過程，叫做?Test-driven Design，可供嘗試。

在傳統的設計方法下，設計師會花很多的時間在自己的方案上。但 Test-driven Design（測試驅動的設計）需要我們逆轉思路，將 90% 精力轉到尋求事實依據的過程上，將剩下的 10% 用于快速迭代方案，做到零糾結、零爭論，將時間省下來放到多方案、迭代和驗證上。

## 用最短的時間做原型

我們的目標是用盡可能短的時間構建一個最小可用化原型（Minimal Viable Prototype，由精益創業的理念啟發），以便在設計驗證中使用。千萬不要在這個階段輸出完整的、包含所有細節的文檔性方案（即使這樣看起來會比較「專業」）。

How to do?

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

在我的經驗中，通常交互設計可以在1-2小時內完成多方案原型的快速構建。對于小規模的需求，這個時間可以被縮短到分鐘級別。對于視覺設計，耗費的時間會久一些，但最長不要超過一個工作日。

原型最好是動態的、可操作、高保真的。不過這也視具體的需求而定。

## 邊做邊驗證

設計師需要接觸數據、專家和用戶，對多方案的質量進行驗證和評估。設計驗證需要穿插在方案過程中，作為對方案的即時的有力支持。

數據搜尋是最簡單的獲取事實依據的方法，能夠解決很多糾結點。設計師應有一定的數據分析能力，熟悉自己產品的后臺數據系統，并且經常去那里尋找有用的信息。

我們可以使用成本最低的啟發式評估（Heuristic Evaluation），通過專家和設計 leader 對方案進行篩選和建議。啟發式評估能給設計師一個公開解釋和辨析方案的過程，并且能發現一些可能忽略掉的要素。

但啟發式評估依然是主觀的。在很多時候，我們依然需要客觀的用戶研究方法。這些用研方法之所以可行，是因為我們將原來用在糾結方案細節、進行無效討論的時間節省了下來。

1. 使用快速、低成本、易執行的用研方法，例如用戶訪談、原型測試等。
2. 需要以對比的方式去執行用研和測試，不僅可以對比設計師的多個方案，也可以對比競品。
3. 測試要圍繞著有與需求目標緊密相關的針對性指標進行，例如：某個流程耗費的時間、某個分支的短時間PV統計等等。方案在針對性指標的表現能夠作為直接的決策依據。

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

Test-driven Design 與傳統的設計方法不同的地方在于：方案不再是用研的目的，相反，用研是方案的目的，就像編程中的 Try & Catch。方案是工具，不是目標。目標是掌握事實，得到整個需求在用戶體驗層面的 insight，方案不過是在這個過程中的附屬品。

## 長期研究

既然我們已經把眼界從方案的層面提升到 insight 的層面，那么我們就能看出：設計師的工作并不是一時的內容，而是貫穿在產品生命周期中持續的工作。

那么在設計方案經過開發實現并發布后，我們還能做什么呢？

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

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

## 總結

我們發現：有了足夠的事實依據和 insight，方案只是順其自然的結果！這就是 Test-driven Design 最強大的一點：這不僅是一種設計方法，而是一套機制，讓設計師產生 insight，讓解決方案順其自然出現的機制。所以我們也可以稱其為 Insight-driven Design。

這是一個初步的、激進的想法，尚未通過實踐驗證。但現在的設計師們需要快速對陌生領域建立認識，需要邊打邊走、邊做邊學的自我更新和協同心態。傳統的、以方案為核心的方法已經不再適用了。而 Test-driven Design，絕對是一種值得嘗試的工作方式。

本文整理自：知乎問答，轉載請注明原作者@吳亮