企業內應用的需求訪談是如何進行的？

分享一個企業內應用的客戶案例，特別是在系統改版的過程，你是否產生過疑問，身為 UX 的我們可以做哪些有價值的事情來幫助團隊？

不是所有的設計都要改變系統的產出結果，特別是在改版企業內應用的時候，人們最害怕的正是未知的改變。

我們受到邀請，協助一個客戶在他們積年已久的企業內部系統改版過程，擔任 UX 顧問，試試看能夠如何協助他們的資訊部門與設計師們。

企業內應用的改版，除了必要的專案目標與限制外，對 UX 而言，始於了解每一個使用情境背後的流程，以及尋找模式。

光是拿到功能清單或畫面是不夠的，我們還須知道有哪些關鍵的流程是如何確保不出差錯才行，這樣系統才能幫助內部的求單位每次都能通過理想路徑，達成想要的成果。

所以一切的設計，不是從出畫面給利害關係人提案開始，而是從需求訪談著手，我們需要問問的是，這些流程是否必須按照固定的順序完成？目前想調整的東西會面臨什麼限制？哪些事情上層特別重視？這些重視事情在不同的層級單位有相同的認知嗎？

在該客戶的環境中，過去企業內應用的各種需求，都是由需求單位填寫需求書，經過多次與資訊部門的會議敲定驗收條件後，再產出規格文件。

「為什麼還需要需求訪談？我們就是需求單位啊？」客戶內部的各個單位表現出不安。

需求單位對於「需求訪談」沒有概念，從來沒當過受訪者，他們會不斷追問要準備什麼文件？有沒有什麼格式的要求？是不是該先教育訓練之後才來「需求訪談」？

為了降低衝擊，我先訓練客戶的內部設計師如何進行訪談，讓他們感受到這是怎麼一回事。

我們以「申請進修事假」為例來做演練，我作主訪跟設計師討論他曾經的申請經驗，然後將他所遇到的過程，包含申請前不確定的事情、申請過程的來來回回確認或浪費的時間、申請後是否獲得回饋等等情境討論之後，一一寫成便利貼呈現出來，並且區分為任務流程與遭遇的困境。

我問客戶的設計師：「你檢視一下，目前討論的成果，是不是你們在申請這件事情的過程，大部分的人會遭遇的狀況？」

得到肯定的答案後，我繼續問：「如果你現在要討論這個流程如何改善，你認為問題大多數發生在哪邊呢？」

設計師很明確的指出其中一個步驟，迫不及待的想討論一些細節的解決方案，但被我先阻止。

我繼續問：「你再回憶一下，以前提需求的方式，跟現在討論需求的方式有什麼不一樣呢？」

客戶的設計師給了很明確的回饋，像這樣將訪談集中在人與任務上的情境，可以跳出系統介面，看到更多狀況。

確認大家都有跟上狀況之後，我再引導大家認識更深的一層：「那麼，這個流程遇到的問題，真的值得花時間改善嗎？你們過去是如何評估的呢？」

這一問還真把他們問倒，回想了一下，他們承認，雖然還是會填寫一些量化的效益評估，但基本上資訊部門只考慮實作上是否具備可行性，效益是需求單位自己要評估的。

但是企業內應用通常不會去裝數據分析來記錄用戶行為，也不一定很多環節會寫 log 來評估使用量，如果真的要分析，光是撈數據就是個麻煩的工程，特別是需求單位並非資訊人員，評估量化效益的這件事情跟自由心證沒什麼兩樣。

於是我根據使用情境建立一個估算模型給他們參考。

「以剛剛的申請進修事假為例子，你們想想看喔，你們全公司三千人，假設每個月有 1% 的人有申請的需求….」

​

我列了以下的試算模型：

所以生產力的損失為：

​

試算到這邊，我停下來問客戶：「聽說你們還有一百多個流程在這次的改版範圍內？你們現在有覺得需求訪談的盤點有價值嗎？」

客戶的資訊部門主管冒著冷汗：「顧問，我們沒有從這個角度想過生產力的損失，你的估算也很合理，只是聽起來……很……很驚悚。」

我總結一下：「其實我們應該正面看待這件事情，你們的系統是過去很多年一點一滴修改出來的，所以累積了很多無效率的環節，因為每次都是針對性的修改單點需求。

既然這次要進行改版，如果我們能夠用整體的角度來進行需求盤點，了解現在的使用情境哪邊造成效率的浪費，這些價值就是改版的意義，而不是糾結在畫面好不好看，或者有多少新需求想要實現。」

然後我問他們家的設計師：「如果把這個流程重新設計，幫公司省了每年三十幾萬，我們拿其中的一成來給你當獎金，你覺得好不好啊？」

設計師笑得很開心：「有獎金當然很好啊！」