如果你對于用戶、行業(yè)、大環(huán)境有足夠了解的時候，你就可以分析現(xiàn)下的問題，預(yù)測未來的發(fā)展方向提早布局，甚至去引導(dǎo)行業(yè)的發(fā)展。事物的發(fā)展總是有規(guī)律的，有足夠的能力，就可以看清這脈絡(luò)，看到這之間清晰的流動。

這幾年總是忙于手頭的項目，從APP到wap再到小程序和公眾號，不停在變。而這變化也是基于業(yè)務(wù)，基于需求。想來互聯(lián)網(wǎng)的大行業(yè)也是如此，每一兩年都有當下的熱門，有些漸漸消逝有些逐漸成型，而各位產(chǎn)品怕是也在不停的接受著這種沖擊和壓力。

那如果這個行業(yè)一直在變化，新的事物一直在出現(xiàn)，有沒有一條線，可以把這些串起來呢，讓我們接觸新的產(chǎn)品形式的時候可以快速拆解上手呢？

剛好有些時間，可以總結(jié)下自己做產(chǎn)品的一些邏輯方法，也就形成了這篇文章。

一、賬號體系

你的大腦是不是已經(jīng)開始浮現(xiàn)起來幾個詞呢：賬號登錄、手機號登錄、郵箱登錄、三方登錄，甚至你還會想到說這兩年很多產(chǎn)品登錄跟注冊已經(jīng)不區(qū)分都通用驗證碼了？

那，為什么呢？為什么賬號體系會這樣呢？而不同的登錄方式根源區(qū)別又在哪呢？

如果我們拋棄一些細節(jié)，從現(xiàn)狀往前推演這個變化過程，會發(fā)現(xiàn)什么呢？

（下文是筆者的推演，并未與歷史進行驗證，只作方法演示）

最初的最初，怕是我們最開始想要把一堆數(shù)據(jù)歸集到一個人身上的時候，便產(chǎn)生了賬號這種東西?？赡苁腔诂F(xiàn)實中的鑰匙和鎖的模擬（筆者編的），有了替代鎖的賬號，和替代鑰匙的密碼，如果你比較細心，在部分登錄注冊UI設(shè)計中，還可以看到這種鎖和鑰匙的圖標。當我們通過了賬號密碼的驗證，便可以看到基于這個賬號的一系列用戶行為數(shù)據(jù)。

而后來，產(chǎn)品越來越多，每個人使用的產(chǎn)品也越來越多，就出現(xiàn)了賬號記不住和密碼記不住的情況，甚至是因為賬號或昵稱是不可重復(fù)的，就有了：李四、李四被注冊這樣的名稱。

所以人們開始嘗試借用一些用戶本身就在用的東西來作為賬號，這個時候就有了郵箱、手機。而郵箱和手機這種獨立于產(chǎn)品本身業(yè)務(wù)的東西，就不再是你注冊只填寫一個沒人用過的用戶名就可以注冊了，而是你需要證明，證明你就是這個郵箱或手機的使用者，也就有了郵箱郵件驗證、手機驗證碼驗證。

這里有一個點需要注意，賬號體系還是你內(nèi)部的，只是，郵箱/手機是外部的。所以，你的賬號體系只支持一種注冊還是多種，注冊后可以通過什么驗證可以登錄，有了賬號把綁定行為觸發(fā)放在登錄前還是登錄后，都是你自家的規(guī)則。

但是郵箱/手機這種介質(zhì)、以及他們支持的驗證方式，則需要去遵循它們的基本邏輯了。但是在他們的邏輯內(nèi)，你是想給郵箱發(fā)個驗證碼還是帶參數(shù)的鏈接，你想給手機發(fā)幾位的驗證碼，是短信驗證碼還是語音驗證碼都是你去抉擇。

那如何又有了三方登錄這種東西呢？

你有沒有發(fā)現(xiàn)，這些三方產(chǎn)品，是你的高頻使用產(chǎn)品呢？微信、微博、QQ？因為大家的高頻場景分布在這些產(chǎn)品上，所以就有了：我可不可以用微信的登錄驗證我在其他產(chǎn)品的登錄呢？如果我把我的微信號跟你的賬號綁定在一起，是不是證明了我是這個微信號的使用者，就可以登錄了這個賬號呢？

這個就是目前的三方邏輯了。

而基于上文的解釋，你自然明白，三方是別人的產(chǎn)品，你如果想跟對方的賬號體系發(fā)生點什么，是需要對方提供給你方法的。

以微信為例：如果你想接入微信的賬號登錄體系，那你肯定需要微信給你一個代表這個微信賬號是這個微信賬號的標識，而作為第三方，微信是不可能把微信號或者原始ID之類的東西給你的，所以它就生成了一個加密字符串作為賬號的唯一標識，這個就是我們常說的openID。

但是你想接人家的賬號，肯定有別家也想接，人家怎么知道你是你呢？

這樣吧，你在我這里申請個商家賬號?？墒?，你除了web想接，APP也想接，而且你還在微信那里有公眾號小程序，還想把不同的場景區(qū)分開，但是又不想一個用戶多個標識。這樣吧，你每個產(chǎn)品都創(chuàng)建一下，都有自己的APPID、APPsecret，都有自己的驗證方式，但是因為公眾號和小程序是已經(jīng)在微信那里有一套體系了，所以就跟你自己的產(chǎn)品綁在一起吧。

這個就是開放平臺體系的雛形了，和基于單個產(chǎn)品的唯一標識的openID，基于開放平臺賬號的唯一標識的unionID。（如果你還想了解的多一些，可以研究下微信公眾平臺（公眾號、小程序）、微信開放平臺（APP、web）的接口分布）

但是別人的方法只是方法，賬號體系還是你自己的，你把這個驗證放在哪個步驟，你怎么拆分自家賬號的登錄注冊流程，你驗證了這個人就是這個微信號的使用者后要不要讓他直接生成賬號，還是補充個手機號或昵稱再說。

他沒有補充手機號或昵稱是僅僅攔截了登錄行為，還是連賬號都沒有創(chuàng)建成功（沒有入庫，存在賬號體系表里），他綁了一個微信號還能不能再綁一個，或者再綁一個微博，這些除了驗證方法之外的所有，都是你的規(guī)則，你的體系。都需要基于你的需求和你的分析判斷結(jié)果，去梳理整個流程、利用這些方法。方法之外，最重要的就是你的目的。

二、邏輯方法

所以，看到這里，筆者想要分享的邏輯方法也就出來了：

1. 明確你要做什么；
2. 明確所有相關(guān)角色及他們的規(guī)則；
3. 設(shè)計你的方案、推進下去并觀察結(jié)果。

三、筆者經(jīng)驗

以下，就這個邏輯方法，分享一些筆者的經(jīng)驗吧。

1.?明確你要做什么

如果我們描述一下產(chǎn)品工作的整個流程，大概就是：

你在一個平臺上做了一個游戲，用這個游戲吸引一部分人過來玩，同時這些人在你這里玩的時候能給你一些價值。但是這個平臺在變化，這些人也在變化，提供游戲的人也很多，所以你不斷的設(shè)計新的玩法，升級你的游戲并且提高這些人在你這邊創(chuàng)造的價值。

但是，你的老板可能不懂怎么玩只想知道一些結(jié)果、或者跟你說用別人那套玩法行不行，你的直屬領(lǐng)導(dǎo)可能覺得你設(shè)計的新玩法不一定能達到預(yù)期的結(jié)果，所以你通過你的各種分析表達給他們看是可行的。

當你終于通過了老板和直屬領(lǐng)導(dǎo)的認可，把你的玩法細節(jié)完善好告訴團隊怎么實現(xiàn)，把你的玩法推動到團隊去實施的時候，你的團隊可能告訴你說，你設(shè)計的這套東西邏輯有問題，或者是你的細節(jié)不是很清楚好多情況沒有給出處理方法，或者是其他業(yè)務(wù)線的人找到你，說你的玩法要是升級了，他們很多東西會受到影響，所以你不斷的解決這中間的問題。

當你終于解決各種問題帶領(lǐng)團隊把這套新玩法正常推到線上以后，通過各種方法去觀察新的玩法是不是真的有實現(xiàn)你的設(shè)想，在最初的設(shè)計中可能有的實現(xiàn)了有的沒有。所以你不斷的鍛煉自己的能力，最終對于玩法的有效性控制力越來越好、你跟領(lǐng)導(dǎo)的溝通也越來越順暢、你對團隊的推動力也越來越強。

這整個流程用一句話總結(jié)下來，就是：為了更好的滿足用戶需求和內(nèi)部需求，設(shè)計迭代方案，正確的推進下去并不斷分析迭代。而實際在初期的工作中，其實一件事的目的并沒有那么宏觀，而是細分的，比如提高活躍；也可能一件事情的目的需要你自己去尋找的，比如：做一個新增平臺的項目規(guī)劃。這種時候，對于相關(guān)角色及他們的規(guī)則的熟知，便能更好的幫你分析確定要做的事情。

2.?明確所有相關(guān)角色及他們的規(guī)則

如果我們上來就進行角色分組其實會比較亂，這個時候你可以按照自己工作的行為路徑去先進行劃分，然后明確每個行為步驟中的相關(guān)角色。

2.1 需求階段相關(guān)角色

（1）產(chǎn)品依存的平臺

對于平臺的分析，可以至少從兩個方面需要了解：

• 平臺定位：web、PC客戶端、APP、H5、小程序、公眾號等，不同的平臺類型，有自己的定位，比如APP可以作為終極服務(wù)提供端，H5/小程序可以作為推廣傳播使用。
• 技術(shù)了解：比如web、H5跟瀏覽器玩，PC客戶端跟桌面系統(tǒng)玩，APP跟手機系統(tǒng)玩，小程序/公眾號則是基于微信的體系。對于基礎(chǔ)技術(shù)的了解，可以幫助我們在遇到問題的時候有處去尋，比如做APP的需要關(guān)注iOS、Android的規(guī)則和技術(shù)迭代，比如做小程序/公眾號的需要關(guān)注微信的技術(shù)更新日志及運營策略調(diào)整。

（2）用戶行為及大環(huán)境/業(yè)務(wù)相關(guān)方/競品

產(chǎn)品除了定義準目標用戶及需求外，還需要做的是如何設(shè)計引導(dǎo)去滿足，而這個過程，其實就是觀察用戶行為流動及進行相關(guān)引導(dǎo)的過程。關(guān)于這部分相關(guān)文章已經(jīng)足夠多便不再贅述。但有一點，對于用戶的觀察，一定要放到政治經(jīng)濟社會技術(shù)大環(huán)境中。

而業(yè)務(wù)方，相對用戶而言，是對于內(nèi)部需求實現(xiàn)過程中需要進行配合的。而二者的關(guān)系及側(cè)重，則需要產(chǎn)品綜合業(yè)務(wù)類型、企業(yè)基因、產(chǎn)品基因、優(yōu)先級等多方進行判斷。

如果你是剛剛接手一端產(chǎn)品，看看競品公司的設(shè)計并分析設(shè)計意圖，可以幫你快速的了解產(chǎn)品及行業(yè)。但是你在產(chǎn)品設(shè)計中做的決策，一定是在內(nèi)部體系支持下的，因為不論業(yè)務(wù)再相似，也一定是有差別的，沒有思考直接借用大多會給自己挖坑。

（3）領(lǐng)導(dǎo)層及其他產(chǎn)品線

產(chǎn)品規(guī)劃過程，及方案的評審，都可能涉及到與領(lǐng)導(dǎo)層的溝通。如果你不是戰(zhàn)略制定者，如何正確的理解產(chǎn)品戰(zhàn)略訴求，并把自己的方案規(guī)劃及項目價值以最大限度表達給各負責人，也是考驗產(chǎn)品經(jīng)理能力之處。

如果說內(nèi)部團隊的溝通可以更好的把控項目，則對上的溝通可以配合領(lǐng)導(dǎo)對于產(chǎn)品線的管理。自己悶頭做自己的需求而不在意團隊/其他產(chǎn)品線/領(lǐng)導(dǎo)，很多情況下并不是什么好事。

2.2 實施階段相關(guān)角色

實施階段的角色參與一般是在原型確定，或者文檔細節(jié)完成后進行的，一般需要把握設(shè)計稿的完成節(jié)點、提測節(jié)點和上線節(jié)點，如果這之間有一些角色之間的節(jié)點沖突，便需要進行協(xié)調(diào)。

（1）UI/交互

規(guī)劃階段的產(chǎn)品及用戶定位等，可以幫助設(shè)計師把握視覺及交互層的基本方向。

產(chǎn)品提測到上線期間，如涉及產(chǎn)品界面樣式修改，會有一部分時間用于調(diào)UI。

（2）開發(fā)/測試

產(chǎn)品在平臺基本技術(shù)了解的情況下，加深對于前臺、后臺、接口等的理解，關(guān)注用戶行為和數(shù)據(jù)流動，設(shè)計過程中關(guān)注平臺差異和設(shè)計點差異，這樣做出的方案能夠減少開發(fā)階段的不確定。如果經(jīng)歷的項目較多，或者對于團隊足夠熟悉，在迭代方案制定時基本就可以確定這版方案的大概開發(fā)和測試周期，及跟進時的風險點。

如果涉及到跨平臺的產(chǎn)品，比如APP內(nèi)接入H5，原生和H5頁面進行互相跳轉(zhuǎn)，則需要進行不同端開發(fā)間的配合。

而基于平臺的不同，開發(fā)測試的迭代特點也不同，APP有版本的迭代發(fā)布審核且區(qū)分iOS、Android，H5可以隨時發(fā)布，小程序需要在微信公眾平臺后臺提交版本，這些特點在配合上是需要注意的。

（3）業(yè)務(wù)對接

如果你手里的項目是業(yè)務(wù)相關(guān)性很強的，則實施過程中如果有需求變動或者上線時間調(diào)整，都需要與業(yè)務(wù)方進行對接以方便對方有時間去做準備。

2.3 上線后的相關(guān)角色

（1）業(yè)務(wù)對接

主要是上線后業(yè)務(wù)、運營的對接，以及產(chǎn)品培訓(xùn)。

（2）數(shù)據(jù)監(jiān)測

針對想要達成的目的，進行相關(guān)數(shù)據(jù)的分析，以判斷迭代的效果。如果是業(yè)務(wù)類系統(tǒng)，則需要向內(nèi)部業(yè)務(wù)人員收集反饋。根據(jù)這些分析結(jié)果，作為后續(xù)迭代參考。

3.?設(shè)計你的方案、推進下去并觀察結(jié)果

其實在第二步我們分析相關(guān)角色的時候，基本已經(jīng)把方案設(shè)計和項目推進大概說了。這個過程無非就是針對第二步各個角色和你的需求，不斷的提高方案的成熟度和項目的可控性。而需求的識別與轉(zhuǎn)化、實際項目中的判斷力，還是需要實操去磨的。這里就直接分享一些項目過程中的經(jīng)驗吧。

（1）短期方案和長期方案

不管是在迭代方案的確定中還是項目跟進過程中，都可能會遇到一些狀況需要處理。有些比較大不好直接改，有些比較小就可以直接調(diào)。這個過程中，一定要分清哪些是長期的處理方案哪些是短期處理方案。比如，新項目接近上線還有一些問題，這時候產(chǎn)品協(xié)調(diào)各個角色保證本次上線是短期方案，上線后針對團隊問題進行分析調(diào)整是長期方案。

（2）觸發(fā)幾率和嚴重性

這個主要用于產(chǎn)品上線時比較難改又發(fā)現(xiàn)晚的問題，或者是一些線上bug發(fā)現(xiàn)后的處理依據(jù)。比如：在商品支付項目中，訂單金額的計算或顯示錯誤就是嚴重性很高的問題，一旦發(fā)現(xiàn)是要盡早改的。但是比如一些UI問題，不在核心頁面展示且觸發(fā)幾率比較低，則可以考慮后續(xù)迭代時修改。

（3）尊重各個角色、但維護團隊核心訴求

不管是不同業(yè)務(wù)線的產(chǎn)品，還是UI/交互/開發(fā)/測試，還是相關(guān)的業(yè)務(wù)、運營，每個角色在團隊中都起著各自的作用。產(chǎn)品對于項目中各個角色的工作理解越深，對于項目的把控力就越強，項目推進及上線時的風險就越小。

但是合作過程中難免會涉及一些紛爭，溝通協(xié)調(diào)和解決是沒有問題的，但是一定要維護團隊核心訴求：就是團隊工作的高效和項目上線的質(zhì)量。

以上就是這篇文章的主要內(nèi)容了，照應(yīng)文章開篇的問題，這個方法不妨一試。但是如果你問，讀了這篇文章是不是就可以毫無風險的去做一個從未接觸的產(chǎn)品了？

怕還是不能的，因為項目的規(guī)劃和跟進經(jīng)驗還是有差別的，但至少，如果你在經(jīng)手的每個項目中都這樣去思考分析，經(jīng)歷的項目越來越多，當新的東西產(chǎn)生并交到你手上的時候，以往的思考就會作為你強大的后盾，幫助你對新產(chǎn)生的事物進行快速的拆解。

而如果你對于用戶、行業(yè)、大環(huán)境有足夠了解的時候，你就可以分析現(xiàn)下的問題，預(yù)測未來的發(fā)展方向提早布局，甚至去引導(dǎo)行業(yè)的發(fā)展。

事物的發(fā)展總是有規(guī)律的，有足夠的能力，就可以看清這脈絡(luò)、看到這之間清晰的流動吧。

作者：無良，公眾號：無良在想

本文由 @無良 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議