作為一名新晉的交互設計師,面對大大小小的需求時,該如何處理? (PS:不處理掉這些需求,老闆就會處理掉你)而將得到的需求變成你設計稿中的結構框架是每位交互設計師必備的能力之一。 此文就通過筆者參照國內知名APP和自身工作實例將如何需求落地進行簡略說明,方便新手交互設計師閱讀參考。
一、需求分類
我們首先對所接收到的需求進行分類處理,這塊工作一定要和產品經理溝通清楚和反复確認。 而我總結的需求大概有四類
- 延展需求
- 外接需求
- 創新需求
- 偽需求
1.1 延展需求
延展需求是平時工作中遇到最多的需求。
它最主要的體現是在一款產品的架構下進行迭代或者增加的功能設計等,此類需求重點在於它們是已有產品功能的延續和發展,例如:網易新聞APP需要增加一個新的新聞板塊 ,美團APP增加一個租房的板塊等等。
處理此類需求的要素在於遵循已有產品的設計規範和準則,所有的設計必須嚴格按照產品框架來進行。 此時,處理此類需求時,保持設計上一致性尤其重要。
1.2 外接需求
外接需求在日常工作中也比較常見,一般此類需求存在於大的平台級或者工具類產品中,最顯著的特徵是常以H5頁面鑲嵌進產品中(PS:並不是所有都是H5頁面) 。
例如支付寶APP接入社保查詢功能,釘釘APP工作板塊的各項新添加應用。 外接需求既整合於產品之中又游離於產品之外,它需要已有產品的框架為支撐,但在具體內容的設計上又不必以已有產品的規範約束。
1.3.創新需求
創新需求是指完全脫離公司已有產品,而需要實現的全新功能(PS:並不代表市場上沒有相同的競品)。 處理此類一般是由0到1的一個過程,可以不必局限於公司已有產品的規範,在不違背交互原則下的大膽創新是處理此類需求的重點。
1.4 偽需求
偽需求是指表面上看似很有市場潛力,但經不起推敲驗證的需求。 比較經典的偽需求案例就是“賓館改裝成自習室”,建議有興趣的同學可以去搜搜看。
偽需求一般來源於:老闆腦門一熱/客戶說啥就啥/用戶反饋建議,前兩個不用說,為什麼用戶反饋建議也經常是偽需求? 因為所說非所做,用戶嘴上說的永遠不能完全代表心裡想的。
所以在工作中,如果遇到這三個來源的需求,請各位同學一定要多加思考分析,避免做出力不討好的事。
二、清楚用戶訴求
在對需求分類完成之後,接下來就應該從用戶的角度對需求進行分析。
分析的方式可以是我們給自己提出的這一系列問題:我們所做的設計是為哪些人群而做的? 為他們解決了什麼樣的需求? 他們一般在什麼樣的場景中會有這樣的需求? 我們的設計最終要達到一個什麼目標? (PS:是為了吸引新手用戶還是穩定住現有用戶或者是為了提升專家用戶的體驗)
如果我們能把上述問題思考清楚,也就明確了用戶的需求,進而給我們設計明確了方向。 在設計的過程中也會不斷的提醒自己用戶的需求,防止出現設計的偏差。
三、需求分級
清楚了用戶訴求後,接下來就是需求分級的工作,這項工作大部分產品經理可能已經在產品文檔中完成了,但當你遇到一個不靠譜的產品經理或者產品經理並沒有在產品文檔 中完成的時候,你就要來輔助他完成。 所以進行這一步的時候,你必須和產品經理一起討論商量,不能完全的越俎代庖,以免撕逼。
對需求進行分級最重要的依據主要有:
- 產品的核心功能(是否符合產品的DNA);
- 公司的研運實力(研發實力和運營能力的綜合考量);
- 產品的形態等級(現階段產品的發展狀態),如果大家是剛入門的小白設計師可以多參照同類競品,多與產品經理溝通。
四、需求落地
當上述的這些工作完成後,就可以根據需求等級開始具體的信息組織構架和主要流程梳理了。 在這裡,我們之前處理過的需求就會變為信息構架圖中的一個個分支點,也變成各項流程圖中的一個個功能點。
在這裡需要說明的是,做產品流程圖的時候一定要根據需求等級先梳理好主流程,再根據主流程的各個節點來確定分支流程,同時將每個需求處理成不同的功能點,對應流程 圖框架進行羅列。
如上圖,是之前分析一款同事圈競品而繪製的,該產品主要的需求就是為企業內部同事提供一個發布工作狀態的社交平台,類似於微信朋友圈,但使用人群局限於企業內部員工。
我們可以看到,圖片最上面的一行就是產品的主要流程,而主流程的第二個節點“輸入文字 插入圖片”又是主流程中最關鍵的節點。 在此我們又把該節點的分支流程梳理出來,以及每個分支流程上的節點上具有的功能點也同事羅列出來,並且根據重要程度分級,也就是上圖中右下部分展現出來的內容。
而梳理後,這些流程節點和各項功能點都會變成我們設計稿中的一部分,如下圖:
五、交互細節
細節決定成敗。 接下來就是在設計過程中進行各模塊各頁面的細節設計了,這裡就不詳述了。
六、總結
以上所述就是我總結的需求落地過程中的一些經驗和體會,希望對大家有用,以後會繼續更新關於交互設計知識的文章希望大家多多關注!
本文由 @李小先生 原創發佈於人人都是產品經理。 未經許可,禁止轉載。
題圖來自unsplash,基於CC0協議