背景：自身產品的數據后臺，是上一任開發自己做的，沒有產品設計，只是在需要更新某些功能的時候加進去，使用體驗比較差，搜索交互反應比較慢。在這樣的背景下，根據自身產品的業務，進行后臺的重構，一方面是技術的重構，一方面是后臺呈現框架和使用體驗的重構，技術我不懂，所以我只是記錄呈現框架和使用體驗的重構。

一、思維技術坑

? ? ? 做后臺功能列表腦圖的時候，一直跟著之前的后臺模型去走，思維被限制地死死的；畫完一圈后發現，這樣做無異于只是做現有后臺做一些簡化而已。在重新思考了一遍以后，根據“使用場景”進行了功能列表的優化。其實自身產品的后臺大多數都是提供查詢和設置功能，使用者其實是我們自己。因為之前的開發是站在自己的需要去做的，所以一些沒有必要的查詢字段，比如userkey，openid等都加入了。在細化功能列表到字段后，我也陷入了思維怪圈，認為他們之前有的就大多數是需要的，因為怕自己不懂技術會導致一些錯誤。其實不然，首先產品的使用者是我們產品經理本身以及一些同事，做到簡單易懂就可以了，技術上的字段只是技術為了方便自己識別加進去而已，完全可以省略掉。也許這會回歸到某個偽命題，就是產品經理到底需要懂技術嗎？其實我的想法是需要懂一點點，不求能幫開發解決技術上的難點，只求不被開發忽悠。說不需要懂技術，其實大多數都是認為在設計的時候會被局限在能否實現的程度上。我覺得真實的場景可以是這樣，設計的時候應該站在用戶的角度去設計，比如在什么樣的場景用戶大致會做什么樣的操作，我們需要什么樣的交互，要先注重用戶體驗吧，實在難以實現最多就是退而求次優解。

二、信息分類坑

? ? ? 不記得在哪本書上看到有關信息分類的內容，在簡約至上一書有組織策略，我個人理解就是信息分類。比如某個功能是屬于查詢功能還是設置功能，子功能里面有再包含了哪些子功能，是否每個小的功能之間有重復或者有不同屬的關系。我想這應該是產品經理要避免的一個坑，因為一個網站或者一個應用所呈現出來的分類邏輯是否清晰易懂，會直接影響你的產品學習成本有多高等。但是這個目前為止，我也無法很快的掌握，目前我的死方法就是所有分類都列出來，再慢慢進行推敲，雖然這個方式消耗時間會久一點，但是思考的過程能讓你看清楚想明白之前一些沒有涉及的內容。在這過程中，我有因為某個地方用得多或者少，把其中某些功能單獨提取什么的，但這樣就完成破話這個框架邏輯，使得結構不夠清晰，特別混亂。

三、設計坑

? ? ?在這個后臺的重構中，我這里所說的設計坑，不是指ui設計，指的是文案設計等。首先就是，文案設計必須要讓使用產品的人都看得懂，不需要他們來提問等。我一直都認為自己文筆不錯的，然而這并沒有什么卵用。好用一般都是得在能用的前提下才發揮作用的。我老大說，像我業務參加這文深的人，都需要我去解釋文案的意思，那我的文案就真的很失敗了。文案必須要求簡單簡潔，要求別人一看就能懂。還有一個設計坑，就是排版。我曾經認為，只要排得整齊就行了，所以第一次設計的時候，我沒有去考慮使用頻率等相關因素，我就只是讓他整齊就可以了。但是由于人的視覺習慣一般都是從左到右，從上到下，按照這樣的習慣，你必須根據使用頻率的高低去排序，而不是根據字多字少。根據使用頻率大小排序，你可以避免在使用高頻功能的時候，還需要接受低頻功能的信息干擾。當然，你也必須在保證不對用戶產生干擾的前提下，設計得整齊整潔。

四、項目跟進坑

? ? ? 一開始的時候，我在設計的時候加入了很多新功能，導致整個產品的開發周期很長。但是我們只是需要盡快把重構做完。但一開始我沒有注意到這點，加入了很多功能，拖慢了開發進度。所以，作為一名產品經理，我覺得需要懂一點項目知識。畢竟你是要確保在什么時間點，完成什么樣的開發進度。很多時候，你都需要把控開發進度和評估開發周期

? ? ? 目前來看，坑大概就是這樣，可能說起來簡單，但一切還是得靠自己慢慢實踐去完善。知易行難，好困，之后有想到再補。