設計師做需求分析,如何避免這4個誤區?
說到“需求”,簡簡單單的兩個字,卻困擾了很多的設計師和產品經理。迷茫的設計師一邊做一邊猜,猜不對就改,改了還不對,回去再繼續改。總會有人給你提各種各樣的意見,你按他們的意見去改了,結果產品經理還是可能會拍桌子:完全不是我要的樣子?。?/p>
從iPhone開始火了用戶體驗,用戶體驗又火了交互設計。但是很多人學習新東西還是喜歡找模板,生搬硬套。網上那些Axure教程都挺火的,各種厲害的五毛錢特效、動態面板,反正是應有盡有。
我見過很多Axure軟件操作的高手,他們畫的原型看起來都很歷害的樣子。哎喲,還會動哦!但是當他們接到設計需求時,多數還是一臉茫然,或者總會遇到不斷被要求修改修改修改這樣的工作狀態。
我在面試的時候,像這種軟件操作的熟練程度,一般是不看的。因為我要找的不是畫原型和線框圖的工人,而是有想法的設計師。
不知道什么時候開始,多了一個我不是很喜歡的詞:干貨。什么是干貨?就是聽完一個講座,或者看完一篇文章,得到一個回去馬上就能使用的方法、技巧。比如我跟大家說,寫文章的時候,你給標題加一個數字,對于提高點擊率是有幫助的。(就好像這篇文章的標題~哈哈哈哈~)
但是很可惜,我今天不是來分享干貨的。
我今天不會教大家怎么做需求分析,主題并不是“設計需求分析的4個技巧”。所以,只是想在這里跟大家分享一下,在我過去的工作經歷當中,我做設計需求分析時,踩過哪些坑,也就是走過哪些誤區,應該如何避免。這些坑,如果你也不幸踩過,可能你會感同身受;如果你還沒踩過,要么是你太幸運,要么就是還沒開始,總之該來的總是會來的。
小技巧是很容易得到的,花點時間找一下就有了。但是,你能輕易得到的小技巧,別人也行啊。所以,小技巧算不上核心競爭力。建議大家回去還是要多啃幾本專業的書,多做幾個項目,又或是多找幾個同行前輩交流交流,那樣才扎實,才能得到真正是干貨。
要做好設計,就要搞清楚設計的需求。關于設計需求分析,的確是一門學問。在展開介紹幾個誤區之前,我想先跟大家說明一下什么是“設計需求”,這不是我自己創造的詞匯。所謂設計需求,就是指需要設計師配合完成的需求,比如設計用戶流程、用戶界面這些都是設計需求。
我認為一個產品的設計需求應該包括兩個方面,一是業務,二是用戶。所以,會同時包含業務目標和用戶體驗目標兩個層面。符合設計需求的方案,一定是既滿足業務目標,又滿足用戶體驗目標的。 設計師在做需求分析的時候,第一個容易踩的誤區就是:只關注用戶需求,不關注業務目標。
誤區1:只關注用戶需求,不關注業務目標
在實際工作中,設計師接到的業務需求,大多數時候,可能都是類似這樣的。比如,“把購買流程優化一下”、“課程頁面加一個分享的功能”、“討論區帖子要支持頂和踩”、“在消息中心提供清空操作”。說是需求,其實多半已經是一個解決方案了。完整的需求應該包含目標和期望,甚至是背景的描述。
如果你只是想把這個工作任務快點完成,那么就會照著需求方的方案去做,完全不管背后的目標和期望。這樣的事情做多了,充其量就是一個“努力的笨蛋”而已。這樣很危險,對產品,對你個人來說,都很危險。
對待業務需求,我們需要向對待用戶需求那樣,不斷地問為什么。去了解原因、背景。比如,為什么要優化購買流程?現在的流程有哪些問題呢?我們的用戶會分享什么樣的內容到微信里邊呢?做了這些事情,產品期望得到怎樣的成果呢?并且,我們又要如何來衡量設計方案的效果呢?
了解問題,往往比提供解決方案更加重要。愛因斯坦說:
如果讓我1個小時解答一道決定我生死的問題,我會花55分鐘來弄清楚這道題到底是在問什么。一旦清楚了它到底在問什么,剩下的5分鐘足夠回答這個問題。
了解問題,即知道了做這件事情的目的、原因、動機。目的通常是需求的出發點,而目標是期望的成果。之所以提出目的和目標兩個概念,是因為現實中就是會有很多人把目的目標混淆。如果直接用目的來指導設計,是空的,不夠具體,也可能和設計沒有直接關系。比如,要達到“獲得更多的注冊用戶”這個業務目的,只要多做做推廣,多掛掛廣告也是可以的。但“提高注冊轉化率”這個業務目標,就變得和產品設計有非常直接的關系了。
對目標最有幫助的事情,就是最有價值的事情。設計前先確認清楚相關的目標和期望,先問問做這件事想要達到什么效果。如果想不清楚,就先花時間搞清楚,不要因為時間急就匆匆忙忙地開始。努力固然重要,但比努力更重要的,是走心和思考。思考是一件難度更高的事,所以許多人寧愿立馬埋頭苦干,任勞任怨,不愿意花時間多想。這種看似勤奮的行為,實質是懶惰的,懶到腦子都不愿意轉一下。
像提升PV、UV、用戶數、轉化率、留存率、活躍度這些,通常是產品類的業務目標。而像提高市場份額、百度排名這些則是市場類的業務目標。這些目標一方面來源于產品的定位、規劃,以及業務目的;另一方面,這些目標也有可能來自于公司戰略、用戶的需求、數據的分析結果等等。
作為設計師,我們不僅需要關注用戶需求,還需要關注業務目標和相關的衡量指標,積極去思考如何將業務目標轉化為用戶行為。然后再去設計用戶流程和界面。我們通過規劃引導用戶使用,來幫助產品達成目標。
為了達成目標,通過設計需求的分析,給用戶創造動機、排除擔憂、解決障礙。其中,創造動機、排除擔憂是為了讓更多的用戶有更強的意愿使用;解決障礙,是為了讓用戶的操作變得更加有效、高效、容易學習使用。只要我們完整思考了這三個方面的因素,就能夠有效提升產品的用戶體驗,同時又能夠幫助產品順利達成業務目標。這是一件雙贏的事情。
用數據來監測產品,能讓你了解到用戶的使用情況,和產品的健康狀態。數據和用戶體驗并不是對立的,如果產品的改進讓用戶覺得很有意義,那么數據指標自然就會上升;如果用戶體驗沒有什么改變,就不能說你的改進很成功。
數據目標可以讓整個團隊團結起來,大家圍繞著一些清晰和有形的指標,各司其職。如果沒有數據指標,就很難衡量。如果無法衡量,就無法增長。
但是,數據沒有辦法告訴我們用戶體驗是否得到了改進。比如,你給消息中心增加了刪除消息的功能,刪除按鈕的點擊率很高,這并不能說明用戶體驗變好了。相反,很多用戶刪除了產品推送的消息,我們就需要好好想辦法改進消息推送策略了。有些問題也不是光看數據就能發現的,比如你無法通過數據得知為什么有那么多人愿意徹夜排隊搶購一只手機,因為品牌效應很難進行量化。所以,定性研究是一個非常好的補充。定量研究告訴你用戶做了什么,定性研究幫助你搞清楚用戶的感受,兩者需要相輔相成。
微信創始人張小龍在騰訊發表了一個內部演講,說“KPI是副產品”,我非常贊同。好的用戶體驗超越用戶期望,這種工作不是單靠KPI這種數據的東西可以指導的。團隊首先應該有用戶價值的導向,然后再來談數據,談KPI。KPI是副產品,但用好KPI并不會讓團隊辜負產品。
當業務需求和用戶體驗取得了比較好的平衡時,我們設計的就是一個健康的、可持續發展的產品。這是一個系統的工作方法,也是所有設計師必需要掌握的技巧。更是設計師幫助產品、幫助自己實現價值的關鍵基礎。
誤區2:需求分析是產品經理干的
以前我曾經有過一段這樣的工作經歷:交互設計師如果覺得產品經理的需求不完整、不靠譜,就把需求打回去,要求產品經理重寫。產品經理覺得交互設計師阻礙了產品的進展,交互設計師覺得產品經理需求不靠譜,相互埋怨。可是,沒有誰是老板派來搗亂的,對吧?當兩個角色相互不信任,就沒有辦法形成很好的合力。甚至,大家做這份工作都會覺得很吃力,工作體驗很糟糕,更別指望能做出好的用戶體驗的產品了。
到這里可能就有人就會說,那交互設計師和產品經理合二為一不就得了??墒俏也⒉贿@么認為。在資源許可的情況下,我的建議是,交互設計師和產品經理兩個角色還是分開設置比較好。因為設計師和產品經理的思維方式完全不同。
設計師通常關注產品的實現層面,而產品經理通常關注產品的業務層面。業務層面的意思是,假如你是一個在線教育產品的產品經理,為了達到管理層制定的提升20%的用戶活躍度這個目標,你最關心的并不是開發什么功能,要把界面做成什么樣,而是思考怎么樣篩選出一群人,讓他們來建立學習的氛圍。然后,再來制定一個個小目標和實現路徑,協調各個專業領域的人來達成目標。
所以,當產品經理在思考業務層的問題時,絕對不是功能是什么,界面應該做成什么樣。而是思考如何打通業務、爭取資源,建立產品的閉環,協調團隊,幫助產品順利達成目標。
再具體一點的話,設計師和產品經理各自都會負責不同的事情。比如產品經理主要負責收集市場和用戶的信息,確定產品的目標和方向;通過獲取更多公司可用的資源,來制定實施路徑和策略;通過協調不同的團隊共同工作,促進目標達成。而設計師呢,主要職責是明確業務需求和用戶需求,并確定相關衡量指標;通過提供可視化的解決方案供團隊討論決定,挖掘更多的可能性;通過建立和維護設計規范,來提升產品設計的品質和效率。
總之,產品管理的目的,是為了讓產品實現長期的用戶和客戶滿意,保持市場競爭優勢,把產品的商業價值發揮到最大。而交互設計的目的,是讓產品和用戶之間建立有機關系,有效實現用戶目標和產品目標。兩個角色有非常多的時候需要互補,但兩個角色的思維方式完全不同,所以我的建議是交互設計師和產品經理兩個角色還是分開設置比較好。
對于設計師而言,如果你的工作是在產品經理確認需求之后才開始的,那么建議盡快調整過來。你應該在產品經理分析目標市場、思考產品策略的時候就開始介入,只有這樣才能發揮設計的價值。在設計之前,對業務目標和用戶體驗目標的理解,不是別人可以代替你完成的。 很難想像,一個不了解需求的設計師,他能做出什么好設計。事實上,團隊里每一個角色都需要理解用戶需求,不只是產品經理、設計師需要。如果開發工程師不了解需求,沒有提出問題,那么就會有更多的工作浪費。
根據某些非官方渠道的數據統計,95%的產品團隊沒有設立專職的交互設計師,而70%的產品經理又是沒有受過專業的交互設計訓練的。所以,如果你的團隊暫時沒有交互設計師的話,也不要緊,設計需求分析的方法仍然有效。
誤區3:把自己當成典型用戶
在工作中,當我們討論用戶需求時,常常會聽到“我覺得”,而不是“我發現”、“我知道”。有的時候,我自己也避免不了,不自覺地就會這樣描述:“我覺得用戶不需要這個功能”、“我覺得用戶會找不到”。
我們也總是會聽到建議說“你要去多體驗體驗這些產品”??墒?,其實體驗越深入,離典型用戶就越遠了。為什么呢?
因為你的產品視角會阻礙你成為典型用戶。并且,你根本就不是典型用戶,你沒有他的經歷、沒有他的想法、沒有他的感受。盡管你可以假裝成自己是用戶,嘗試用你的同理心,去感受、理解他們。但那樣其實也頂多只是一個低成本,且效果一般的辦法而已。
人物角色其實是一個比較好的辦法。人物角色,英文Persona,它是對目標群體真實特征的勾勒,是真實用戶的典型。
注意了,人物角色是真實用戶的典型,不是一個真實的人?!八笔窃O計者通過對產品使用者的目標、行為、想法等等進行研究,再將這些要素抽象、綜合成為一組典型的產品使用者的描述,用來輔助產品的決策和設計。
一般來說,人物角色會包含一些個人的基本信息,家庭、工作、生活環境描述,與產品使用相關的具體情境,用戶目標或者產品使用行為描述等等。一個產品通常會設計3~6個角色代表所有的用戶群體。人物角色可以幫助我們把握關鍵需求、關鍵任務、關鍵流程,看到產品必須做的事,也知道產品不該做什么?!囤A在用戶》這本書對人物角色有非常詳細的介紹,有興趣的可以了解一下。
當我們討論到用戶需求時,可以試試用“張超不需要這個功能”(假設你的人物角色叫“張超”),來代替“用戶不需要這個功能”這種說法。這樣就會顯得更加的具體、形象,團隊也能夠很好地理解,避免爭議。然后,你回過頭來看看,你屬于這些用戶嗎,你是“張超”嗎?顯然,產品經理和設計師們,都不是“張超”,也不是“張超”那樣的用戶。90%的情況是這樣的!比如開發親子產品的人,他自己可能連孩子都還沒有。所以,你可以移情,代入典型用戶的場景去思考,但千萬不要把自己當成典型用戶。
說了不能把自己當成典型用戶,于是很多人又進入了另外一個誤區,那就是:完全聽用戶的。
誤區4:完全聽用戶的
用戶說什么就是什么,這種設計師就像是一個洗腳店的服務員,顧客說哪里不舒服,就按一下哪里,根據不去找原因、動機。當然,我并沒有說洗腳店的服務員都這樣,這只是一個比喻。
我個人的觀點,做設計并不是做服務。設計不是狹義的服務,我們的設計工作不是服務用戶,更不是服務產品經理。狹義的服務,會被理解為對方想要什么,我就給什么,通過這種方式來獲得對方短時、快速的滿意。
可用性大師尼爾森說“Don’t listen to users, watch users work”。意思是,我們不要光聽用戶嘴上怎么說,重要的是要去觀察他們的行為。當用戶跟你說,希望提供某一個功能的時候,你要去觀察這些用戶,他們有哪些特征、經驗、場景和行為,以及期望得到什么效果。 我們不能只聽用戶說出來的,而且要多去了解為什么,多去觀察他們有些什么樣的行為,去分析用戶的內在動機和原因。只有搞明白了用戶需求,才有可能做出用戶滿意的產品。
KANO模型定義了三個層次的需求:基本型需求、期望型需求、興奮型需求。
?基本型需求:
是指用戶認為產品必須要有的屬性或者功能。不滿足時,用戶就會很不滿意;滿足時,他們也無所謂滿意不滿意。比如手機可以打電話、空調可以制冷、電腦可以連WIFI、看視頻不要卡頓,這些都是基本的需求。
期望型需求:
要求提供的產品或服務比較優秀,但并不是必須的產品屬性或者服務行為。有些期望型需求連用戶自己都不太清楚,但的確是他們希望得到的。在市場調查中,用戶跟我們談論的通常就是期望型需求。比如,寫文章要自動保存、上傳大文件要支持斷點續傳、信號不好要支持自動切換片源,這些都是期望型需求,用戶可以比較明確的說出來。期望型需求在產品中實現的越多,用戶就會越滿意;沒有滿意這些需求時,用戶就會不滿意。
興奮型需求:
就是指超出期望的需求。當你提供一些讓用戶完全出乎意料的產品屬性或者服務行為,并且讓他們得益,他們就會非常興奮,從而提高對品牌的忠誠度。比如海底撈會給戴眼鏡的客人一塊眼鏡布、云音樂會根據你的口味推薦音樂給你、Mac電腦復制的文字可以在iPhone上粘貼,這些都是超出用戶期望的需求,用戶自己也不知道,更不會告訴你應該要有這些功能。
超越用戶期望的體驗,才稱得上好的用戶體驗。否則你的產品對用戶來說,可能是可有可無,被替代性很高的。所以,要提升產品的用戶體驗水平,我們就需要特別關注,去挖掘那些可以超出用戶期望的興奮型需求。
福特汽車創始人亨利·福特說,如果我當初去問人們需要什么,他們一定會說:我要一匹更快的馬。用戶的意見雖然重要,但是只問用戶的意見是做不出突破性的產品的。請問,亨利·福特制造的汽車,在當時屬于滿足哪種類型的需求?興奮型需求對吧,用戶當時自己也不知道原來有一個叫汽車的玩意可以用來實現“快速從A地到達B地”的目標。
需求的類型是會發生變化的。比如放到今天,“快速從A地到達B地”也許并不需要汽車,如果只是想要跟外地的同事開個會,用視頻會議系統就可以了。所以,需要遠程會議的人已經對汽車不再興奮了。
總結
對于基本型需求,我們要做的是確保萬無一失,并且要讓它非??煽俊F綍r可以用表格來幫助自己整理,避免做出“打不了電話的手機”這種無用的產品;對于期望型需求,通常是越多越好的,但是你可能要好好計算一下投入與產出比;對于興奮型需求,因為用戶自己也不知道,所以我們只能通過多觀察、多分析,提高這方面的敏感度,不斷推陳出新,定期給用戶驚喜,他們會更樂意把你的產品推薦給別人。
一旦每個需求都得到了明確的分類,我們就可以在需求收集的過程中對它們的優先級和可行性進行綜合考量和排序,然后制定實施計劃。當然,這些都是后話了,今天的分享到這里就結束了。
作者:我是阿智
來源:優設
- 目前還沒評論,等你發揮!