0
  • 登入
  • 首頁
  • 2025開課計劃表
  • UX 靈感庫
    回主選單
    • 【研究報告】職場衝突情境
    • 需求訪談
    • 產品需求文件 PRD
    • 從零自學UX
    • 用戶旅程
  • UX 專家服務
    回主選單
    • 企業UX顧問服務
    • 企業內訓
    • 一對一諮詢
  • Podcast 節目
  • 註冊
  • 登入
  • 0
  • 首頁
  • 2025開課計劃表
  • UX 靈感庫
    【研究報告】職場衝突情境 需求訪談 產品需求文件 PRD 從零自學UX 用戶旅程
  • UX 專家服務
    企業UX顧問服務 企業內訓 一對一諮詢
  • Podcast 節目
  • 文章總覽
  • 分類
  • 需求訪談 (4)
    • 產品需求文件 PRD (5)
      • 從零自學UX (2)
        • 用戶旅程 (2)
          • 使用者研究報告 (1)
            用戶研究 (1) 職場溝通 (1)
            1. 首頁
            2. 部落格
            3. 如何看懂 B2B 產品需求訪談的常見地雷?

            如何看懂 B2B 產品需求訪談的常見地雷?

            2024 Apr 05 需求訪談
            內容目錄
            1. ▋直接指示你具體的規格,但邏輯矛盾 ▋
            2. ▋要求你先進入執行,但講不出交付標準 ▋
            3. ▋跨部門流程,每個人的說法各自解讀 ▋
            4. ▋總結一下

            你是 B2B 產品開發團隊的一員嗎?

            相對於面向一般消費者市場的軟體產品,其實更大比例的軟體產品設計工作,發生在企業端的需求上。

            在過去我接觸到的案例中,B2B 產品的需求訪談往往不是什麼輕鬆的經驗,因此我想透過這篇文章與你分享有什麼常見的地雷?以及面對這些地雷的拆彈原則是什麼?

            常見的地雷有:

            • 直接指示你具體的規格,但邏輯矛盾
            • 要求你先進入執行,但講不出交付標準
            • 跨部門流程,每個人的說法各自解讀

            ​

            ▋直接指示你具體的規格,但邏輯矛盾 ▋

            我還是產品經理的時期,曾經遇過一個同事跑來找我談需求。

            他說:「你們有空嗎?下週能不能在 OO 頁面上加個圖表?」

            我問:「你是因為什麼狀況,所以需要圖表功能呢?」

            他回:「行銷希望企業用戶寫完問卷之後,可以看到一些回饋。」

            我又問:「為什麼會希望企業用戶可以在那個時候看到回饋呢?」

            他回:「現在問卷的填寫狀況不好啊!想說放一些回饋比較吸引人。」

            我:「欸?可是圖表放在問卷填寫之後的頁面,用戶在填寫前還是看不到啊?為什麼這樣可以解決填寫狀況不好的問題?」

            同事:「不行嗎!?」

            ​

            如果我不在乎對方要什麼,只要許願就照單全收,那麼光是處理這類矛盾的需求就飽了。

            ​

            更糟糕的是,通常這類討論需求的情境中,往往要你在第一時間就壓上時程,在你還不確定問題的樣貌之前,就問你什麼時候可以開發完成。

            ​

            但我們七趕八趕的加班完成這些工作,有用嗎?

            如果這個需求沒有解決問題,問題還是會回到我們手上,一而再的修改。

            ​

            所以第一個 B2B 需求訪談的拆彈原則是:先釐清真正的問題與影響範圍,才評估解決方案

            ​

            ▋要求你先進入執行,但講不出交付標準 ▋

            另外一個情況是,要求你先規劃一個流程,可能是競品有這類功能,也可能是客戶內部的某個需求單位曾經許願過。

            但要求你設計這個流程的人,他卻無法回答最重要的關鍵問題:交付標準。

            ​

            誰要使用?不知道。

            他會怎麼使用?你先想。

            ​

            會發生這樣的情況,往往是因為來到你面前的這位需求方,他只是一個代理人,他並不真正掌握問題發生的情境。

            ​

            在這邊我們要掌握一個基礎原則,那就是 B2B 產品的用戶目的到底是什麼?

            ​

            如果說大部分產品的終極目的是:「幫助使用者成為更好的人。」

            那麼在 B2B 產品的情境中,最基本的就是:「幫助使用者完成他的工作。」

            ​

            這個時候,我們可以使用 STAR 原則,來進行行為職能的訪談,來找出具體的使用情境,如此才能定義如何幫助使用者達成目標。

            ​

            使用 STAR 原則來調查行為職能,通常會以這四類問題切入:

            「有哪些情況會跟這個需求產生關係?」(情境 Situation)

            「什麼樣職位的人會需要參與?他們的職責目標是什麼?」

            (任務 Task) 「他們會採取什麼行動?為什麼選擇這樣的作法?」

            (行動 Action) 「預計會發生哪幾種結果?什麼因素會產生影響?」(成果 Result)

            ​

            ▋跨部門流程,每個人的說法各自解讀 ▋

            即使運用了 STAR 原則來調查行為職能,還是會遇到一個艱困的問題:跨部門。

            ​

            有時候,你遇到不同職能的人與你討論同一個工作流程時,感覺像在討論完全不一樣的議題似的。

            ​

            你可能覺得是在討論需求,另外一個角色他卻稱呼這叫提案,還有人認為這就是開會。

            ​

            我們會遇到此狀況的第一個原因是「本位主義」,每個人都是從自己的觀點出發來看待問題,採用自己熟悉的觀點才能夠降低認知負荷。

            ​

            第二個原因是知識的詛咒,同一群人在同樣的領域久了,習慣用自己內部的溝通語言,而忘記小圈圈之外的人聽不懂他們對話內容中許多隱含的資訊。

            ​

            身為圈外人的我們,可以如何處理呢?

            「任務步驟分析」會是你梳理跨部門流程的好幫手。

            ​

            任務步驟分析關注三件事情:

            • 可獨立:每個任務步驟由單一角色執行
            • 可交付:每個任務步驟都產生具體可驗證結果
            • 可置換:對任務步驟進行抽象化,可使用不同解決方案達成同樣目的

            ​

            例如一個請假的流程,可能涉及到請假人、代理人、審核主管以及人事 HR。

            我們要先知道的並不是具體假別的計算規則與欄位有哪些。

            ​

            我們要釐清的是,整件事情有哪幾種觸發的起點?

            從起點抵達終點所需要的交付條件是什麼?

            可共用的任務步驟有哪些概念?

            如何提供客觀證據來驗證某一任務步驟已經完成?

            某一任務步驟有哪些不同形式的提交資料方法?

            上一任務步驟交付的結果,下一任務步驟的單位會如何運用?

            ​

            先整理出每一個關鍵任務步驟客觀的可驗證結果,才去釐清這些結果是用什麼規則、哪些欄位組合出來的。

            ​

            最怕的就是被一句話唬弄過去:「輸入不同的條件會得到不同的結果。」

            客觀來說,這是一段沒有意義的廢話,因為我們無法從中提取出可驗證範圍的規則。

            ​

            你會發現,有時候同一個流程,A 企業是幾個部門合作完成,但在 B 企業卻是同一個部門內自己在處理,到了 C 企業卻通通是同一個人搞定的。

            ​

            識別任務步驟的切分點,能夠讓你找出適當的顆粒度,用來設計產品的流程。

            而不是根據 A 企業的部門分工,拿去要求 B、C 企業按照別人的營運邏輯來分配人力。

            ​

            ▋總結一下

            我們在 B2B 產品的需求訪談中,有三類常見的地雷,我們的拆彈原則有:

            • 遇到直接許願的需求方,先釐清真正的問題與影響範圍,才評估解決方案。
            • B2B 產品的用戶目的,就是能夠順利完成工作,可以透過 STAR 原則,了解情境、任務職責、具體行動、關鍵成果。
            • 遇到橫跨多個部門的流程時,運用任務步驟分析,找出適當的切分點。

            ​

            以上是我在進行企業內應用的需求訪談時,也經常採用的需求訪談方法,分享給你。

              • 分享此文章
              0則留言

              相關文章

              UX 身為一種多巴胺職業,我想說的是......

              用戶體驗這門領域的工作職業令人嚮往。但現實中的商業環境,UX 只是一種次文化,一小群人信仰著。如果你渴望透過這份工作改變人們,職場環境很容易讓你認知失調。

              • 2024 Jul 03

              從用戶旅程思考你的顧客終生價值 LTV

              當產品布局有明確策略的時候,你同時也會看到相當穩定的用戶旅程樣貌。然而用戶從陌生人轉化成為顧客,並不是故事的終點,年復一年,如果他沒有成為更好的人,或許也會放棄了追求,消失在我們眼前。

              • 2024 Apr 05

              如何從零開始自學 UX(一)掌握基礎就從易用性開始

              「沒有相關背景的人,該如何自學 UX 呢?」這是我開始寫作與教學以來,蠻常被問到的議題。 我想開啟一個寫作主題系列,與你分享如何從零開始幫助自己自學 UX 的路徑,在這個主題系列中我會跟你介紹「學習目標」、「推薦掌握的知識與技能」、「自己練習的方法」。

              • 2024 Feb 05

              在需求訪談中辨認多方利害關係人的類型

              身為專業工作者的我們,都經常會遇到的一個局面,那就是一個工作任務中有許多利害關係人的聲音會影響執行的決策。當需求雜亂如麻,每個人都認為自己的意見很重要,都想逼著我們實現那些願望時,最難的不是執行,而是如何開始面對這一切麻煩。

              • 2024 Apr 05

              產品需求文件 PRD 到底要寫到什麼程度?

              「如何建立更系統化的交付文件?」 「如何撰寫開發也看得懂的PRD文件?」 「因合作PM不會寫PRD也不會出spec,想了解最基本的PRD模板元素應該要列到多細才堪用?」 「如何寫出清楚明瞭讓工程與外部人士都了解的規格書?」

              • 2024 Feb 05

              關於我們

              • Soking 使用手冊
              • 免費電子報

              教育訓練

              • 購課權益
              • 2025年開課計劃表
              • 企業內訓方案

              聯絡我們

              • 公司名稱: 千綺創意設計股份有限公司
              • 統編: 90766379
              • 隱私權政策
              COPYRIGHT© All rights reserved | Powered by 路老闆