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則留言

              相關文章

              8個產品設計文件 PRD 的 SPEC 書寫原則小技巧

              寫產品設計文件 PRD 的時候,重點在於把「如何使用資訊物件的規則」想清楚,我最常被詢問的議題通常包括「到底要寫到多細?」、「有沒有 PRD 模版可以照填就好?」、「我又不會寫程式,要怎麼樣才能讓工程師看懂?」等等。

              • 2024 Apr 04

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

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

              • 2024 Apr 05

              用戶旅程中的五個 UX 洞察點

              在進入用戶旅程的討論之前,不妨先花個十秒鐘回憶一下:你的產品所服務的用戶,需要的成功是什麼?

              • 2024 Apr 05

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

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

              • 2024 Feb 05

              需求訪談的本質是了解期望

              「需求」這個詞彙經常出現在我們的日常生活與工作中,例如你要規劃一個產品推進到市場中,你要了解消費者的需求,或是你要與客戶合作完成一個專案,你也要了解對方的需求,這樣才能完成有價值的交付。

              • 2024 Apr 05

              撰寫產品需求文件 PRD 時的閱讀體驗七宗罪

              許多人覺得自己煞費苦心寫出精美的 PRD 沒人看,但閱讀者其實也很痛苦,因為看不懂。 文字的理解需要動用系統二的後設思考,會大量消耗認知心力,特別是像軟體需求溝通這麼困難的議題。 寫 PRD 不是在寫文學作品,重點在實用。 因此,簡單易懂、脈絡清晰、意圖明確的書寫原則,幫助閱讀者輕鬆理解,人家才看得下去。

              • 2024 Feb 02

              關於我們

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

              教育訓練

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

              聯絡我們

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