本次復盤從產品規(guī)劃與設計、溝通協(xié)調兩個方面來思考，而產品規(guī)劃與設計又根據(jù)用戶體驗五要素的產品設計流程來展開。

產品規(guī)劃與設計方面

1、戰(zhàn)略層

此產品最初的戰(zhàn)略方向很明確，就是為了讓領導能夠方便的看到一線員工的工作量和質的情況。因此從戰(zhàn)略層面來說，本次產品的設計不存在問題。

2、范圍層

在考慮范圍層的時候出現(xiàn)了一些問題：因為需求只能通過遠程電話溝通、時間過于倉促（從想法到交付只有兩周時間）、本身對領導層（最關鍵的用戶）的具體需求和員工工作習慣不了解等各種原因，導致部分產品范圍考慮有欠缺，比如某些說明性的字段的遺漏。要想避免，必須要相關人員全身心投入，而身為產品經理也需要更多時間和機會去實際了解各用戶角色在本系統(tǒng)涉及的工作流程中的習慣和需求。

做的好的地方：做了用戶角色和任務分析

1）從接單后，就一直在搞清楚組織架構，用xmind抽象出了組織架構，從而確定本系統(tǒng)的目標用戶有哪些，分為哪些人物角色。

2）調查了解各個人物角色之間（使用系統(tǒng)的）工作流程，做好了任務分析；并且在processon上用泳道圖繪制了整個系統(tǒng)的主要核心業(yè)務流程圖，也針對不同角色用Visio分別繪制了他們的核心業(yè)務流程圖。

經驗教訓：應該盡可能早的把盡可能準確的用戶組織架構和人員名單給到研發(fā)，經過抽象處理的未必準確

早期我向領導（需求方）再三確認過抽象出來的組織架構沒有問題，感覺肯定不會出錯，就直接將抽象后的組織架構給了研發(fā)。但是在梳理最終的具體名單和組織架構時，發(fā)現(xiàn)雖然與抽象出來的架構雖然大體一致，缺還是略有不同——存在一人身兼多職的情況。這在前期抽象過程中并沒有想到，也沒有提醒研發(fā)可能存在這種情況。導致在研發(fā)的最后關頭出現(xiàn)了原本的數(shù)據(jù)結構設計無法滿足需求的問題，好在最后只是做了略微調整就完善了。如果不是一人身兼多職而是一人身兼多種角色的情況，那這次就會造成數(shù)據(jù)結構的完全不適應，從而導致研發(fā)大面積返工，上線時間大幅度延遲。因此，以后在做此類產品設計時，應該在第一時間將準備的用戶組織架構和人員名單梳理出來并給到研發(fā)，因為這會影響到他們的數(shù)據(jù)結構設計，避免不必要的研發(fā)資源浪費和產品交付推遲。

ps：因為本系統(tǒng)相對較為簡單、且沒有時間和機會做詳盡的用戶調研和使用場景分析，因此這次產品設計過程中，用戶調研就是依賴直接與領導溝通完成、場景分析基本就是在自己腦子里面過了幾遍就完成了，并沒有形成書面交付物。

3、結構層

1）根據(jù)角色需求的差異對系統(tǒng)進行拆分設計，將復雜度降到最低：因為不同角色的功能需求完全不同，所以此系統(tǒng)的前端系統(tǒng)展示是根據(jù)不同角色的功能需求分別設計。

2）信息列表按多種狀態(tài)分類，因此采用了頂部tab導航的方式對信息列表進行歸類整合。

經驗教訓：微信的返回按鈕太惡心，與可定制的APP不同，一定要給用戶提供一個快捷切換的導航按鈕。

本系統(tǒng)在微信公眾號上運行，但微信的返回按鈕太惡心，完全不可控。即使你只有兩個主要功能模塊入口，如果用戶路徑較深，采用微信的返回按鈕返回，會使得用戶一直深陷于返回狀態(tài)而難以到達主入口頁，因此產品一定要給用戶提供一個快捷切換的導航按鈕。本系統(tǒng)為了保持系統(tǒng)設計的一致性和前端代碼的復用性，同樣是采用了懸浮icon導航，直接跳轉到主入口頁，類似于下圖。

4、框架層

1）核心模塊和入口少，采用頂部tab導航+懸浮icon導航的組合方式：此系統(tǒng)的所有角色都只有1~2個核心功能模塊，因此整個系統(tǒng)都是采用了頂部tab式導航+懸浮icon導航的組合方式，見下圖。如果核心功能模塊更多，或許會考慮采用頂部tab式導航+底部菜單欄導航的組合設計框架。

2）本系統(tǒng)信息相對單一，再加上是移動端，所以基本都是采用了最簡單的從上到下的信息流的頁面結構方式。

做的好的地方：1）所有的模塊和框架設計樣式都盡量保持一致：為了保持系統(tǒng)的整體性和一致性、同時也增加研發(fā)（前端）的代碼可復用性，所有的模塊和框架設計樣式都盡量保持一致。如統(tǒng)一采用頂部tab導航和懸浮icon導航、相同樣式的卡片式信息列表。

5、表現(xiàn)層

1）卡片式列表設計：大部分頁面都是展示信息列表，而且文字描述內容較多，因此最終選用了常見的卡片式列表設計（上面有圖）。

2）為了能夠盡早交付、減少前端工作量，本系統(tǒng)盡可能的降低交互效果的要求。

3）采用了最近流行的平鋪滑動式導航和信息列表樣式，增強了系統(tǒng)的可擴展性，若日后添加更多的部門也不需要修改前端代碼，見下圖。

做的好的地方：1）設計規(guī)范化：在制作原型時，基本統(tǒng)一了不同頁面各種情況下的字體大小、字體和背景顏色、間距、圖標尺寸大小等，做到了相對較好的統(tǒng)一和規(guī)范化設計。2）提前跟UI交待了整體風格：在UI設計之前，就交待了本系統(tǒng)的使用對象年齡較大、所處環(huán)境較為傳統(tǒng)，因此需要一個較為穩(wěn)重的設計基調。

溝通協(xié)調方面

1）研發(fā)響應快速的團隊，可以口述零散的需求變更和bug修復，反應慢則最好使用奇妙清單等團隊協(xié)作工具進行書面通知和任務分配，明確責任人，并且能夠及時更新和追蹤任務完成狀態(tài)

在產品開發(fā)過程中，出現(xiàn)了很多需要修改的細節(jié)（有的是需求變更，有的則是程序bug）。為了節(jié)約大家時間，我就直接和對應的研發(fā)口頭溝通。因為很多小細節(jié)稍微做點修改就好了，工作量也不大，原以為研發(fā)會很快修改好，但是到最后發(fā)現(xiàn)，研發(fā)響應速度太慢，之前提到的需要修改的問題并沒有去完善，被遺忘了……

2）為了讓所有人的認知處于同一水平，同時方便上線前的產品測試核驗，任何的需求變更都錄入到需求管理表或者產品功能的featurelist中，并讓團隊所有人更新文檔

由于本次為了加快響應速度，所有的featurelist都放在了原型文檔中呈現(xiàn)，但是原型的原始文件莫名其妙不見了（悲催的……），只剩下了一個pdf版文件。導致中途很多需求的變更都不能及時以一個統(tǒng)一、整體的書面版本交付給大家，最終的結果就是，雖然口頭或者零散的書面通知了所有人，但是還是很多人都是參照第一個版本的產品設計來開發(fā)、測試。

其他

相比于典型的互聯(lián)網(wǎng)產品設計，雖然此管理系統(tǒng)非常小，但是產品設計的整個過程，除了戰(zhàn)略層不需要有太多考慮外，其他層面也都基本需要相同的考量和設計。