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

作者以一個錯誤提示問題為例，介紹了他認為比較核心的三類產品思維工具及其在項目中的應用，分別是本質思維、結構思維、系統思維。具體是如何進行的？歡迎感興趣的伙伴們閱讀~

01 前言：關于產品思維的迷思

在業務工作中，我們經常會討論到：處理這個問題你需要運用產品思維；我想要提高一下自己的產品思維……我們知道產品思維是幫助設計師更好地推動項目的重要能力，但當想要進一步學習時，又會發現關于產品思維的各種維度的解析。

什么是產品思維？產品思維是如何在我們設計中發揮價值的？怎樣體現產品思維？怎樣學習產品思維？始終會有些說不清道不明的感覺，缺乏很具體的定義與行動指導。

我自己也在這塊苦惱過，各類資訊書籍一看，怎么有這么多類型的產品思維？大家講的還不一樣。但之后我開始反思，也許不存在絕對定義的產品思維，不同的崗位（產品/設計/產品負責人/業務負責人等）、不同的業務、目標、經歷、認知……不同的人對如何做產品、做設計其實會有不同深度的理解與運用，進而提煉與總結出可以幫助他們更好的「洞察機會、解決問題、創造價值」的思維工具組合，即為他們的產品思維。

所以相對于學習某種產品思維，我們更應該建立自己的產品思維體系，在學習與實踐中不斷補充與提升。

今天的分享，以一個「錯誤提示問題」為例，介紹一下我認為比較核心的三類產品思維工具及其在項目中的應用。

02 本質思維：從表征看病因

某一天，技術同學過來和我提到：“之前的一個錯誤碼只定義了郵件登錄場景下的錯誤文案，現在發現用戶遇到在發送場景下沒有定義的問題，你給個文案，這個版本補充一下？”

當下，我也是直覺的反饋說：“好的，稍后給你。”

但隨后我追問了自己幾個問題，發現并沒有這么簡單：

• 為什么這個錯誤定義會遺漏？
• 為什么之前統一文案的規則沒有生效？
• 還有沒有其他也會在發送場景觸發的錯誤沒有定義？
• 要修改錯誤碼，只能通過發版本的方式嗎？
• 為什么沒有做成實時配置實時生效？

于是我拉著技術又進行了一輪溝通，我們發現，之前的錯誤梳理是分散且單一維度的，即：登錄模塊的產品梳理登錄模塊的錯誤，發送模塊的產品梳理發送模塊的錯誤，而實際郵件登錄、收取、發送等諸多過程中，都需要驗證帳號的有效性，所以部分登錄時的錯誤，在發送驗證時也會發生，而兩個場景下的提示在文案與操作上有所差異，無法單純的復用。由此，原先的問題被重新定義為：

1. 如何完整定義所有的錯誤場景？
2. 如何實現錯誤提示配置的實效性？

就像我們的身體出現了癥狀，需要去醫院檢查，請醫生明確病因后才能對癥下藥。體表顯現的病癥，有時卻是內部系統根源出現了問題的反應，如果僅僅是針對表征進行處理，并不能真正解決問題。

與人體系統相似，產品也是由一系列系統組成運行的。那么當我們發現表現層出現問題的時候，就需要提醒自己進一步思考下問題的影響范圍有多廣？是不是系統底層邏輯出現了問題？比起解決表征的問題，我們更需要去優化引發問題的系統。

問題本質探究的思考方式：

1. 問題溯源：不斷追問why，從根源解決問題，避免復現。追問的方法很簡單，但很多時候是我們忘記問或問的不夠深。
2. 審視目標：重新審視產品目標，明確現狀與目標的差距在哪里，為什么？
3. 回到系統：把問題放回到它所處的系統中去重新思考，找到系統中起決定性作用的核心因素。

03 結構思維：復雜問題構建

重新定義問題后，第一步，我們希望可以收集、梳理完整的產品錯誤碼，并定義其內容。

但是郵件服務涉及多個不同的郵件協議，加上不同產品端（移動、電腦）、不同場景（登錄、發送…）的相互疊加，相關錯誤有幾百個，該如何梳理？

結構化思維方法可以幫助我們：

1. 拆解要素 分類重組

結構化的過程，首先是拆解的過程，分析問題的對象由哪些部分組成，將這些部分拆解出來。再將子項再進一步進行拆解，不斷細分（實現MECE規則中提到的 不遺漏、不重疊的效果）。案例中的錯誤提示便經過了以下的幾層拆分：

第一層：協議，如IMAP、SMTP等；不同協議之間的錯誤碼相互獨立；

第二層：產品端與場景，不同端、不同場景下的提示樣式、內容規則會有差異；

第三層：內容組成，拆分錯誤碼、錯誤提示的組成，如：cause、code、形式、標題、操作等；

拆解后，需要再將這些要素重新分類組合，以便于我們梳理和不斷補充錯誤碼。

此處，我們利用表格工具建立二維管理表：

• 每個Tab是一個協議；
• 縱向是需要梳理的每個錯誤碼；
• 橫向是錯誤信息組成與不同場景下的需要定義的內容；
• 而他們組成的每個單元格就是我們需要完善的內容。

借助此工具，每一個錯誤碼，都有了一個梳理的框架，可以明確需要定義哪些內容，避免場景與內容的遺漏。

2. 提煉共性 建立標準

在拆解梳理的過程中，會發現內容之間會存在一定的相似性與復用性，通過找到這些共性內容，又可以逐步形成一些標準化規則：

• 相似場景的提示形式是否可以統一？
• 好幾個錯誤碼都在描述帳號風險問題，他們的文案提示是否可以復用？
• 一些常用文案，如：確定按鈕是用「確定」還是「好的」，是否可以統一？
• 常用關鍵詞的翻譯是否可以統一，避免后續翻譯混亂？

通過這一步，可以總結和輸出：錯誤提示組件規范、文案規范等標準化工具，一方面是保障用戶體驗的統一性，另一方面也是為后續設計提供參考降低成本。

結構性思考是產品設計中很重要的工具，可以幫助我們將復雜的問題轉化為簡單的行動，將混沌的問題轉化為清晰的描述。

常用的結構化方法：

1. 圖表化：展現復雜問題的結構，幫助更全面的完善細節，也是我在整理信息是特別常用的一種方法。但其難點是在于要將問題拆解充分，最終每個單元格只有單一的「是與否」信息為最佳；
2. 模型化：將問題思考的過程提煉，幫助我們進行更全面的分析與思考，設計常用的分析模型如：用戶體驗地圖、用戶增長模型…
3. 公式化：找到核心變量及其影響關系，明確工作與結果的關系，對于數據結果導向的工作特別常用。

04 系統思維：讓設計動起來

梳理錯誤提示的同時，我們還需要搭建一套系統，以實現靈活配置與實時生效的目標，即：將我們的設計構想進行產品化落地。而此時，系統思考之一，便是關注系統的動態性。

1. 動態適應

“系統能運行多久？”

系統的設計需要滿足動態的需求變化，單以錯誤提示為例，發生變化的情況有很多：

• 雖然希望能夠完整定義所有錯誤，但事實上是比較難做到的，未來的內容新增不可避免；
• 相關方對于服務的調整，有可能會造成錯誤提示的修改要求；
• 提示上線后，發現文案效果不佳，會帶來優化需求；
• 隨著產品能力與技術的迭代，一些過去的內容與操作可能不再適用，需要調整；一些過去的未知錯誤有了新的解決辦法，需要補充…

之前的錯誤提示，是伴隨著每次功能迭代，在設計時定義好，在研發時寫在客戶端，因此造成每次修改都需要發版處理的情況。在優化方案中，替代原先在客戶端管理的方式，將錯誤內容配置放到服務端，客戶端獲取服務端錯誤碼與配置內容進行匹配，展示相應內容：

2. 自動執行

“一定需要提示嗎？”

我們常聽到一句話：最好的設計是「沒有設計」，轉化用在這個項目中卻相對合適，最好的錯誤處理也應該是「沒有提示」。

當我們在專注于梳理錯誤操作內容、設計錯誤操作配置，不妨可以再問問自己：

• 這個提示真的有必要展示嗎？—— 是否可以通過自動重試或其他策略優化，避免錯誤的發生？
• 這個操作真的有必要讓用戶處理嗎？—— 是否可以提供一鍵檢測、一鍵修復的方案，幫助用戶完成一系列的復雜操作？

3. 主動反饋

“你能發現未知的問題嗎？”

前面提到，提示系統的作用之一就是便于后期將未知錯誤轉化為已知錯誤？但是如果是未知錯誤，我們要怎樣發現它們？如何決定哪些未知錯誤需要優先處理？

考慮到這個問題，我們在配置系統外，同時還搭建了一套線上報錯監控系統（雖然還做不到識別高頻未知錯誤主動預警），定期復查高頻錯誤，補充定義新的未知錯誤。

至此，錯誤提示問題的解決方案設計才算告一段落。

郵件系統的錯誤提示有其復雜性與重要價值，借助產品思維工具，避免了掉入「這個問題很簡單」的陷阱，找到問題根源與最佳目標，從復雜繁多的錯誤中找到規律，進行結構化梳理，建立標準，最后建立錯誤提示配置系統、自動化策略、監控機制，為產品的錯誤提示管理建立系統方案，為產品與用戶提供長期價值。

05 結語

有同學會問，如果要搭建這么一套系統的話，投入大時間久，那這個之前的問題就一直放著嗎？

當然不是。在實際工作中，處理問題需要同時考慮解決效率與投入價值。

從處理問題的效率上考慮，最開始的錯誤提示當時也是先及時做了補充的。但是此時，這個文案的補充并非孤立無序的，我們能夠清楚，它將是錯誤信息管理表中的一項重要信息，也是配置系統的一項重要配置，是未來錯誤提示系統的重要一部分。我們并非在零碎的做事情，而是在逐步完善一個產品系統。