? 近來公司為期較長的一期需求終于封包了，這期需求是一個大功能改版，下面對在做本期需求過程中遇到的問題做個總結。這次遇到最大的坑就是關于布局排版方面的。有同學可能會疑惑產品經理為什么還要考慮這個問題，在大公司產品部門崗位分的相對比較細PM、UI、UE、UX，而在小公司產品部一般是由PM和UI組成的，其余崗位的工作基本都是PM來搞，因此事事都要做到了解。

（該篇文章的內容相對基礎，是對自己工作一段時間以來的總結。所以描述的解決方案不一定完全對，算是拋磚引玉了，歡迎更多的小伙伴拋問題~）

本期產品需求和問題

? ??我當前做的產品是黨建類型的，本次大功能改版是增加各會議記錄模板例如三會一課（支部黨員大會、支委會、黨小組會、黨課）、黨日活動、民主生活會等6個會議。每個會議在具體業務邏輯或標題文案方面等各有不同。

梳理需求，解決問題（舉例描述產品排版的通用問題）

梳理各會議之間的關聯性--求同存異：每個會議列表是一樣的，不同的是標題文案或會議業務邏輯，比如參加人員類型，主持人類型等。

坑1--標題文案編寫：設計的會議主題文案不一樣，都分別對應一個不同的提示語（如下圖），導致技術大哥需要考慮各種場景給予提示代碼較凌亂，同時也增加了測試成本。原以為技術大哥每個會議都單獨開發一遍。不是這樣的，否則后期維護會累屎~~技術大哥也是開發一個“模板”，各會議用到什么就從中抽取出來。

填坑方法：在不影響用戶體驗的前提下，標題盡量找共性，將“會議議題”改為“會議主題”，這樣提示語可以共用一個“主題不能為空”。這樣能減少開發測試成本。

坑2--標題內容定長問題：在創建頁內容輸入有無定長，需不需要換行顯示？（如下圖）原以為一般內容輸入就是自動換行的，不是這樣的~~（懂點技術沒虧吃）。特別是IOS系統，創建頁顯示+輸入自動換行相對是比較麻煩的，技術做的時候這個高度基本是定死的，輸入多的內容展示1行往前推。如果考慮到開發周期盡量換一種展示方法比較好。

填坑方法：調研其他app發現其他app都巧妙地避免了這個坑。①如果直接在當前頁編輯，直接設定多行高度（這樣頁面展示不美觀）②點擊進入下一頁編輯（設計個專門的編輯頁面），編輯完保存返回上一頁，這里只是展示。（大部分app都是這么干的）③一般在當前創建頁就可以輸入的都是內容不多的場景，字數限制在8個字以內，（考慮到屏幕尺寸大小，如Iphone5）。

坑3--內容壓蓋問題：由于我們產品的特性，很大程度上不限制內容長度。比如姓名，一般app控制在5-6個字以內，而我們卻不做限制（少數民族名字有近20字的情況）。這樣就會導致姓名和其他屬性元素排列在一起時，考慮不周就會有壓蓋。

填坑方法：首先說明產品設計不限制內容長度其實是不太合理的，這樣設計后續要考慮很多地方排版的壓蓋問題，增加不少開發成本。①能限制字數的盡量限制字數。②沒有限制內容長度時排版要考慮根據內容長度...省略號，還是在寸土寸金的地方換行顯示（要跟技術大哥說明白的）③真遇到不定長的內容，排版時多加考慮，盡量讓它單獨一行。

坑4--草稿箱修改保存數據問題。技術原理：修改其實是創建一條新的草稿，然后再刪除原來的（刪除操作不做錯誤檢查）。當多人同時操作時編輯一個草稿結果就是創建了兩條新的，刪除了同一個舊的。可能會出現多人同時操作保存后，有2條草稿數據。

填坑方法：先搞清業務需求。①大多數情況，是直接全部覆蓋舊的數據。②少數情況是復制多條數據，保存不同的數據。做其他功能也一樣，考慮停留在當前頁問題。數據刷新問題。

其他常規性問題總結

1.遇到溝通問題要想清楚再給答復，盡量別直接做決定。特別是開發中途技術反饋需求“不合理”，或許在溝通過程中會被技術大哥的點子所誘惑，及時這樣也不要直接拍板更改需求。要相信自己當初這樣設計一定有他的道理，靜下心來對比下當初方案再做決定也不遲。

2.不要主動暴露缺點。為了某一個產品漏洞直接打補?。ɑ蛘呓o予用戶提示說明），在這條路上一直錯誤的走下去。如果發現設計有問題就直接更改正確的方案，不要將錯就錯。將來花費更大的成本彌補。

3.新功能不為了1%的特殊需求花更多的精力。時間相對充足的情況下可以完善，或后期迭代。

4.技術大哥問產品需求邏輯，不要直接敷衍按需求文檔來，大多是有待溝通的地方。要溝通詳細，多問一句他是怎么想的，或許真的能碰撞出火花。

5.還是老套路--產品經理一定要多想、多看。

以上就是這段時間的總結。歡迎小伙伴提出問題~ Merry Christmas~