本文作者@wbuild ，在文中，作者先容瞭計劃師在發展進程中的三個階段，並針對這三種分歧的成長階段講訴瞭三種分歧順應本身程度的計劃辦法。從基本技巧到後果計劃，末瞭要計劃師要做的就是計劃用戶。

　　在對計劃師而言，對本身計劃最主要的就是深入懂得產物需求，深刻斟酌用戶是若何應用產物，

　　作為交互計劃師，我認為有幾個成長階段：

　　初入這個范疇，大部分人大概更多精神放在若何應用對象、若何畫線框圖、若何將設法主意變成現實可見的Demo;

　　再往下一個階段的計劃師，大概會斟酌線框圖如何做得加倍公道、如何能夠有更棒的交互後果、存眷義務流程和信息構造的計劃和可用性原則;

　　再到一個更高條理，我認為須要計劃師在前兩個條理的基本上去前置產物，深入懂得產物需求，深刻斟酌用戶是若何應用產物的。用戶應用產物有哪些途徑和在這些途徑上的現實應用場景是如何的。哪些是強場景，哪些是弱場景，在各場景下用戶目的是如何的，他們有如何的需求，哪些是強需求，哪些是弱需求

　　跟人人分享第3個條理的計劃辦法，這些辦法合適WebBase類產物的計劃。

　　起首做產物的早期，從PM那邊拿到需求時，必定沒有是立馬開端畫線框圖。做一個產物，我們計劃師的事情就是要肯定兩個焦點的題目：1、須要哪些頁面和這些頁面的幹系;2、每一個頁面應當若何計劃。

　　對付第1個題目我是如許斟酌的。起首肯定產物的用戶群和應用場景，這裡的用戶群是產物中現實存在的、互斥的幾個群體，分類辦法許多，以產物本身特點來肯定，也能夠在前期用研的基本上來肯定。基於此思緒就發生上面的一個頭腦圖:

　　固然，這裡須要去斷定哪些是強場景，哪些是弱場景，然後在做計劃時，做些棄取。好比強場景下，能夠斟酌將較焦點的途徑進口增加到顯著的地位(如導航)。

　　拿百度身旁來舉例，這裡按這類模子大抵枚舉瞭頁面途徑：

　　(這邊重點先容計劃模子，對付內裡的分類辦法是不是有優化空間這裡沒有做特殊的商量)

　　​ 在計劃時，我們綜合斟酌這兩種用戶，並從當選擇幾個最強的場景，如找美食、商傢，如許就須要有清楚的商傢聚合頁及美食聚合頁。

　　​ 如今，須要哪些頁面和這些頁面之間的幹系已異常清晰瞭，我們便可以產出以下產物架構圖：

　　第1個題目辦理瞭，上面看看零丁一個頁面應當若何去計劃。

　　起首照樣援用與第1個題目相似的計劃模子：斟酌此頁面有幾種互斥的用戶，這些用戶在這個頁面有哪些應用場景，每種應用場景下用戶有哪些需求及對應的功效。針對每個功效，從深度、廣度、頻度這3個維度來評價功效的強弱。功效越強，計劃時須要優先斟酌此功效，好比在最顯著的地位賜與最強的展示;功效越弱，則斟酌將功效隱蔽、歸並或置於非焦點視圖地區。

　　以百度XX產物APP官網為例，援用此模子則能夠導出以下頭腦圖：

　　由此模子，我們發明平臺進口、下載進口、產物功效等得分較高，是以這些是我們在計劃時須要重點斟酌和凸起展現的信息。是以，我們做瞭以下的計劃：

　　在計劃一個產物進程中，引入以上計劃模子，我們能夠真正做到以用戶為中間去計劃，同時，能夠異常清楚的辦理以下題目：

　　模仿重現實在用戶現實是若何應用我們的產物，幸免自覺的客觀臆斷;

　　計劃師與PM能用一樣的頭腦形式斟酌統一個題目，幸免無休的爭辯;

　　實在斟酌每種用戶的應用途徑，為義務流程的優化和頁面途徑的公道化供給根據;

　　重現每一個頁面的用戶目的及需求，從而使頁面結構和功效展示加倍公道，相符用戶預期;