起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識面對新事物，這套邏輯方法，也許可以幫到你
如果你對于用戶、行業、大環境有足夠了解的時候，你就可以分析現下的問題，預測未來的發展方向提早布局，甚至去引導行業的發展。事物的發展總是有規律的，有足夠的能力，就可以看清這脈絡，看到這之間清晰的流動。
這幾年總是忙于手頭的項目，從APP到wap再到小程序和公眾號，不停在變。而這變化也是基于業務，基于需求。想來互聯網的大行業也是如此，每一兩年都有當下的熱門，有些漸漸消逝有些逐漸成型，而各位產品怕是也在不停的接受著這種沖擊和壓力。
那如果這個行業一直在變化，新的事物一直在出現，有沒有一條線，可以把這些串起來呢，讓我們接觸新的產品形式的時候可以快速拆解上手呢？
剛好有些時間，可以總結下自己做產品的一些邏輯方法，也就形成了這篇文章。
一、賬號體系
你的大腦是不是已經開始浮現起來幾個詞呢：賬號登錄、手機號登錄、郵箱登錄、三方登錄，甚至你還會想到說這兩年很多產品登錄跟注冊已經不區分都通用驗證碼了？
那，為什么呢？為什么賬號體系會這樣呢？而不同的登錄方式根源區別又在哪呢？
如果我們拋棄一些細節，從現狀往前推演這個變化過程，會發現什么呢？
（下文是筆者的推演，并未與歷史進行驗證，只作方法演示）
最初的最初，怕是我們最開始想要把一堆數據歸集到一個人身上的時候，便產生了賬號這種東西?？赡苁腔诂F實中的鑰匙和鎖的模擬（筆者編的），有了替代鎖的賬號，和替代鑰匙的密碼，如果你比較細心，在部分登錄注冊UI設計中，還可以看到這種鎖和鑰匙的圖標。當我們通過了賬號密碼的驗證，便可以看到基于這個賬號的一系列用戶行為數據。
而后來，產品越來越多，每個人使用的產品也越來越多，就出現了賬號記不住和密碼記不住的情況，甚至是因為賬號或昵稱是不可重復的，就有了：李四、李四被注冊這樣的名稱。
所以人們開始嘗試借用一些用戶本身就在用的東西來作為賬號，這個時候就有了郵箱、手機。而郵箱和手機這種獨立于產品本身業務的東西，就不再是你注冊只填寫一個沒人用過的用戶名就可以注冊了，而是你需要證明，證明你就是這個郵箱或手機的使用者，也就有了郵箱郵件驗證、手機驗證碼驗證。
這里有一個點需要注意，賬號體系還是你內部的，只是，郵箱/手機是外部的。所以，你的賬號體系只支持一種注冊還是多種，注冊后可以通過什么驗證可以登錄，有了賬號把綁定行為觸發放在登錄前還是登錄后，都是你自家的規則。
但是郵箱/手機這種介質、以及他們支持的驗證方式，則需要去遵循它們的基本邏輯了。但是在他們的邏輯內，你是想給郵箱發個驗證碼還是帶參數的鏈接，你想給手機發幾位的驗證碼，是短信驗證碼還是語音驗證碼都是你去抉擇。
那如何又有了三方登錄這種東西呢？
你有沒有發現，這些三方產品，是你的高頻使用產品呢？微信、微博、QQ？因為大家的高頻場景分布在這些產品上，所以就有了：我可不可以用微信的登錄驗證我在其他產品的登錄呢？如果我把我的微信號跟你的賬號綁定在一起，是不是證明了我是這個微信號的使用者，就可以登錄了這個賬號呢？
這個就是目前的三方邏輯了。
而基于上文的解釋，你自然明白，三方是別人的產品，你如果想跟對方的賬號體系發生點什么，是需要對方提供給你方法的。
以微信為例：如果你想接入微信的賬號登錄體系，那你肯定需要微信給你一個代表這個微信賬號是這個微信賬號的標識，而作為第三方，微信是不可能把微信號或者原始ID之類的東西給你的，所以它就生成了一個加密字符串作為賬號的唯一標識，這個就是我們常說的openID。
但是你想接人家的賬號，肯定有別家也想接，人家怎么知道你是你呢？
這樣吧，你在我這里申請個商家賬號。可是，你除了web想接，APP也想接，而且你還在微信那里有公眾號小程序，還想把不同的場景區分開，但是又不想一個用戶多個標識。這樣吧，你每個產品都創建一下，都有自己的APPID、APPsecret，都有自己的驗證方式，但是因為公眾號和小程序是已經在微信那里有一套體系了，所以就跟你自己的產品綁在一起吧。
這個就是開放平臺體系的雛形了，和基于單個產品的唯一標識的openID，基于開放平臺賬號的唯一標識的unionID。（如果你還想了解的多一些，可以研究下微信公眾平臺（公眾號、小程序）、微信開放平臺（APP、web）的接口分布）
但是別人的方法只是方法，賬號體系還是你自己的，你把這個驗證放在哪個步驟，你怎么拆分自家賬號的登錄注冊流程，你驗證了這個人就是這個微信號的使用者后要不要讓他直接生成賬號，還是補充個手機號或昵稱再說。
他沒有補充手機號或昵稱是僅僅攔截了登錄行為，還是連賬號都沒有創建成功（沒有入庫，存在賬號體系表里），他綁了一個微信號還能不能再綁一個，或者再綁一個微博，這些除了驗證方法之外的所有，都是你的規則，你的體系。都需要基于你的需求和你的分析判斷結果，去梳理整個流程、利用這些方法。方法之外，最重要的就是你的目的。
二、邏輯方法
所以，看到這里，筆者想要分享的邏輯方法也就出來了：
- 明確你要做什么；
- 明確所有相關角色及他們的規則；
- 設計你的方案、推進下去并觀察結果。
三、筆者經驗
以下，就這個邏輯方法，分享一些筆者的經驗吧。
1.?明確你要做什么
如果我們描述一下產品工作的整個流程，大概就是：
你在一個平臺上做了一個游戲，用這個游戲吸引一部分人過來玩，同時這些人在你這里玩的時候能給你一些價值。但是這個平臺在變化，這些人也在變化，提供游戲的人也很多，所以你不斷的設計新的玩法，升級你的游戲并且提高這些人在你這邊創造的價值。
但是，你的老板可能不懂怎么玩只想知道一些結果、或者跟你說用別人那套玩法行不行，你的直屬領導可能覺得你設計的新玩法不一定能達到預期的結果，所以你通過你的各種分析表達給他們看是可行的。
當你終于通過了老板和直屬領導的認可，把你的玩法細節完善好告訴團隊怎么實現，把你的玩法推動到團隊去實施的時候，你的團隊可能告訴你說，你設計的這套東西邏輯有問題，或者是你的細節不是很清楚好多情況沒有給出處理方法，或者是其他業務線的人找到你，說你的玩法要是升級了，他們很多東西會受到影響，所以你不斷的解決這中間的問題。
當你終于解決各種問題帶領團隊把這套新玩法正常推到線上以后，通過各種方法去觀察新的玩法是不是真的有實現你的設想，在最初的設計中可能有的實現了有的沒有。所以你不斷的鍛煉自己的能力，最終對于玩法的有效性控制力越來越好、你跟領導的溝通也越來越順暢、你對團隊的推動力也越來越強。
這整個流程用一句話總結下來，就是：為了更好的滿足用戶需求和內部需求，設計迭代方案，正確的推進下去并不斷分析迭代。而實際在初期的工作中，其實一件事的目的并沒有那么宏觀，而是細分的，比如提高活躍；也可能一件事情的目的需要你自己去尋找的，比如：做一個新增平臺的項目規劃。這種時候，對于相關角色及他們的規則的熟知，便能更好的幫你分析確定要做的事情。
2.?明確所有相關角色及他們的規則
如果我們上來就進行角色分組其實會比較亂，這個時候你可以按照自己工作的行為路徑去先進行劃分，然后明確每個行為步驟中的相關角色。
2.1 需求階段相關角色
（1）產品依存的平臺
對于平臺的分析，可以至少從兩個方面需要了解：
- 平臺定位：web、PC客戶端、APP、H5、小程序、公眾號等，不同的平臺類型，有自己的定位，比如APP可以作為終極服務提供端，H5/小程序可以作為推廣傳播使用。
- 技術了解：比如web、H5跟瀏覽器玩，PC客戶端跟桌面系統玩，APP跟手機系統玩，小程序/公眾號則是基于微信的體系。對于基礎技術的了解，可以幫助我們在遇到問題的時候有處去尋，比如做APP的需要關注iOS、Android的規則和技術迭代，比如做小程序/公眾號的需要關注微信的技術更新日志及運營策略調整。
（2）用戶行為及大環境/業務相關方/競品
產品除了定義準目標用戶及需求外，還需要做的是如何設計引導去滿足，而這個過程，其實就是觀察用戶行為流動及進行相關引導的過程。關于這部分相關文章已經足夠多便不再贅述。但有一點，對于用戶的觀察，一定要放到政治經濟社會技術大環境中。
而業務方，相對用戶而言，是對于內部需求實現過程中需要進行配合的。而二者的關系及側重，則需要產品綜合業務類型、企業基因、產品基因、優先級等多方進行判斷。
如果你是剛剛接手一端產品，看看競品公司的設計并分析設計意圖，可以幫你快速的了解產品及行業。但是你在產品設計中做的決策，一定是在內部體系支持下的，因為不論業務再相似，也一定是有差別的，沒有思考直接借用大多會給自己挖坑。
（3）領導層及其他產品線
產品規劃過程，及方案的評審，都可能涉及到與領導層的溝通。如果你不是戰略制定者，如何正確的理解產品戰略訴求，并把自己的方案規劃及項目價值以最大限度表達給各負責人，也是考驗產品經理能力之處。
如果說內部團隊的溝通可以更好的把控項目，則對上的溝通可以配合領導對于產品線的管理。自己悶頭做自己的需求而不在意團隊/其他產品線/領導，很多情況下并不是什么好事。
2.2 實施階段相關角色
實施階段的角色參與一般是在原型確定，或者文檔細節完成后進行的，一般需要把握設計稿的完成節點、提測節點和上線節點，如果這之間有一些角色之間的節點沖突，便需要進行協調。
（1）UI/交互
規劃階段的產品及用戶定位等，可以幫助設計師把握視覺及交互層的基本方向。
產品提測到上線期間，如涉及產品界面樣式修改，會有一部分時間用于調UI。
（2）開發/測試
產品在平臺基本技術了解的情況下，加深對于前臺、后臺、接口等的理解，關注用戶行為和數據流動，設計過程中關注平臺差異和設計點差異，這樣做出的方案能夠減少開發階段的不確定。如果經歷的項目較多，或者對于團隊足夠熟悉，在迭代方案制定時基本就可以確定這版方案的大概開發和測試周期，及跟進時的風險點。
如果涉及到跨平臺的產品，比如APP內接入H5，原生和H5頁面進行互相跳轉，則需要進行不同端開發間的配合。
而基于平臺的不同，開發測試的迭代特點也不同，APP有版本的迭代發布審核且區分iOS、Android，H5可以隨時發布，小程序需要在微信公眾平臺后臺提交版本，這些特點在配合上是需要注意的。
（3）業務對接
如果你手里的項目是業務相關性很強的，則實施過程中如果有需求變動或者上線時間調整，都需要與業務方進行對接以方便對方有時間去做準備。
2.3 上線后的相關角色
（1）業務對接
主要是上線后業務、運營的對接，以及產品培訓。
（2）數據監測
針對想要達成的目的，進行相關數據的分析，以判斷迭代的效果。如果是業務類系統，則需要向內部業務人員收集反饋。根據這些分析結果，作為后續迭代參考。
3.?設計你的方案、推進下去并觀察結果
其實在第二步我們分析相關角色的時候，基本已經把方案設計和項目推進大概說了。這個過程無非就是針對第二步各個角色和你的需求，不斷的提高方案的成熟度和項目的可控性。而需求的識別與轉化、實際項目中的判斷力，還是需要實操去磨的。這里就直接分享一些項目過程中的經驗吧。
（1）短期方案和長期方案
不管是在迭代方案的確定中還是項目跟進過程中，都可能會遇到一些狀況需要處理。有些比較大不好直接改，有些比較小就可以直接調。這個過程中，一定要分清哪些是長期的處理方案哪些是短期處理方案。比如，新項目接近上線還有一些問題，這時候產品協調各個角色保證本次上線是短期方案，上線后針對團隊問題進行分析調整是長期方案。
（2）觸發幾率和嚴重性
這個主要用于產品上線時比較難改又發現晚的問題，或者是一些線上bug發現后的處理依據。比如：在商品支付項目中，訂單金額的計算或顯示錯誤就是嚴重性很高的問題，一旦發現是要盡早改的。但是比如一些UI問題，不在核心頁面展示且觸發幾率比較低，則可以考慮后續迭代時修改。
（3）尊重各個角色、但維護團隊核心訴求
不管是不同業務線的產品，還是UI/交互/開發/測試，還是相關的業務、運營，每個角色在團隊中都起著各自的作用。產品對于項目中各個角色的工作理解越深，對于項目的把控力就越強，項目推進及上線時的風險就越小。
但是合作過程中難免會涉及一些紛爭，溝通協調和解決是沒有問題的，但是一定要維護團隊核心訴求：就是團隊工作的高效和項目上線的質量。
以上就是這篇文章的主要內容了，照應文章開篇的問題，這個方法不妨一試。但是如果你問，讀了這篇文章是不是就可以毫無風險的去做一個從未接觸的產品了？
怕還是不能的，因為項目的規劃和跟進經驗還是有差別的，但至少，如果你在經手的每個項目中都這樣去思考分析，經歷的項目越來越多，當新的東西產生并交到你手上的時候，以往的思考就會作為你強大的后盾，幫助你對新產生的事物進行快速的拆解。
而如果你對于用戶、行業、大環境有足夠了解的時候，你就可以分析現下的問題，預測未來的發展方向提早布局，甚至去引導行業的發展。
事物的發展總是有規律的，有足夠的能力，就可以看清這脈絡、看到這之間清晰的流動吧。
作者：無良，公眾號：無良在想
本文由 @無良 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
寫的不錯