包括但不限于以下的這些清單僧凤。
1. 容易追求完美
一個版本里想要的太多深浮。希望一個版本更新之后收入上去了，活躍度上去了池充，品牌知名度上去了桩引。什么都想要達到是不可能的。一個APP里很多功能收夸，每個功能都是用戶最常用的坑匠，這是不可能的。所以需要保持理智卧惜，分清楚每個版本的主要任務(wù)厘灼。主要任務(wù)優(yōu)先保質(zhì)保量完成，次要任務(wù)優(yōu)先級排后咽瓷，下版本更新也ok手幢。
不要苛求完美。
2.容易陷入細節(jié)
沉浸在交互細節(jié)上忱详、花費大量時間围来。畫線框圖的對齊、圖標(biāo)匈睁、標(biāo)題文案监透、描述、圖片航唆。某個頁面做出一個模板復(fù)用就行胀蛮，不需要做得太細節(jié)。畢竟這是原型糯钙。推敲細節(jié)邏輯
3.溝通不足
以為自己把需求說得很清楚了粪狼。
溝通最大的問題是：雙方都以為對方理解了自己的想法。然而實際上很可能并不是任岸。
其實設(shè)計和需求關(guān)注的東西不同再榄，不一定溝通到位了。原型期間叫上團隊小伙伴一遍遍解說享潜，討論困鸥，調(diào)整。然后根據(jù)討論及時更新原型剑按。把共識用備注的方式進行說明疾就。開發(fā)過程中盡量當(dāng)面溝通倦青。高效~
4.需求變更過于頻繁
最忌諱上線前變更需求
在進入設(shè)計之前多次討論和變更都是ok的纳决。上線了之后，多次調(diào)整風(fēng)格悍缠、架構(gòu)將極大地浪費工程師設(shè)計師的時間猜敢。
5.想得太少做得太多
為什么要做這個功能姑荷，希望達到什么目的盒延，內(nèi)容從哪里來，后續(xù)有沒有相應(yīng)的運營機智厢拭？一個功能想的太少兰英。
6.做重復(fù)勞動不總結(jié)
產(chǎn)品經(jīng)理應(yīng)當(dāng)對自己的工作內(nèi)容也有設(shè)計思維。在做的這些事情供鸠，是不是每次都花費很多重復(fù)勞動畦贸？有沒有更高效的解決方案？可以用問題的方式把日常的問題總結(jié)成一個個清單楞捂，提高效率薄坏。比如上線前的檢查清單。測試時的測試清單寨闹。
7.對團隊成員說“這個需求很簡單”
產(chǎn)品對技術(shù)的評估未必是準(zhǔn)確的胶坠，另一方面顯得不夠尊重工程師。
8.將增加功能當(dāng)作產(chǎn)品提升
保持克制不加功能很難繁堡。
9.工具崇拜
覺得產(chǎn)品經(jīng)理主要就是畫原型的沈善。其實工具只是為了溝通方便的一個媒介。不是會畫原型就很厲害椭蹄。關(guān)鍵的原型背后的邏輯闻牡、品位、視野绳矩。
10.花很多的時間畫高保真原型
切記罩润，幾乎把線框圖畫成了UI圖。
建議黑白灰三色的相框圖基礎(chǔ)上再加一個其他色表示著重點就夠了翼馆。原型的目的是為了方便溝通割以，高效是首要考慮的。加上色彩应媚、加上設(shè)計細節(jié)一個是浪費時間严沥，另一個會限制住設(shè)計師的思路。不利于發(fā)揮珍特。
11.產(chǎn)品邏輯混亂沒有形成閉環(huán)
還是那句話祝峻，邏輯，邏輯扎筒，邏輯。用戶從哪里來酬姆，到哪里去能否走通流程嗜桌。在不同流程、場景上是否有相應(yīng)的提示或者反饋辞色。反饋以什么樣的形式讓用戶比較舒服骨宠。等等。都是需要考慮的。
主場景层亿、次要場景的分解桦卒，以及相應(yīng)的處理方案需要反復(fù)推敲。
12.未經(jīng)思考快速給出答案和處理方式
例如需求變更(沒想清楚匿又、考慮問題不全面)方灾。收到用戶反饋的問題后，可以給出臨時解決方案碌更，但是切記直接修改代碼裕偿。每一個功能的迭代都應(yīng)該考慮清楚了再做。解決小問題時的修改未必是適合所有場景的痛单。
其他想到再補充吧
