本文作者結合自己的經驗，總結了產品從0到1設計過程中的一些反思，與大家分享，希望可以給大家一些啟發。
2015年的夏天，我以實習生的身份來到現在的這家公司。剛到公司時，我在一個已經比較成熟的部門項目下做著用戶研究的工作，直到有一天，領導讓我做一個關於XX的競品分析報告。當我找遍資料寫完報告交給老闆時，雖被領導找出了一千個不足之處，但一番「痛罵」教導後，對我說「1.0的需求原型、周五前給我個初稿」。我好像一個毛頭小兵，突然被委以重任，便開啟了從0到1的產品設計之路。
在這個項目中筆者參與了iOS端APP以及PC官網、後臺的設計，那麼我著重會以iOS端APP的產品設計進行舉例分析。
關於如何收集與整理用戶需求、如何繪製原型、如何寫一份優秀的需求文檔，網絡上優秀的乾貨文章不勝枚舉，在此筆者不再贅述。
值得一提的是，對於需求文檔的撰寫，我並不注重偏形式化的東西，文檔的命名格式以產品名/功能名_版本號_撰寫日期即可，一份需求文檔則是一款產品，那麼開發人員則是使用它的用戶。如何讓用戶體驗好，才是產品經理在撰寫文檔時更應該注意的。
一份需求文檔可能會被前端開發、API開發、後臺開發、測試等不同的技術人員閱讀，在文檔中應該體現針對不同角色而對應的不同閱讀模塊。簡單來說，ios開發需要閱讀文檔中的整個功能需求模塊，而PHP開發只需要閱讀所需接口需求模塊，因為對於PHP開發來說，如何實現一個翻頁操作是他毫不關心的。在文檔中，針對不同角色分段說明，開發能明確知道自己的開發任務、閱讀體驗更好，也能有效提高開發效率。當然，內容條理、邏輯清晰是需求文檔的基礎。我也經常會問開發，你需要什麼樣的需求文檔？開發說「我可以完全按照你的需求文檔開發，不需要再做任何思考」。那這其中要求的是產品經理將各方面考慮詳盡，但在實際操作中，產品經理難免也會有遺漏之處。
在1.0原型初稿出爐之後，我面臨了職場的第一次鄙視，來源於隔壁組支援的UI設計大兵。我仍記憶猶新，在個人中心頁面上，有一個登錄及我的訂單入口。而我居然遺漏了未登錄狀態下點擊我的訂單入口時的情況。這幾乎對所有產品經理來說，是一個不可能犯的錯。我被大兵鄙視了一番「你這原型畫的，我都沒心情設計」，這也著實給了我一次較沉重的打擊。事後我一直在反思，怎樣才能讓自己在做需求設計時考慮的更全面呢？
思維導圖是一個非常簡單但極其有效的幫助思考工具。在思維導圖中，你可以將產品的功能進行分類再分類、深入到每一個細枝末節。它不僅能幫助你深入思考、而且記錄下思考過程。在繪製原型時你可以遵循思維導圖進行設計，儘可能避免遺漏任何一個枝節，而流程圖的繪製對於頁面操作交互、流程的設計十分有利。我們所期望的是用戶能夠在我們的產品中進行轉化（註冊、下單等），那麼要求所設計的任何一條路徑都是能夠通向目標的，如果在流程圖中發現有一條走不通的路徑，那這裡的問題就是產品經理應該去考量的。
0與1、和1到多法則指的是思考時應該針對每一個頁面或功能分析它的對立面和多種情況。有人就會說，「如果我真的能考慮到多種情況，那就不會出現遺漏了」。讓每個人都能考慮所有情況不是一件容易的事，而我這裡想說的是你需要培養自己的思維模式。在設計事，按照0與1、1到多的步驟去進行思考每一種情況，不斷地鍛鍊加強的自己的思考能力。
在產品設計中的遺漏和出錯對於產品經理來說，總歸都是一次經驗教訓，失誤之後的分析和總結是必不可少的。而最基本的要求是不能在同一個環節步驟設計上失誤兩次。
在經歷了產品評審、技術評審會議後，1.0需求在修修補補後終於塵埃落定，提交給技術大哥們進行開發了。在研發階段，我也必須要完成後續一系列的工作。
在技術評審會議結束後，我將產品的功能模塊拆分成一個個小的任務，然後以表格形式下發給技術人員，技術人員各自在每個任務後填寫對應的開發周期及開始時間、結束時間；在安排前後端開發時，能夠根據開發需求調整任務的先後順序，得到一個較為合理的排期。
在產品開發過程中，溝通是必不可少的。所以在產品開發之前，產品經理與開發人員需達成共識：在需求文檔不完善或有疑問的情況下，開發人員需要主動與產品進行溝通；而在需求發生變動的情況下，產品經理也需要第一時間告知開發人員。
而我深感在實際開發過程中，經常會出現一種「我以為我說的，別人就能明白」的溝通方式。這種先入為主的思想，會使訴說方的措辭表述不清，傳達的信息不準確，繼而影響問題的解決。
常見的錯誤溝通方式有：
這句名言中指出的另外一個問題是：產品經理是需要了解產品功能的實現過程的。舉個很簡單的例子，修改文案。對於網站來說，可以在代碼中進行修改、發布上線；而如果在開發前產品經理進行要求該文案是可以通過後臺進行編輯操作的，那麼運營人員直接可以自主修改並發布文案。對於移動端應用來說，如果是在接口中寫入的信息，那麼可以通過修改接口中內容達到目的。而如果該文案被開發寫死在客戶端中，那這一個簡單的修改文案是需要通過重新發版本才能完成。這時候產品經理就該燒香拜佛祈禱這個文案並不會對產品有太糟糕的影響。所以，產品經理對於實現方法的把控也至關重要。
在技術人員緊鑼密鼓的進行開發工作時，我也開始著手準備下個迭代版本的需求原型。在1.0的需求當中，我僅僅是優先實現了基礎功能，而忽略了數據的投遞工作。在領導的提醒後，我開始研究如何做APP的埋點設計。
數據統計一般分為兩個方面，一方面為基礎數據例如新增人數、啟動人數、活躍人數、用戶留存等，還有崩潰率（很重要）；另一方面則為衍生數據，頁面的瀏覽人數次數、操作的人數次數、頁面轉化率等。我採用的方法便是，列出所有的功能頁面、操作按鈕、加入人數和次數兩個指標，直到現在我還是這樣做的。
當我正在電腦前構思1.1版本的需求原型時，領導問我「APP發布上線的資料準備的怎麼樣了？」
當然是提交APP到應用商店的審核資料。
App store開發者帳號或安卓應用商場帳號的申請
因公司而異，有些公司是需要產品經理/運營去申請開發者帳號的；申請APPstore的開發者帳號流程較慢，需要提前進行申請，切勿版本開發完之後才一拍腦袋發現帳號沒申請！具體的申請流程可百度查閱。
應用截圖
在1.0快上線的最後幾天，我才發覺還沒有應用介紹頁的設計圖。於是，我只能帶著一杯奶茶求隔壁組UI大兵加加班。應用截圖一般是尺寸1242*2208、png格式的3~5張圖片，在APPstore中針對不同尺寸只需上傳一個尺寸的文件通用即可。
應用介紹（內容提要）
應用介紹是用戶對產品的「第一印象」，簡明扼要的告訴用戶為什麼我們的產品比別家的要好。在APPstore中展示時僅展示前五行內容，需要用戶點擊更多後才能查看完整內容，所以前五行的內容相對比較重要。而在具體內容的撰寫上，我有以下幾個建議：
ASO優化：
當領導跟我說ASO的時候，我是懵圈的。我默默的百度了一下，「ASO是手機應用商店優化的簡稱，是提升你APP在各類APP蘋果電子市場排行榜和搜索結果排名的過程。」在這個方面，我一般是藉助了ASO優化相關的工具。通過工具分析調整關鍵詞和應用名稱，提高APPstore的排名。
值得注意的是，APP store經常會發布相關APP審核的最新規則制度，例如最近的禁止使用熱更新以及應用名稱禁止出現「免費」字眼，產品經理都應及時關注並調整應用的相關內容。
2016年1月6日是這款產品上線APPstore的時間，至今為止已更新迭代15個版本，每個版本的研發周期在1個月左右。其中四月份到六月份，我回學校進行了畢業答辯。
在整個產品研發、迭代期間，我會將每一次版本的開發周期、上線的時間以及其中發生的事件（服務端客戶端bug）均記錄在工作本中。
很感謝領導能夠讓我參與到這個項目中來，從一開始的我和領導到現在線上開發團隊也已有二十來號人。還記得在項目剛開始時，我每天下班之後也要盯著工作群，生怕領導在群裡艾特我，說哪裡出了問題。那段時間頭髮都掉了好幾根。壓力大，責任也大，成長得也越快。
謹以此篇寫給還算努力的自己。
作者：一顆南星，產品汪。微信公眾號：一顆南星
本文由 @一顆南星 原創發布於人人都是產品經理。未經許可，禁止轉載。