第1章 企業用戶研究方法探討

1.1 發掘用戶真實的需求

作者：鄧俊杰

在談這個話題前先分享一個小故事，這是我曾經一個同事講述的用戶需求案例。事情是這樣的，他的一個朋友是外國人，有一天來公司拜訪他，結束之后他送這位老外朋友出公司。老外朋友對同事說，他需要找前臺借一支筆。同事就問他做什么，他說需要朋友將自己手機上顯示的英文地址寫成中文，然后他打到的士后就可以給司機看，這樣司機就能把他帶回酒店。

同事舉這個例子是想告訴我們，他的朋友最原始的需求是“借一支筆”，而本質需求卻是“回到酒店”，這兩者相差甚遠。通常原始需求都是用戶自己想到的解決方案，認為可以解決自己的問題，而事實上如果能獲得用戶的本質需求，就可能找出更合理的方案來解決用戶的問題。

在做產品時，不論是產品經理還是設計師經常能從市場或運營團隊那里得到一些用戶的原始需求，例如這個顏色希望變成綠色，這里的字體需要更大，急需更省電的模式等等。很多產品經理和設計師信奉用戶至上，包括現如今很多聲稱具有互聯網思維的公司都強調用戶在產品設計和開發過程中的重要性，這個觀點并沒有錯，但是如果對用戶原始需求沒有進行任何分析就落地到產品中，這也是對用戶極不負責的行為，非常容易造成“頭痛醫頭，腳痛醫腳”的情況。

再舉一個實際案例，這發生在我們自己實際的產品中。云之家是一款移動辦公應用，有一個功能就是可以在手機上簽到，這樣員工到了公司附近就可以掏出手機在應用上打卡完成考勤，而不用走到公司的考勤機旁排隊用工卡打卡。有個公司的人力資源經理就給我們提了一個原始的需求：盡快把簽到提示音改為人聲。

簽到提示音是指在上下班時間前15分鐘手機發出的聲音提示，以提醒員工用手機簽到。我當時回絕了這個需求，理由有兩點：一是一般App的提示音都不會采用人聲，因為不夠優雅，例如我們在一些工作場合聽到一些人聲的電話鈴聲或是奇怪的提示音都會覺得對方不夠專業一樣；二是上下班時間前15分鐘，員工要么在公共場合（如地鐵、公交上），要么在辦公環境中（如還在開會），此時手機突然有人聲叫“簽到啦”會引起不必要的尷尬，體驗會不好。

但是這名人力資源經理并不認可，堅持認為我們的提醒聲音很普通，就是要改為人聲，需要給員工很強的提醒。如果僅僅從這個原始需求上來看，感覺是我們的提醒聲音不夠強烈或是不夠特別，可能會跟諸如微信、短信等其他應用的提醒音混淆。所以我跟這個人力資源經理溝通是不是可以讓員工自定義鈴聲，因為如果我們官方提供了一個人聲提醒，那究竟是用男聲還是女聲，用清脆的還是磁性的，用林志玲的聲音還是郭德綱的聲音？這將無形中夸大個人的好惡。人力資源經理覺得讓員工自定義鈴聲也可以，并且要求馬上就要落地到版本中。但是我自己又仔細想了一下，其實用戶自定義提示音的比例并不高，例如我們不少人還是只用默認的電話、短信、鬧鐘、日程的提示音，而且如果真的大家都來自定義提示音，那么一到某個時間點一個辦公室的人手機響起各種自定義的簽到提示音，也是很滑稽的。

所以我就跟這個人力資源經理繼續溝通，然后才發現了他的本質需求。他們公司原來是在一個特定的指紋打卡機上打卡的，每到上班時間，指紋打卡機前會排很長的隊伍等待打卡。現在采用了移動辦公應用，員工不用排隊打卡了，人力資源經理強行拆除了指紋打卡機。但由于剛開始執行還沒形成習慣，導致員工經常忘記打卡。該公司考勤很嚴格，忘記打卡或是晚打卡都要扣錢，員工就要在月底前打印紙質文件，然后再找兩個以上的證明人來證明自己當天只是忘記打卡并非曠工。而這名人力資源經理則要去考證這些證明，無形中增加了很多工作量，也提高了公司的管理成本。我們可以看到，這名人力資源經理的原始需求是將簽到提醒音改為人聲，實際上他的本質需求是讓員工減少忘記打卡的次數。在他看來只要將簽到提醒音改為人聲，那么明顯的提示之下員工自然會想起來打卡，大家都打卡了，他也就沒有那么多工作量了。

這名人力資源經理的原始需求和很多用戶的需求一樣，通常都是他們自認為的解決問題的方案，但是用戶對整個產品的考慮卻比較少，他們一般較難想到自己的方案對現有產品帶來的影響或是在一些場景下的不適。對于這個人力資源經理的原始需求我給出了更為人性的方案：首先如果員工在上班前忘記打卡，但是員工此時手機連上了公司Wi-Fi，或者GPS定位員工在公司附近，那么應用會給員工自動補打卡（同時還要結合一些手機傳感器數據，保證員工手機的確是在使用中，否則員工可能會拿個舊手機連著公司Wi-Fi一直放在公司）；其次如果員工真的由于各種原因忘記打卡，而且自動補打的機制也未生效，那么就判斷員工是否在工作時間連著公司Wi-Fi用我們的應用發過消息、傳過文件，有這樣的情況也可以證明員工并未曠工。通過這些相對智能和人性的判斷來降低員工由于未注意到提醒而忘記打卡的概率，從而解決這個人力資源經理遇到的問題。

其實如果再深入分析一下這個人力資源經理的需求，我們除了能發掘出他的本質需求外，還會發現他一個隱含的需求。例如他為什么這么急切地要求我們盡快落地增強提示的方案？我們來腦補一下他面臨的情況。他強行拆除了指紋打卡機，采用移動簽到，改變了整個公司員工的打卡習慣，結果導致了很多員工忘記打卡，員工需要找各種證明和審批，一定怨聲載道，甚至紛紛質疑這名人力資源經理當初的決策。所以這個人力資源經理的隱含需求極有可能是要盡快打消員工對于他強推移動簽到這個決定的質疑。能幫他解決這個隱含需求，或許他的本質需求也能迎刃而解。

所以我們可以看到用戶的原始需求跟他的本質需求和隱含需求可能差別很大，那么如何發掘用戶的本質需求和隱含需求呢？除了深入交流之外最好是能身臨其境，就以上面的案例來說，如果能到他們公司待上一段時間，當一段時間的員工可能會更有感觸。我又想起來一個案例，在一次業界交流活動中，有個設計師在西門子公司做大型醫療器械設計。他就跟我說大型醫療器械的設計要非常嚴格精準，但是設計師不是醫生，很多地方會考慮不到，于是他就跟醫生一起工作，醫生干什么他就干什么，時間長達三四個月，到最后他對人體的各種器官、血管都了如指掌了才開始進行設計。或許醫生的原始需求只是要掃描病人的某個部位，但是如果僅僅很簡單地去根據這樣的需求做設計和開發產品，最終的結果一定不理想，也難以捕捉到醫生的本質需求和隱含需求。

回到本文最開始的例子，“借一支筆”是原始需求，“回到酒店”才是本質需求，于是我的同事并沒有給這個外國人找筆，而是找了另外一個同事順路將其帶回了酒店。看，并非一定是用戶要求什么你就執行，仔細分析之后其實會有更好的方案。再深入分析一下這個外國人的隱含需求呢？其實是“跟司機用中文交流”，試想一下這個隱含需求解決了，他也就不會有剛開始借筆那一幕了。

To B產品面臨的角色有很多，不能簡單像To C產品那樣考慮通用的人性，企業里的老板、經理、基層員工，不同崗位職責的人都會有不同的需求。所以一款好的To B產品對不同角色的需求把握必須非常到位，只有了解到對應角色的真實需求才能設計和開發出合適的產品。