起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識經驗分享｜在設計原型時，我的一些所思所想
最近參與一個項目，在前期的討論與規劃中算是一個比較復雜的項目，當我把功能拆分開，定下第一期的要做什么的時候，卻發現已經沒有什么難度了。不經懷疑這段時間自己到底干了些什么……是不是又打醬油了？于是，在這里簡單羅列一下自己在設計原型時候的一些所思所想。本文適讀對象：初級產品經理。
產品經理屬于接力的第一棒，一旦最開始的方向錯了，那么即使UI做的有多出色，開發有多順暢，結果終歸是失敗的。這大概是產品經理這個職位的第一重壓力，在你的設計之后跟隨著是UI、開發、測試多個部門，期間消耗的可不是你一個人的人月。
所以，在接到一個需求任務時，首先要做的不是打開axure 吭哧吭哧的開始畫圖。
第一：明確需求
要搞清楚需求的提出者是誰？服務對象又是誰？
搞清楚這兩個角色，主要的目前就是搞清楚這個需求到底要怎么做。
提出需求的角色會有很多，boss、自己、產品同事、運營、客服……
不同的角色往往會從自身的角度去考慮并提出需求。想要完美解決這個需求，就需要站在同一個角度去看問題，若是角度錯了，設計方案也就偏了。
不同行業的需求滿足的對象也是不同的，to b、to c、to vc……
- 若是對內部人員，就需要優先考慮好內部的操作邏輯，提高使用效率，必要時還需要考慮各種權限控制。至于界面樣式是否好看，并不是一個重點。
- 若是對外的用戶，那么操作流程、交互體驗、不同狀態下的信息反饋，這些都是需要考慮的。
- 若是金融行業，還需考慮營造安全感、風險控制等等。
了解需求的緊迫程度
在接手需求時必須要提前了解好時間節點、緊迫程度，畢竟功能開發不是你一個人的事情。要是時間緊迫，而你又把功能設計的超級復雜，害的開發、測試需要長時間的通宵加班，這鍋可就得你背著了。
舉個栗子：運營MM想要蹭熱點做活動，給你提了一個活動需求。時間緊迫，熱點又不等人，這該怎么辦？
原型設計、UI出圖、前后端開發、聯調、測試……一個功能開發需要經過這么多環節，除開前后端開發還可能并行開發外，其他環節基本都是線性進行的，任何一個環節失誤都會導致整個項目的延期。
所以，在項目前期我們就應該對這些資源的調用、風險的預期，有個大概的認知。倘若加班加點的趕工，最后還是沒在這個時間點上完工，這就比較尷尬了。浪費了大家的時間不說，也很打擊士氣，降低你的影響力。
既然時間這么緊迫，風險這么大，干脆不做好了？
當然可以，這也算是為開發的兄弟們爭取到了喘息的機會。這種情況一般在討論過程中就推掉了，開發人員可能都感覺不到到你做出的貢獻。而你，則成功的在運營眼里打上了“不配合”的標簽，再也沒有運營MM會來找你聊天啦……
那么，究竟該如何做？
我想大家平時都會被叫做產品經理、產品，而不會被叫成“畫原型的”，就是因為我們不僅僅畫原型啊。產品經理不是畫原型的，不是需求的傳遞者，而是需求的解決者，功能設計、原型方案僅僅只是解決需求的一種方式而已。
活動本身有沒有簡化的空間？現有的功能里面有沒有可以利用的地方？是不是可以采用第三方去實現？若是需求本身沒有問題，那么它就應該有解決的辦法。
第二：流程設計
先把流程理清楚再去設計原型，這一點應該算是一種共識了，也就不在這邊贅述了。就來簡單說一說流程設計的好處都有啥：
1、拆解需求，整理思路
接到一個需求之后云里霧里的無從下手怎么辦？畫腦圖、畫流程圖唄，一般產品崗都會要求掌握visio、腦圖這些工具，這些可不是用來湊數的。
梳理流程，將復雜需求拆分成子需求，將子需求拆分成功能點。拆分完成，思路也就清晰了，也許連原型的設計方案都已經有大半個腹稿了。
2、優化流程，減少不必要的返工
我們最開始的想法往往不是最優的解決辦法，最優解總是需要經過多次思考、辯證之后才形成。若是什么都沒理清楚，就草率畫原型的話，等自己想明白了可就得返工重新畫了。
所以，比起后續重新花費精力去返工畫原型，還不如前期多思考、多畫畫流程。
3、直觀，容易表述
現在也有很多原型圖通過連線來表明跳轉流程。這種方式在邏輯不復雜的功能上使用還可以，能夠直接看的懂。若是功能復雜一點，線條多了，自己都不一定搞得清哪跟哪。
流程圖可以作為一個大綱，不至于講著講著就把話題帶偏了，表述的邏輯也相對會清晰些。在需求評審中，先將整體流程講明白，可以流暢的引出詳細的功能說明，也有助于開發人員理解整體項目。
就個人的習慣來說，與設計原型相比，前期的準備、流程的設計往往需要花費更多的時間。（PS：也可能是拖延癥的錯覺）
第三：原型文檔
原型、文檔這兩部分就不刻意拆開了寫了，這兩者的邊界已經變的有些模糊。目前很多PRD文檔都在用axure進行編寫，而axure8更是自帶了一個便簽的控件，用于在原型上添加說明描述。
關于原型繪制工具
目前我接觸的原型主要是通過axure、墨刀去設計的，當然也有使用sketch去畫，更有甚者是直接在excel上畫的。只要能將一個需求表述清楚，就算是畫在白板上也是可以。
是否需要高保真原型？
曾經有人問我axure里面輪播圖的效果怎么實現？
說來慚愧，雖然我一直用axure畫原型，但是對axure里面的功能卻是只學了點皮毛。諸如中繼器之類的，甚至連玩都沒玩過。于是，先問了一句：“這個制作了是給誰看的？”
在我看來，原型的使用對象有兩種：boss、開發人員。若是給boss用來宣講等用途的，無可厚非，原型當然是越精致越好。而我們接觸較多的一般都是開發人員，他們更多關心的是如何實現、而不是盯著原型看動態效果……如何快速的制作、如何將功能說明清楚才是其中的關鍵。
所以輪播圖怎么實現？做再多動畫效果，遠不如將這一塊注明成輪播圖，并寫明輪播頻率、方向。
如何寫文檔？
我一直把產品文檔當做是迷你的產品在做。文檔的主要目的是將一個需求拆解成實際可開發的東西，它的需求就是能夠讓開發清楚的知道該做什么。
寫文檔其實沒有什么固定的規范，幾乎每家公司都會有自己的一套模板，只要能夠讓開發人員看的明白就是優秀的文檔?，F在網絡上可以找到很多的文檔模板，已經提供了豐富的大綱和編寫思路，剩下的就是根據公司的實際情況和流程去做些調整。
下文為我在編寫文檔過程中的一些簡單歸納：
- 文檔中的用詞、描述應該統一口徑，并使用專業名稱。
- 文字描述應該簡潔，不要有冗余的對話。
- 一段描述最好只用來說明一個功能點。
- 通過編號等形式，使文檔有條理，不容易遺漏一些規則。
- 做好版本管理，及時增加修改記錄，保留歷史版本。
完成文檔之后，可以時常接受一些開發人員的反饋，進一步完善編寫方法，畢竟這個迷你產品的服務對象就是這些開發人員。
你是否已經想明白了？
心理學里面有一種叫——墨菲定律，放在這里大概意思就是：自己沒有想明白的地方，最后一定會出問題。
僅管我們畫了原型圖，但這也許只是這個功能的冰山一角，判斷條件是什么、數據怎么處理、異常狀態怎么提示……完整的功能遠沒頁面上顯示的那么簡單。
很大程度上，原型并不是獨創出來的，而是多個app樣式拼湊出來的。在拼湊頁面的同時，就需要考慮對方為什么要這么做？內部有怎樣的操作邏輯？把這些想明白了，才能在評審、開發過程中對答如流，真正實現你想要的功能。
切記不要說：“參考XXX app就好了”，開發人員不是產品經理，你才是。
以上，是一個野生產品經理對于原型的一些不成熟的想法，若有不正確的地方，還望指正。
本文由 @訶息 原創發布于人人都是產品經理。未經許可，禁止轉載。
學習了
寫的通俗易懂，就是錯別字太多。請諒解