“一入 B 端深似海”...就這一句來開始話題吧，希望跟大家分享一篇小心得：「在 B 端產品設計中踩過的坑+趟過的淚之如何快速融入業務」，希望對想要往 B 端發展的同學有所幫助，畢竟你越了解業務，業務越需要你。

階段一：把握好入職前期的業務熟悉階段（大概 2 周時間）

剛入職的前 1-2 周，是很好的業務熟悉階段，在這個階段不會有迭代項目的設計壓力，也不會有產品/開發/測試同學來溝通 UI 問題...但我狠狠的錯過了這個好時機，所以揮淚總結如下：

1. 一定要擁有一個最全的測試賬號（測試環境+線上環境）

B 端產品用戶往往是兼具多種身份角色的，「員工 A」、「管理員 A」、「管理員 B」、「管理員 C」等等身份，這些身份權限既可能交差，也可能毫不觸及。所以擁有一個兼顧所有功能模塊的測試賬號，是了解業務的第一步。

2. 帶著角色身份，有目的性地操作

前期在使用系統的時候，千萬別站在一個旁觀者的角度，去審視這款產品。既沒有把自己當做「員工」去體驗整個實施過程，也沒有作為「管理員」去創建管理項目，在業務前期迭代設計中只起到了美化原型圖的作用。

當然這種「沒目的性的操作」還會帶來另一個非常不好的點就是：對功能的記憶點很模糊，一頓猛操作后自我感覺良好，認為已經搞懂了業務邏輯…卻沒有去思考為什么當時要這樣設計（是只為了滿足業務的被動需求還是設計方案的局限，又或是基礎技術方案的限制，站在不同的角色場景中，體驗是否順暢合理，是否還有其他更優化的設計方案）。這些「思考點」其實都可以簡單的記錄下來，到項目迭代中有涉及到這些點的時候，可以再去深挖。

階段二：拿到產品需求后的準備工作（立項-概設階段）

這個階段需要輸出設計方案的思考點，立足用戶場景，滿足業務需求，與產品經理密切溝通需求與設計方案。

1. 本次迭代涉及到了哪些模塊，是否在前期都有線上的實操體驗？

如果前期沒有操作體驗過，那咱就在了解「需求」想要解決的用戶場景后，帶入角色的去體驗模塊。

2. 是全新功能設計還是既有優化？

這可以初步的判斷一下時間排期，設計的優先順序，是否需要用到「體驗畫布」去擬定方案，是否需要參考「競品分析」等各種輔助設計工具（這些都是需要花時間的，緊張的迭代周期不可能滿足所有需求都應用到這些）

3. 溝通（產品經理、測試、其他業務線的設計同學）

在需求分析階段最需要緊密聯系的人就是產品經理，了解他們在業務設計階段的方案，去參考其他競品是否有利于我們的產品設計。但產品經理站的角度往往僅是滿足被動的業務需求（功能層面上）。在滿足功能的同時是否有更好更順暢的體驗設計（體驗角色是偏「學員」身份多一些，還是滿足「管理員」身份多一些），這是我們需要跟產品經理溝通--梳理--擬定方案的。

充分「利用」好測試同學，因為他們其實才是最了解功能模塊的人，每天不計其數的操作，讓他們甚至比產品經理更加熟悉模塊。產品需求是否設計合理，測試其實更有主動權。

如果你所在的公司擁有多業務線，其實在一些共性的功能模塊上，還可以多多與其他業務線的設計同學們聯系，視覺+交互上是可以借鑒，既能滿足公司品牌調性一致，也能多一項設計參考，共同進步嘛...

4. 形成自己的需求清單

我之前用的方法是直接把產品的需求文檔打印出來，在上面做筆記，但后來發現這種方式不僅費紙，效率也不高。現在直接在 sketch 文檔里專門建立一頁，把「業務背景」、「目標」、「產品解決方案」、「設計方案思路」「...」都羅列出來，隨時都可以跟蹤記錄下每一次討論的結果。在后續的畫圖中，是否畫著畫著就偏離了「目標」，也可以隨時檢查。

階段三：設計實施階段（不要局限于同類競品設計參考）

階段四：走查階段

你是不是也會遇到視覺走查不完整的情況，有些模塊細節點會被遺漏。因為走查階段是在開發功能都提測以后，但最充裕的時間可能都沒有 2 周（中途還有開發調整修改的時間、有些功能點還需要反復去看）所以時間很緊。如何才能保障至少走查兩輪呢。

之前一直都是在現有的測試項目上根據迭代的功能測試，走查的界面特別零散，很容易遺漏。但如果一開始我們就創建了「專屬賬號」，在熟悉整個流程的情況下，對新迭代的需求進行復核，操作就會是連貫的，步驟是緊密的，就會把很多細碎的點串聯起來了。

寫在最后

希望大家別只顧著卷，被工作節奏打亂了自己的腳步…文章寫得有點幼稚，但希望能對小白菜們帶來些幫助啟發，大家一起進步。