如何對接需求,精準避坑?

3 評論 4894 瀏覽 41 收藏 12 分鐘
🔗 产品经理的不可取代的价值是能够准确发现和满足用户需求,把需求转化为产品,并协调资源推动产品落地,创造商业价值。

在產(chǎn)品設計的工作流程中,設計師有時也需要參與到需求評審、需求設計等階段中,這個時候,設計師要怎么避開需求評審或需求對接中的“坑”?本文作者便結合自身經(jīng)驗進行了總結分享,一起來看看吧。

通常設計師會參與到需求評審、需求設計、設計評審、研發(fā)跟進、設計驗收幾個階段。在每一個階段,設計師應該都踩過“坑”,本文主要復盤作者在需求評審(需求對接)里遇到的典型問題,并分享解決辦法。

需求評審時需要思考哪一些內容:

  1. 需求背景是什么(用戶是誰、遇到什么問題、怎么解決問題)。
  2. 需求上線想要達成什么樣的目標(量化指標)。
  3. (產(chǎn)品介紹方案后)初步思考功能能不能實際解決背景里闡述的問題,有疑惑及時提出。
  4. 初步思考實現(xiàn)方式,若產(chǎn)品方案和設計師的認知有很大偏差的情況下,及時提出,避免設計師按照自己的想法修改后方案被pass,因為產(chǎn)品可能基于某方面考量,不得已選擇此實現(xiàn)方案。
  5. 確定交付日期,避免產(chǎn)品經(jīng)理瘋狂催稿(因為設計師可能不止對接一個產(chǎn)品,但是有的產(chǎn)品會想當然你接下需求就馬上開始做,并且給你主觀預估交稿時間)。若交付時間比較緊,來不及完成,可以和設計師商量先完成一部分交付進行開發(fā),后續(xù)在補交未完成部分。

一、需求價值不明確

背景:每個季度員工需要填寫KPI和KPI完成情況,季度末領導對員工績效完成情況進行評定,若員工對評定結果不滿意,可以發(fā)起績效申訴,然后由HR邀約員工和領導進行面談,并填寫通知申訴結果。

問題:績效申訴在整個公司一年大約0-3起,使用率非常低,值得做嗎?

方法:針對此類型的需求,思考3個方面。

  1. 該功能能幫助用戶解決什么樣的問題,是否符合產(chǎn)品目標(降本增效)。
  2. 用戶量有多少?使用是否頻繁?
  3. 需求投入人力和實際功能上線后帶來的價值是否成正比。

*當然一切的方法都敵不過領導或者需求方的我就是要這個功能,如果需求不合理但是非做不可的情況,可以根據(jù)緊急程度適當調整優(yōu)先級。

應用:

  • 該功能能幫助用戶解決什么樣的問題,是否符合產(chǎn)品目標(降本增效)——該功能能夠幫助員工更便捷申訴、HR更快的查看申訴資料。
  • 用戶量有多少——申訴的用戶是全公司,處理HR是固定的幾個人之一。
  • 需求投入人力和實際功能上線后帶來的價值是否成正比——需求投入人力約48h+ 但是用戶實際使用一年幾分鐘。

結論:1次申訴節(jié)約時間成本約4分鐘(根據(jù)打字和手寫速度估算,正常人手寫每分鐘25+字,電腦打字每分鐘120+字),研發(fā)投入2880分鐘需要處理720件申訴,花費約240年才能大概回本。

當然這個只是大概的估算,一方面HR團隊和研發(fā)團隊的薪資不同,無法直接對比時間成本,另一方面過程中可能有別的突發(fā)事情是不可預料的,比如申訴資料查找在電腦可能2分鐘找到,但是紙質的可能丟失,又會帶來一系列的問題,需要時間人力處理。

二、產(chǎn)品方案不合理,不考慮實際場景

背景:貨運司機會根據(jù)車輛調度員的計劃進行發(fā)車,也會有不在計劃內的發(fā)車任務,因此設置了加班車&臨時發(fā)車的入口,方便快捷登記。

問題:加班車和臨時車都是在常規(guī)班車以外的特殊發(fā)車,是兩個字段相似且不同性質的兩個登記流程。但是產(chǎn)品經(jīng)理的方案里只外露了加班車登記的入口,然后點擊默認進入加班車登記,然后通過提交后校驗,決定是否再轉入臨時車的流程。站在申請臨時發(fā)車用戶角度,沒有直接入口操作非常不便。

方法:很多時候產(chǎn)品經(jīng)理給的方案是未經(jīng)探索和調研,只是功能層面的思考,功能走通即可。因此在對接產(chǎn)品需求的時候設計師需要有自己獨立思考,學會不斷提問(可以采用5WHY分析法)。

應用:

  • 為什么要隱藏臨時發(fā)車入口——因為加班車和臨時車之間有邏輯需要校驗。
  • 這個邏輯是用戶自己能判斷,還是必須系統(tǒng)來校驗——用戶可以自己判斷。
  • 那用戶想要直接申請臨時發(fā)車的時候怎么辦——只能先提交加班車,再提醒轉入臨時發(fā)車。
  • 為什么不可以直接申請臨時車——(支支吾吾……)。
  • 臨時發(fā)車申請的使用頻率高嗎——占場景的80%。

*在和產(chǎn)品對接的過程中,產(chǎn)品不清楚場景是一方面,可能還會基于不愿意承認自己錯誤這一心理要素,給你錯誤引導,所以設計師要學會根據(jù)業(yè)務理解、競品、參考資料等獨立思考,分析需求。

結論:B端是以效率為本,突出顯示高頻的操作按鈕,可以幫助用戶節(jié)省操作成本,提升產(chǎn)品滿意度。

三、場景考慮不全面

背景:連續(xù)兩次績效不合格的人會被HR邀約面談,制定接下來的改進計劃,并在績效改進中實時跟進改進結果。

問題:產(chǎn)品經(jīng)理直接將線下的績效改進表格發(fā)過來,然后告訴填寫入口在哪里,就讓設計師開始設計。表面看起來就是一個績效改進填寫的頁面,但是其實流程涉及三類角色,每個角色入口,做的事情都不一樣。

方法:可能基于時間關系和產(chǎn)品做事的風格不一樣,有的需求拿到手里其實是非常表面的,需要設計師先梳理流程和角色,然后基于業(yè)務目標進行設計。

應用:

梳理流程:

梳理查看頁面不同角色操作:

結論:這不是一個頁面的設計,入口頁、編輯頁、查看頁、通知,是一個閉環(huán)的流程的設計。

四、不清楚要什么

背景:財務總監(jiān)想要做一個工作臺,方便財務各個角色的人員可以快捷的通過工作臺處理日常工作事項,財務管理者可以通過工作臺直觀的看數(shù)據(jù),輔助管理。

問題:需求是財務總監(jiān)傳達給產(chǎn)品,但是并沒有說明需要哪一些數(shù)據(jù)和內容,于是產(chǎn)品讓設計除出了一版初稿給到財務總監(jiān),然后總監(jiān)再找到對應角色去詢問使用意見,設計再進行修改,然后再拿給財務總監(jiān)確認。反復修改,設計成本高。

方法:業(yè)務不等于用戶,有條件的情況下可以直接接觸用戶了解真實場景,沒有條件的情況下可以通過業(yè)務代問用戶拿到二手資料,大框架一定要提前制定,細節(jié)可以逐步完善。

應用:首先梳理工作臺的角色有哪一些,綜合考量角色的共性以及差異進行工作臺草圖繪制,然后拿著草圖找到對應的角色去咨詢意見并針對遇到的問題適當詢問用戶解決方案并修改,再找業(yè)務確認。

結論:如果產(chǎn)品或者需求方不清楚要什么的情況下,一定要找到真實用戶詢問場景和探討解決方案。

五、簡單視覺優(yōu)化就可以

背景:產(chǎn)品經(jīng)理因為上線時間緊,提前按照原型上線了看板內容,然后才截圖發(fā)給設計師說就簡單做下視覺優(yōu)化。

問題:視覺優(yōu)化只是好看就行嗎?

方法:任何產(chǎn)品需求都建立在用戶需求之上,設計要有理有據(jù),不要脫離場景做設計。

結論:看板的需求其實和我們做其他需求一樣,需要先了解背景,跟隨業(yè)務目標進行信息的整理和布局,最后再做美化。如果你真的只是在現(xiàn)有界面基礎上進行美化不考慮業(yè)務場景、交互邏輯,那么很有可能產(chǎn)出中看不中用的產(chǎn)品。

六、簡單做,不考慮擴展性

背景:在一個項目中,功能會分期迭代,但是有的產(chǎn)品經(jīng)理不管后續(xù)功能的擴展性,只考慮當前版本能夠上線。

問題:后續(xù)功能上線后和前面的沖突,導致全部重新設計。新功能可能由于數(shù)據(jù)原因、流程原因、定位原因等,會導致頁面的布局交互重新設計,重新開發(fā),增加了人力成本。并且在時間緊急情況下,可能有的產(chǎn)品經(jīng)理會選擇不重構,錯上加錯,僅僅為了滿足功能,忽視了體驗。

方法:在接到需求設計時,我們應該充分考慮各種場景和產(chǎn)品后期規(guī)劃,盡量保證產(chǎn)品擴展性,減少重新開發(fā)。

結論:不考慮拓展性很可能導致返工重新設計或者體驗大打折扣,務必提前了解清楚規(guī)劃,盡量避免。

本文由 @(*≧▽≦) 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉載。

題圖來自 Unsplash,基于CC0協(xié)議。

該文觀點僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 有趣的方向 和討論 對于B端產(chǎn)品來講 第一點 簡直太高頻了

    來自北京 回復
  2. 產(chǎn)品經(jīng)理“六宗罪”?

    來自江蘇 回復
    1. 哈哈哈哈 尷尬尷尬 絕無此意 人孰無過

      來自上海 回復
专题
12849人已学习14篇文章
良好的交互规范可以很好的帮助企业、团队提高产出,保证用户体验。本专题的文章分享了交互规范指南。
专题
13331人已学习12篇文章
需求管理,也是产品运营人工作中非常重要的一个任务。本专题的文章分享了如何做需求管理。
专题
12577人已学习12篇文章
所谓SOP,即标准作业程序,指将某一事件的标准操作步骤和要求以统一的格式描述出来,用于指导和规范日常的工作。本专题的文章分享了SOP创作指南。
专题
133275人已学习23篇文章
产品经理,除了会写竞品分析,还要会写产品分析。
专题
18148人已学习15篇文章
语音交互是基于语音输入的新一代交互模式,通过说话就可以得到反馈结果。本专题的文章分享了语音交互的入门指南。