起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識畫原型時，經常會漏掉很多的使用場景，怎么改進？
編輯導讀：剛入行不久的產品新人，總是會遇到這樣的情況：盡管自己已經考慮全面，但是總是會在開發的時候遇到各種各樣的問題。畫原型時，經常會漏掉很多的使用場景，應該如何改進呢？我們在天天問和小伙伴共同探討了這個問題，一起來看一下他們是怎么說的吧~
作為產品經理，不是在畫原型就是在畫原型的路上。
而作為一名新人，總會遇到這樣的情況：
畫完原型，評審完，自以為沒啥問題了，但是到前后端開發的時候，還是會出現各種各樣的問題或者自己沒有想到的一些情況。
為什么會這樣？是自己能力不夠的問題還是正常情況？需要怎么去改進？
針對這個問題，我們在天天問展開了一場討論，一起來看看小伙伴們是怎么說的吧~
【天天問每周精選】第146期：畫原型時，經常會漏掉很多的使用場景，如何去改進？
文章內容部分來源于@我愛芋兒雞 @北北北北 @小胖紙 @倉前吳彥祖 @冰雨幻天 @冬至 的精彩回答。
一、從自己入手
拿到需求以后，不要第一時間畫原型，第一步是確認了解需求；在確認了解需求的基礎上進行需求調研和競品分析，競品分析和需要調研完成接著畫功能清單和業務流程圖，最后才畫原型；原型是最后一步也是非常重要的一步，不能急于求成。
產品需求文檔是否考慮得全面，會直接影響到后續的開發進度以及實現的效果。
如果碰上比較嚴謹負責的團隊開發，他們會提醒那些我們忽視的問題。但是很多開發只是按部就班，未提及的細節就默默地處理，或者是不做了，直到我們驗收版本時才發現問題，不僅項目延期，開發對我們的信任感也驟然降低。
以下是容易被忽視的十個細節：
1）默認值
大多數用戶比我們想象中的還要懶，所以需要在涉及到個性化選擇功能時，設置默認選項或者是默認值時，同時滿足小白用戶與專家用戶的需求。
2）上下限
任何功能都需要設置上限值和下限值，避免產品出現失控。
比如說文字輸入限制，發圖片數量限制，就是為了界面整體的協調性，保證文字不會越界，同時考慮是否允許換行，并且最多允許換幾行。超過字數限制后會怎樣顯示，是直接省略還是滾動顯示。
3）誤操作提醒
對于一些不可逆轉的功能，比如說舉報、加入黑名單、清空數據、放棄保存等等，必須要給予確認提醒，防止因為誤操作而觸發該功能。
4）網絡狀況
網絡狀況會影響數據的拉取，所以要考慮在斷網或者是弱網環境下的使用。比如客戶端內置默認圖片，在拉取到數據之前保持界面的完整性，還要考慮到數據緩存機制，減少網絡狀況的不穩定，對產品的體驗影響及時給予用戶網絡狀態提示，并引導用戶重新連網。
5）權限禁用
產品的功能需要調用系統的權限，而一些手機品牌對于權限的限制比較嚴格，所以會出現安裝之后某些功能無法使用的情況。
比如我們的產品需要調用攝像頭權限，而小米在第三方應用中默認禁用這個權限，所以很多小米用戶反饋無法拍照。后來我們添加了權限禁用時的提示彈框，引導用戶去設置里開啟權限。
6）無響應狀態
有一些功能運行時，會占用比較大的內存，對于性能較差的手機就會一直出現在loading界面，用戶只能強制剎掉進程。所以要設計無響應狀態提示用戶程序仍在運行，需要耐心等待，也要給用戶返回上一層的選擇空間。
7）多語言配置
如果你的產品有可能會推廣到海外，那么最好提前考慮多語言配置的問題。為了減少安裝包的大小，必須要精簡資源庫，盡量使用能夠復用的圖片素材減少文字類圖片。分享功能可以使用集成SDK，保證國內海外的用戶都可以使用。
8）規則后臺可控
很多規則在制定時，我們也不能保證說是最佳的。如果把規則寫死在客戶端，上線后數據反饋效果不佳，那么只能通過發布版本來調整，費時又費力。如果把規則做到后臺可控，雖然在開發時會多投入一些工作量，但能夠做到快速靈活的調整。
9）數據統計埋點
要驗證功能上線后是否達到設計目的，就必須通過統計來進行分析，這也是衡量產品經理能力的一個指標?？梢杂糜衙诉@種第三方統計平臺，如果想要更詳細的數據情況，就需要搭建公司內部的數據后臺。比如界面的停留時長，點擊轉化率，用戶路徑等等。
10）運營擴展
產品和運營是密不可分的，所以在設計每個功能時都要考慮到是否有運營擴展的可能，比如限制某些功能的使用需要達成某種條件再解鎖，或者在界面中設計一些預留廣告位，為流量變現做準備。
多看看前輩的文檔，多寫寫通過實操練手。只有踩過才知道哪里是坑，無他但手熟爾。每次工作完成后，多對自己遺漏的東西復盤吧，避免下次再犯同樣的錯誤。
最后，做個原型設計自查表，在自己設計完了之后可以自查一下，看看哪里有沒有問題?；蛘咭部梢栽驮O計完了之后，寫需求文檔，在寫需求文檔的時候再梳理下自己寫的內容。
二、從其他人入手
需求評審所有參會各方未反饋出問題，但實際開展中發現各種問題，這說明除了產品經理外，團隊各個職能的小伙伴都存在可改進之處。
產品：
前期需求調研不夠透徹、業務場景理解不夠深入、邊緣關聯業務了解不足。也就是說，設計的產品方案是沒有形成閉環的或者是細節設計顆粒度不夠。
此外還有一種可能是評審時需求溝通不夠徹底，闡述的需求不夠細致。有些同事不會仔細去看你做的需求，評審會議是他們獲取信息的最佳途徑。也就是說，他們以評審中獲取的信息評估沒問題，不意味著根據需求文檔評估沒問題。
技術：
評審參與度專注度不夠深或者前瞻評估度需要提升。
需求評審的目的之一是技術理解需求內容以評估可行性和開發周期。實際開發中，發現評審時未提出的問題需要去分析到底是什么原因導致，畢竟開發中產生問題會非常影響開發進度且不是一個健康的項目狀況。
其他：
同理，后續開發過程中出現的問題可能是產品向/技術向/業務向，評審中如果還有運營/業務參與，他們也應當擔當一定的方案評估角色。
測試涉及到全需求測驗，對整個產品/技術了解度相當深，正向的團隊測試同學如果在評審中有異議也應該提出。
總體而言，開展過程出現問題產品和技術需做最大反省并為之改進。
三、結語
需求梳理很難一步到位，在任何環節都有可能產生疏漏。畫原型時產生問題也很正常，原型本身也是產品，需要迭代。
產品經理要做的，就是一步步試錯，快速迭代，降低出錯概率。
關于“畫原型時，經常會漏掉很多的使用場景，如何去改進？”這個問題，你有什么想說的呢？一起來聊聊吧~
#天天問神回復#
「天天神回復」是天天問的一個新欄目，致力于發現天天問小伙伴的精彩語錄。抖機靈，大伙兒也是認真的！如果喜歡，記得點擊問題鏈接，和TA一起互動吧，我們也在這里期待你的發言喲~
@夜漫產品：
程序猿分分鐘告訴你什么叫“猩球崛起”
@小小小白：
要運行1+2+3+4，有A, B兩個代碼。
A代碼：1+2=2
B代碼：3+4=8
運行1+2+3+4=A+B=2+8=10，結果正確，皆大歡喜。
有一天一個程序員看到了代碼A，發現了問題，修改A：1+2=3
那么再次運行1+2+3+4=A+B=3+8=11，結果錯誤，而錯誤的B代碼藏得很深，根本找不到。
修改了某一個代碼可能會像蝴蝶效應一樣影響其他代碼，導致大廈傾倒。
淺顯理解，歡迎指正。
@lee：
你想，或者不想，需求就在那里，不增不減。
去找客戶，或讓客戶來你這里，好好溝通，敞亮通透。
我們從不創造需求，更不臆想需求，我們只是需求的發現者、分析者，我們只是需求的轉述者、搬運工。
多一個產品經理不多，但如果少了一個會思考的產品經理，整個世界的效率就又下降一點點。
#相關閱讀#
【天天問每周精選】第145期：知乎VS百度知道，問答產品需要設置“采納”功能嗎？
【天天問每周精選】第144期：除了降價和送禮品，線上促銷還有沒有新玩法？
【天天問每周精選】第143期：看到差評就不想買，那為什么不取消差評？
【天天問每周精選】第142期：明知道用戶不喜歡廣告，為什么還要花錢四處投放？
【天天問每周精選】第141期：直播帶貨主播：銷售導購 or 帥哥美女，應該先用哪個角色亮相？
【天天問每周精選】第140期：眾籌了幾句互聯網情話，我笑yue了
素材來源：天天問話題精選
「天天問」為人人都是產品經理社區旗下的互助問答模塊，致力產品、運營、營銷等領域知識的學習交流。
本欄目由@Darcy 整理編輯發布，歡迎大家踴躍提問，一起交流。
題圖來自Unsplash，基于CC0協議
不錯
但在實際工作中 因為需求是產品的第一步 關系到團隊的開發進度 所以你根本沒有機會去試錯 前期考慮不周全后面沒法給你改 所以大多數都是思考到100%才開始評審 讓開發去操作。
不可能思考到100%的。