大家都很清楚，互聯網產品功能開發出來只是開始，不斷的運營迭代才是關鍵。產品設計之前，除了我們常說做的市場調研、競品分析外，條件允許的情況下盡可能在設計前期接觸用戶，了解一手需求并做梳理分析很重要。產品設計過程中上除了考慮交互、功能和流程，還需要思考該功能上線后如何積累到需要的數據，為產品迭代提供指導依據，否則很容易陷入經驗主義，走偏方向。產品上線后，定期的看數據、解讀數據，形成潛意識的習慣很重要。
產品工作沒有成型的套路可以復用和一成不變，相信每個產品人都是在不斷摸索和調整，包括我自己，下面結合實際的經驗，梳理和分享一些設計觀點。
觀點一：點、線、面，逐步分析完善需求。
點：大的需求如建一個平臺，小的需求如優化某個功能點，不論大小，在開展產品設計時，可以圍繞存在的這個需求點做調研、分析和思考，定義出這個點的需求是什么、解決用戶在什么樣的場景下的哪些痛點。如：我們在設計一個門戶改版時，通過用戶反饋、后臺數據、競品調研來思考是否需要改版、改版解決用戶哪些重點的問題。
線：關注需求點和外圍業務單元的關系，平臺也好、模塊也罷，它們之間肯定存在某種業務關系并在某種業務環境下為用戶提供服務，將各個需求點串聯起來，思考都有哪些用戶會在這些串聯的點上發生互動。每個需求點的業務變動會關聯影響哪些其他需求點、對這些用戶會有哪些影響。如：我們在設計一個接口需求時，除了解需求本身，還要了解接口外圍的交互對象都有哪些、這些對象之間的關系是怎樣的，以便于更好的設計需求的解決方案。
面：需求點的線條梳理完成后，將設計思路放在產品組織結構的各個環節上去審視，如：產品設計對市場、運營小伙伴帶來多少業務價值（提升用戶量/降低運營成本）、對技術、測試小伙伴帶來哪些技術挑戰和技術價值（可能的技術困難點/技術架構的優化改進）、對UED小伙伴帶來哪些亟待解決的體驗痛點（界面不好用/不會用）、對周邊產品團隊帶來的業務價值，通過這層審視，將需求從用戶、產品關聯到組織架構，全面思考需求的價值。
觀點二：解決方案有多種，需求只有一個。
需求了解清楚了，著手設計需求的產品解決方案，設計完一種解決方案后，自認為完美無缺、實則還有其他方案可以替代。尤其當解決方案涉及的點較多、業務交互較復雜時，思考出來的解決方案很容易潛意識當成唯一的解決方案，不愿意繼續思考其他方案，導致陷入其中，無法跳出來。建議思考完一套解決方案，暫停休息、轉換思維，反問自己是否有其他方案可以來實現這個需求，和小伙伴交流溝通。
觀點三：自動化只是一種手段，不是目的。
經常看到一些產品推出一鍵下單、一鍵開通等功能，前臺的極致體驗對中后臺的設計提出了要求和挑戰，產品設計人員往往會不自然地追求這種極簡方式，但回歸到用戶、還原用戶的場景，發現有些時候，產品的自動化必須搭配人工參與的方式一起來完成，如有些用戶在使用產品的過程中，會有一些線上線下的場景交互，需要在設計上做停頓和用戶參與。
觀點四：界面簡潔和流程清晰，可以共存。
不論是面向C端還是B端、消費者還是服務提供商，只要是人在用產品就會有對產品界面信息展示和流程操作上的一些痛點需要我們去考慮和設計，界面數據的展現方式需要基于業務需求來設計流程（如是否展示正式數據和過程中數據），界面數據的組織方式需要基于現實場景來設計交互方式（如商品數量不大的情況下是按頁簽分開展示還是在一個頁面全部展示）
觀點五：數據設計和功能設計，同樣重要。
產品需求分析和設計過程，對系統和功能的設計，很多設計者容易在較快時間內上手并達到熟悉和熟練，但對數據設計的思考卻相對滯后甚至沒有去思考，產品上線后，不清楚產品功能對用戶的感知如何、是否為用戶提供了較好的服務，導致產品后續迭代沒有一個相對客觀的指導意見。所以，不論是什么形態的產品、門戶端還是中后端，在做系統和功能設計時，迭代的思維同時運用到數據設計上，如先期設計將數據落在產品庫中，上線之初可以請技術伙伴人工定期給導出業務數據提供給運營或自己分析，后期設計后臺界面給運營伙伴做常態化的數據分析。再如，先期為運營設計數據表格收集用戶意見、后期設計運營后臺界面給運營伙伴做數據錄入和管理。
posted on 2016-05-29 00:47
cheng 閱讀(1168)
評論(0) 編輯 收藏 所屬分類:
互聯網產品