產品研發過程中，不奢求完美主義，能夠在產品生長的每一步中將產品設計做到恰如其分，同時也能避免一些常規陷阱，已經是很不錯了！

近幾年大大小小接觸過的軟體產品少說也幾十款，產品交互設計能夠做到“恰如其分”的著實少之又少。基本的一些產品思維，想必不論是開發團隊、產品團隊、設計團隊都會多少具備的，比如：一款產品可以面臨不同類型的使用者基本上是一種共識，甚至於同一款產品內部不同的模組面對不同的使用者。

不過我們仍然經常見到下面這種現象：

1、各個模組間出現對於使用者的不同假設定位，一會兒認為用戶是專家使用者，一會兒認為使用者是新手，給出來的框架+表現層參差不齊。

這還不是最可怕的，雖然這已經足夠讓使用者感到苦惱了，如果你是商業產品，還好。如果你是消費產品，那這一條基本上就拜拜了。用戶在螢幕後面距離產品設計者十萬八千里，早就用腳投票和產品say byebye了。

2、最為可怕的是自我代入：產品經理自我代入、程式員自我代入、測試工程師也自我代入。（令人意外的是，觀察後發現自我代入通常竟然還要求極高的洞察力和微觀體感。）

後果會出現多層的矛盾——產品呈現與使用者心理期望的矛盾、產品呈現與底層實現的矛盾，底層實現如果自我代入了，基本意味著重建的必然性。開發實現自我代入是高危行為，作為產品經理這裏必須留意再留意！警惕再警惕！（這裡要求的是產品邏輯和程式邏輯的一致性，產品經理要確保和開發團隊達成共同的認知水準）

如果實現模型（軟體的程序層面）衝突於呈現模型（用戶的體驗層面，也即產品功能/介面/資訊），且在未來的演進思路上（演進是跟隨著使用者模型、市場模型的共同變化）已經南轅北轍，那麼這款產品會很快感受到成長的無力感。

看清問題，才能做到“恰如其分”

第1個問題出在產品研發團隊，甚至於市場團隊、管理團隊，這些人員中心里住著不同的“使用者”，你說的使用者和我說的使用者，並不是一個使用者。

大家對於“使用者模型”並沒有達成一致，而使用者模型，一定是一款產品成功的基礎。不論是對於產品設計、交互設計、技術架構設計、編碼實現、市場行銷。

使用者模型的構建，需要前期一系列的研究工作，在常規的團隊裡面，這些工作通常都是隱型的、不被okr/kpi包含的，重視程度基本靠自覺、靠個人的市場/業務理解支撐。大到新設計一款產品、或者一個新增功能模組/視覺體系改版，小到一個按鈕的調整，都可以參考到使用者模型。

使用者研究裡面，人物模型的建立又是一套複雜而完整的體系，如果沒有有充足的資源以及時間的情況下，即便通過專家知識、過往積累知識的瞭解，自己來擬定一個臨時人物模型，即使是這樣，也勝過沒有任何人物模型的，仍然會在產品設計研發過程中起到良好的指導作用。（但這並不代表任意不經過仔細研究的臨時人物模型就可以拿來就用，雖然有勝有無，但一定要避免误入歧途）

第2個問題，涉及到產品設計邏輯和代碼構建邏輯的一致性。也許有的產品/設計團隊會說，我的方案如此，要求開發團隊交付出來滿足當前方案/文檔的專案成果即可，而往往測試團隊也是對於標的物的產品需求文檔交付測試為主。但最終產品要為使用者/客戶負責，除非我們的使用者/客戶是不變的。

產品/設計團隊應該能夠根據業務的發展 、產品路徑的演進，判斷出來一些核心邏輯的設計、區分和預留。這個基調引導了代碼的架構，這也就是產品設計邏輯、功能邏輯、到代碼邏輯、數據邏輯的層層銜接了。（參考之前分享的這篇文章產品設計邏輯能否引導代碼構建邏輯？）

絕對不是簡單的我想要什麼，剩下的交給開發者。想要什麼很重要、路徑演進的可能性同樣也很重要，表達清楚絕對是為自己的產品路線鋪路。

相信都不願意看到產品極速發展的過程中，代碼逐漸臃腫不堪、跟不上發展的步伐，最終不得不面臨重構，要不就是產品的妥協、用戶價值和商業價值大大折扣。