(網(wǎng)經(jīng)社訊)本文內(nèi)容不局限于交互設(shè)計領(lǐng)域，更多會涉及職業(yè)轉(zhuǎn)型面臨的問題及解決思路的探討。
筆者在學(xué)生時代的專業(yè)是工業(yè)設(shè)計產(chǎn)品方向，因機(jī)緣巧合，當(dāng)初校招入職A廠時選擇了產(chǎn)品運營崗位。由于每家公司的業(yè)務(wù)驅(qū)動有側(cè)重，A廠的運營較其他公司而言更為強(qiáng)勢，所以也更容易接觸業(yè)務(wù)前線以及了解整個業(yè)務(wù)運轉(zhuǎn)流程。
目前作為一名C端產(chǎn)品運營轉(zhuǎn)型到B端產(chǎn)品交互，負(fù)責(zé)的第一款產(chǎn)品是B端SaaS產(chǎn)品（Software-as-a-Service），覺得富有挑戰(zhàn)也很有趣。工作中會更多的關(guān)注橫向業(yè)務(wù)思考能力與縱向設(shè)計專業(yè)度的結(jié)合。
本文內(nèi)容不局限于交互設(shè)計領(lǐng)域，更多會涉及職業(yè)轉(zhuǎn)型面臨的問題及解決思路的探討。
今天主要與大家分享以下幾個思路：
ToC運營轉(zhuǎn)行ToB交互面臨怎樣的職責(zé)差異？
應(yīng)具備怎樣的橫向底層能力與職業(yè)素養(yǎng)？
該如何培養(yǎng)縱向交互設(shè)計專業(yè)度？
一、To C運營與To B交互的職責(zé)差異
我們必須認(rèn)識到作為To C運營和作為To B交互，在切入項目時的視角有何區(qū)別，只有先認(rèn)識到職責(zé)的差異，才能選擇正確的切入方式。
（圖1 – C端產(chǎn)品運營與B端交互設(shè)計的職責(zé)差異）
1. 產(chǎn)品用戶角色的差異
C端產(chǎn)品面對的用戶是單角色用戶，即整個產(chǎn)品生命周期內(nèi)使用產(chǎn)品的用戶群，范疇可理解為新用戶、KOL及付費用戶。
B端產(chǎn)品通常面對的是多角色用戶，即企業(yè)管理者和產(chǎn)品的真正使用者。
2. 業(yè)務(wù)需求分析的差異
C端運營更側(cè)重于用戶訴求，比較感性和發(fā)散。在構(gòu)思方案時會更關(guān)注熱點、玩法以及用戶抓手，簡而言之就是我依靠什么方式去拉新、留存或引導(dǎo)用戶按照我們設(shè)定的路徑使用產(chǎn)品，是一個轉(zhuǎn)化和教育用戶的過程。
B端交互更側(cè)重于產(chǎn)品需求分析和商業(yè)目標(biāo)理解，業(yè)務(wù)驅(qū)動，相對較理性。交互的邏輯是以不同角色使用產(chǎn)品的路徑為切入點考慮的，要平衡業(yè)務(wù)需求、不同角色用戶對該產(chǎn)品的使用習(xí)慣以及學(xué)習(xí)成本之間的關(guān)系。
綜上，C端運營著重處理用戶使用產(chǎn)品始末過程中，能否通過活動及推廣，使產(chǎn)品使用數(shù)據(jù)提升？能否通過用戶運營及數(shù)據(jù)分析，使產(chǎn)品周期延長？
B端交互著重處理設(shè)計方案是否合理的實現(xiàn)了需求？是否在滿足需求的同時減輕了用戶學(xué)習(xí)成本，縮短了使用路徑？是否在完成了業(yè)務(wù)目標(biāo)的同時兼顧了全局方案的統(tǒng)一性和可拓展性？
二、橫向底層能力與職業(yè)素養(yǎng)
筆者無論在轉(zhuǎn)行前還是轉(zhuǎn)行后都一直覺得，想要做好交互，必須權(quán)衡好產(chǎn)品思維、業(yè)務(wù)分析、用戶視角、專業(yè)審美這四個因素。如果說這四個因素是筆者認(rèn)為轉(zhuǎn)行交互所需的職業(yè)能力，那么底層能力就是無論你轉(zhuǎn)行到什么崗位，都需要具備的能力，比如：對新知識的接受與學(xué)習(xí)能力、邏輯分析能力、結(jié)構(gòu)化思維、商業(yè)思維等。
這些能力將幫助你快速的理解你當(dāng)前所處的業(yè)務(wù)，所需解決的問題，提高自己的上手速度。
（圖2 – 橫向底層能力與職業(yè)素養(yǎng)）
養(yǎng)成好的思維習(xí)慣，比解決具體問題本身更重要。這也是筆者對自己的要求（考慮到篇幅，此處不對每種能力展開討論，因為每個展開都可以再寫一篇）。
三、不斷提升縱向交互設(shè)計專業(yè)度
筆者作為轉(zhuǎn)行的交互設(shè)計師，在日常工作中會更注意交互方案輸出的反饋，以及業(yè)務(wù)場景案例的積累。從前期需求分析–信息架構(gòu)梳理 –交互方案輸出 –開發(fā)跟進(jìn) –上線復(fù)查，在一次次完整的迭代周期中，不斷完善設(shè)計方法、調(diào)整設(shè)計思路。
（圖3 – 縱向交互設(shè)計專業(yè)度）
1. 如何做好需求分析？
在筆者負(fù)責(zé)B端產(chǎn)品項目中，由于涉及的模塊功能相對獨立且邏輯復(fù)雜，所以在整個產(chǎn)品設(shè)計過程中，需求分析的能力約占50%。深入業(yè)務(wù)需求不僅使自己的交互方案更合理，同時也是幫助產(chǎn)品經(jīng)理把控和完善需求的過程。
我們從如下幾點進(jìn)行梳理：
整理需求：將需求點分模塊分條記錄（手繪或Xmind）；
明確優(yōu)先級：與產(chǎn)品確定需求優(yōu)先級（手繪或Xmind）；
梳理信息架構(gòu)：以滿足需求為前提結(jié)合用戶使用習(xí)慣梳理功能架構(gòu)（手繪或Axure）；
多維度考量：資源可控時可展現(xiàn)多種設(shè)計方案（Axure）。
2. 如何做好方案輸出？
好的交互方案需同時兼顧滿足產(chǎn)品需求、技術(shù)可實現(xiàn)、功能結(jié)構(gòu)統(tǒng)一、流程清晰明了、界面簡潔美觀。每個產(chǎn)品或功能都不會一蹴而就的產(chǎn)生“完美”方案，在整個項目組遵循“最小可行產(chǎn)品”（MVP）方式小步快跑時，設(shè)計方案也存在“最低可行體驗”。
我們從如下幾點進(jìn)行梳理：
滿足業(yè)務(wù)訴求：多呈現(xiàn)幾種設(shè)計方案，有時候pk的不是90%和10%的方案，而是55%和45%的方案；
保證技術(shù)可行：多思考場景的異常情況，因為任何極小概率發(fā)生的情況，對技術(shù)而言都有一個邊界需要界定；
信息架構(gòu)合理：涉及多模塊聯(lián)動的功能型產(chǎn)品，保證信息架構(gòu)、頁面布局、交互組件的統(tǒng)一規(guī)范很重要。
一個Tips：
審美意識是全人類的，但作為設(shè)計師則更需要培養(yǎng)。審美無他，請多看！多看！多看！說三遍都不夠。不要將范圍僅局限于設(shè)計領(lǐng)域的案例，而是要多關(guān)注生活方方面中那些優(yōu)雅的、實用的、無意識的細(xì)節(jié)和規(guī)律。從建筑中學(xué)習(xí)、從游戲中學(xué)習(xí)、從食物中學(xué)習(xí)…
因為筆者自己是一個好奇心很重的妹子，所以時常會對一個問題發(fā)起奪命連問。好奇心幫助你關(guān)注問題，獨立思考幫助你發(fā)現(xiàn)問題，保持溝通幫助你補(bǔ)全信息，從而才能滋生出更貼切的設(shè)計。
總結(jié)
筆者相信無論處于業(yè)務(wù)的哪個環(huán)節(jié)或職位，符合商業(yè)預(yù)期，為用戶創(chuàng)造價值，才是一款產(chǎn)品最好的出路。接觸B端業(yè)務(wù)大半年以來，也是一個不斷調(diào)整思考方式，豐富自身能力圖譜的過程。
本文均是筆者轉(zhuǎn)型B端交互設(shè)計師的自身感受和實際思考，考慮到文章篇幅，所以未展開討論每個小節(jié)的內(nèi)容。不過，期待與大家探討更多SaaS產(chǎn)品或職業(yè)轉(zhuǎn)型的話題。（來源：人人都是產(chǎn)品經(jīng)理 文/劉瑩瑩 編選：電子商務(wù)研究中心）
