需求就等於「我想要」?

功能不是需求,功能是實現需求的方法。

需求就是「我想要什麼什麼」?

我想要訂飯店,這就是需求了?

需求=產品特性或功能?

很多公司的需求等於一張功能列表,這張功能列表通常出自 PM 手中。

也許是 PM 看了公司 UX 部門提出的使用者研究報告後寫的一張功能列表。

但使用者研究報告能夠影響這份「列表」多少呢?全憑 PM 的個人想像

運氣好的話,開發人員會拿到一套連貫的產品規格,但不能保證照著規格開發出來的產品就是是使用者喜歡的產品。

產品需求=實現方式?

「這邊要放個下拉選單,選單裡有…」有人在說這句話的時候,他在心裡已經有個「預期中的假定解決方案」了。

為什麼畫面要這樣擺?因為不這麼做很奇怪/大家都這樣做?

使用者為什麼需要這個?不知道。

開發者拿到這種「預先假定好的解決方案」也很難進行開發,不知道使用者是誰、使用者在什麼情境下使用。

使用者會怎麼有什麼樣的行為?如何操作我們的產品?使用產品的動機?有想要完成什麼任務或目標嗎?

通通不知道。

也許你覺得知道這些又不會對產品造成多大影響….舉個例子:「一群遊客吃中餐,要讓他們吃飽」。

同樣都是「吃飽」,在登山途中的遊客和遊覽車上的遊客,他們怎麼面對「吃飽」這件事?

他們對於「飽」的標準一樣嗎?登山客需要更大量的體力,他們比較在意食物現點現做新鮮、還是快速補充熱量?遊覽車上的遊客需要多少食物才會覺得飽?

他們為什麼要吃飽?吃飽之後接著做什麼事?繼續爬山,還是上車前往下個景點?體力消耗相同嗎?

通通不知道的情況下,即使目標都是「吃飽」,但不同需求、不同行為,對吃飽有不同標準,開發者怎麼配合使用者進行開發?

猜!矇!通靈!

(員工:反正公司傳統就是這樣,一聲口令一聲動作,產品不討喜不賺錢干我屁事,別拖欠薪水就好。)

怎麼定義需求?

所以產品開發非常看重「需求」,使用者研究就是為了讓產品不要朝「錯誤的方向努力」

使用者為什麼要用我們的產品?他有想達到的目標或待完成的任務需要我們的產品幫忙。

所以我們的產品能提供哪些訊息和能力來完成使用者的目標?

設計產品行為之前,必需先定義產品是什麼、要做什麼。不然就變成「不知道來家裡吃飯的人有幾位、不知道是老人年輕人還是小孩,你就要開始備料做菜了」。

誰知道怎麼開始動手啊?連要煮幾道菜都沒有頭緒啊!

在和 PM 溝通的過程中,最常遇到的問題之一就是「需求和功能混為一談」,自以為釐清了需求,解釋半天,其實都在講「我為什麼要叫你做這個功能」。

功能不是需求,比如「會員註冊」不是需求。

「我想要會員註冊」,也不是需求,不是加上「我想要」3個字就等於需求啊!

為什麼想要會員註冊?

「我們平台需要區別每個會員的不同,才能記錄單一會員在我們平台做了什麼事,包含個人資料、購買清單等,方便追蹤會員喜好和習慣。」

這才是需求!

需求不是術語,有點像是「用一句話描述使用者+情境+動機」。

「我想要路徑導航」不是需求,「我想要有人告訴我路怎麼走」或是「我想知道去台北車站有哪些交通方式」才是需求。

你覺得 VS 我覺得

大家都知道「往錯誤的方向努力是件浪費力氣的事」,也都知道自己想的和對方想的往往有落差,抱怨「豬隊友太多」。

那為什麼敢不把話說清楚,敢靠「默契」做事?

不好好向專案成員說明目標,不一條條把現在遇到的問題列出來,甚至在還沒達成一致意見就直接敲定解決方案?

而且也沒有清晰、明確、客觀的方式評估設計是否適當,那你的工作要做到什麼程度算完成?判斷完成的標準是什麼?

同事:「我覺得我做完了。」
你:「我覺得你啥都沒做,亂搞一通。」

為什麼要用「明確、簡單易懂、可驗收」的方式把需求寫清楚,就是為了確認工作是否適當的完成,避免你認為的工作和我認為的工作不是同一件事。

同樣都是吃飽,「你覺得」一盤雞肉沙拉就能吃飽,但「我覺得」要喀兩個排骨便當才算吃飽,這時候怎麼確定滿足需求,有好好的完成工作?

由薪水比較高的那個人、還是音量比較大的那個人來決定?

Akane Lee

Akane Lee

幫助你快速學會 UI/UX 實用技巧,結合理論與實作,短時間內擺脫設計瓶頸,讓你每個專案都能交出滿意的成果!

Comments

wave
comments powered by Disqus

Press ESC to close