產品設計的環狀循環

• 原文地址：The Circle of Product Design
• 原文做者：Francesca Negro
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：Ryden Sun
• 校對者：ryouaki Starriers

產品設計的環狀循環

In All Its Freudian Glory

咱們只是簡單的從A點走到B點，有時候都會變得混亂不已 —— 會考慮這條路是否是對的，咱們走得是不是正確的方向，若是咱們走捷徑又會怎樣等等這些問題。 但當A點是一個用戶問題並且B點是一個實現的功能，這就像你用一張舊地圖和一個壞的指南針在大海里航行。 這就解釋了爲何按照一個嚴謹的流程 —— 即使時間很緊張 —— 也會是通往B點的關鍵因素，並且有着最多的信心和儘量的與解決方案相關的數據 —— 而且 —— 會讓之後的相同的工做變得簡單一點（也爲了之後的迭代創建詳盡的文檔）。

---

文章中全部的過程都是 Freudian glory(弗洛伊德學說風格)（全部的插畫都是我畫的）

---

1.理解問題

問題也是須要被理解的。

首先，這個需求是如何被提出的？這是一個顧客的需求，是一個CEO的點子仍是一個實現願景的藍圖？理解需求從哪裏提出的，不管它是在 Jira 上，或是郵件裏，或是貼子裏，這是最重要的。從用戶的附加解釋中，辨別出那些真正觸發需求的問題一直都是困難的，而且是容易忽略的（讓咱們來面對它，減小時間的消耗）。

回溯到最開始的被觸發的想法， 意味着須要確保咱們設計的出發點是一個真實的問題，而且不是一個可能的解決方案。

從顧客關愛部門，CEO，首席產品官他們那裏獲取他們的想法，不管是誰 —— 就像產品設計的 Sigmund Fredu —— 深挖這些想法直到你找到來源，那個激發需求的最初始的事件。

2.調研問題而且收集數據

調研這個問題是解決方案的一部分。

第二步意味着會變得很擅長打擾別人和搜索東西。一旦定位了那個事件（多是童年的心理創傷或是客戶的抱怨），那就是時候儘量多獲取這個問題的信息了。 其餘人是怎麼處理這個問題的呢？這是一個廣泛的仍是特殊的問題？咱們有辦法把這個問題分解成多個小問題嗎？而且，最重要的，收集這個問題的數據。

即便咱們在討論一個全新的功能/或是產品還處於開發狀態，仍是會有相關的（某些程度上）度量方法來使用的。若是是對於一個已經存在的功能進行提高，他 應該 是容易從分析中收集數據的或是 應該 有任意的度量方法能夠被執行的。

3.從新構想這個問題

Blue steel ™.

根據目前全部的信息，對於問題和其存在於的背景應該比較容易的有一個更清晰的認識。 從新定義這個問題意味着須要從不一樣的視野和角度看待它（看一下 J.W. Getzels 在「Problem of the Problem」的工做和其創造性的問題解決），所以在收集過程當中，從任何之前的偏見或者解釋來破壞他的行爲均可能會被加入。 因此，當最初的需求多是「咱們須要一個功能容許餘額太低時轉帳給用戶」（這就是一個需求包含解決方案的例子），促使產生這個需求的問題多是「轉帳給用戶太耗時並且須要不斷地查看餘額」。 這個問題的從新定義打開了通向解決方案的新道路（執行一個調度程序，亦或是餘額太低時自動提醒）。

4.設計解決方案

Vitruvian 解決方案。

問題如今已經成功定位，並且數據是能夠被投入到更普遍的產品背景中的。如今是時候把解決方案構建爲「決定這些方法中哪一個方法更適合解決這個問題」。出於這個目的，它能夠適用於一系列問題：解決方案中應該有哪些功能 —— 「用戶應該可以設置自動提醒嗎？」 「用戶應該可以引入事件嗎？」 —— 而且創建一個可能的解決方案實現列表。 目的是減小選項，造成一個能夠用原型來測試的設想。 既然目的是測試這個設想，原型應該是理想化的以設想爲中心，是從全部修飾和不必的細節中剝離開來的，這些修飾和細節可能會在測試中讓用戶分散注意力。 在這一步，若是能和開發者或是任何將參與到過程當中的人（如，整個設計團隊，客戶關心部門）進行交流就理想了，這樣能夠收集他們從自身角度出發關於解決方案的見解了。

5.測試解決方案

「我想知道爲何他們讓我作一個數學測試」。

依靠現有的可用資源和時間，用戶測試一直都是有挑戰性和有必要性的。

即便資源不多，時間很緊，測試一個能表明大部分產品用戶的用戶樣本是十分重要的，這更比測試一大羣沒有表明性的樣本重要（參照 1936 年的 Literary Digest 案例）。

進行記錄 —— 或者更好的辦法是進行錄音 —— 這是最詳盡的辦法來更方便的在一個用戶體驗研究員的幫助下進行訪談的總結（若是可能的話，或者至少有另一個能夠記錄的人），爲了能同時保證記錄的質量和訪談的活躍度。

6.實現解決方案

不適合3歲如下的小孩。

目前爲止，設想被驗證了沒有？若是已被驗證，什麼是設計方案的痛點和長處？假設全部都進行順利（設想被驗證而且幾乎沒有痛點），這個原型應該變成真實的屏幕顯示出，同時需求須要傳遞給開發者們。爲了給將來迭代鋪設道路，一個強制性的任務是定義哪些是功能點的KPI和績效指標，這可能須要別的團隊成員（市場人員，後端和前端開發人員）的幫助。

若是設想沒有被測試，那就有必要回到以前的設計解決方案步驟，甚至是從新審視問題自己而且從新開始。

當設計一個複雜的解決方案時 —— 最有可能的是對於一個複雜的問題 —— 一個可能的策略是從實現解決方案的最簡單版本開始， 接着不斷增長複雜度最後發佈。

7.運送這個功能

Arrrrrrrr!（語氣詞，相似啊啊啊啊啊啊）

好吧，這是很明顯的。 趕快把他發佈出去讓世界知道他發佈了。

8.密切關注功能點的成功

它有達到最好的效果嗎？

若是全部事情都進行無誤，如今應該能夠收集度量數據了。 去客戶關愛部門，告訴他們目前正在進行的功能的關注點，而且爲用戶反饋設置一條特權通道，這些反饋包含新功能的全部方面，這也是一個很好的監測進行狀況的注意。

9.解決方案有解決問題嗎？

解決方案也須要理解。

功能已經發布並且用戶已經使用了一段時間（幾周或者幾個月），根據流程和其餘問題，如今是時候問一個問題：大多數用戶有發現問題被這個方案解決掉了嗎？

在理想的世界裏，咱們會舉辦大型的舞會和聚會來慶祝解決方案那簡約而又燦爛的美麗，世界上的饑荒也會僅僅存在於記憶力，由於咱們這個功能的問題解決能力。

現實中，不是每一個人都會滿意（用戶和/或隊友），別的問題也會出現，也多是時候解決商業上的一些問題 —— 忽略整個過程 —— 咱們可能會沒法完成咱們的目標。 所以，讓咱們在過程當中保持信心，不斷地從新開始（帶着更多的內省）。

---

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。