在需求成立的前提下,如何識別結構層的偽需求?
結構層主要包含交互設計和信息架構設計,要充分理解用戶的心智模型,才能設計出對用戶友好的系統。那么,如何識別結構層的偽需求呢?本文通過實際案例進行了分析,一起來看一下吧。
產品角度的偽需求是指沒有價值的需求、不符合用戶需要的假需求,產品和設計師通常會憑借經驗或調研來辨別需求,剔除那些不符合用戶需要或沒有商業價值的需求。本篇文章我們不談產品角度的偽需求,會基于需求成立的前提下,以一個更貼合設計師日常工作的角度去介紹怎么處理設計師在結構層遇到的偽需求。
結構層主要包含交互設計(怎么通過系統操作更好的完成任務或目標)、信息架構設計(怎么將信息有效傳達給用戶)。對于結構層的設計,需要做到充分理解用戶的心智模型,從而設計出對用戶友好的系統。友好的系統不是簡單滿足用戶需要,而是以最有效的方式滿足用戶需要之外,還給到用戶情感上的滿足。
一、什么是結構層的偽需求?
怎么理解結構層的偽需求呢?我們通過案例來了解下。
案例1
場景:用戶每天會在以下界面打卡,有固定打卡時間。
產品需求:為了后臺更有效地統計考勤數據,在非打卡的時間段內用戶不可以打卡;同時為了避免用戶在非打卡時間打開該界面,因長時間停留未刷新導致到了打卡時間仍然顯示不能打卡,所以需要一個刷新的功能。
這個需求看起來是不是很合理?有明確的業務場景,交互方式符合用戶認知,視覺設計簡單(加一個icon)。新手設計師遇到這種情況可能就直接開始設計,快速交付了。但是其實更合適的解決方式是:在可以打卡的時候后臺自動刷新界面,變更打卡按鈕狀態為可點擊。這樣才是從根源解決用戶的問題,避免造成困惑和不滿。
案例2
場景:用戶通過以下頁面查看不同庫位車輛排隊情況,排隊共5種狀態,可切換tab可查看不同狀態下的車輛總計和明細。
業務需求:用戶比較關注園外排隊情況,目前只能通過點擊tab來切換查看不同庫位園外排隊中這個狀態的數據,覺得比較麻煩,想在tab上加上園外排隊中的車輛數,如下圖:
業務的需求痛點是存在且合理的,但是這個解決方式明顯是不可取的。通常在【tab+數字】這個形式用戶會認為是該tab下的所有數據的總和,而不是該tab下某一類數據的和。
若按照業務要求實現了,會造成更多用戶的困擾。用戶的痛點的關鍵是“點擊查看麻煩”,那怎么讓用戶能夠快速、方便地查看,有效地幫用戶解決問題。最終方案是:增加了左右滑動頁面切換tab的手勢。
案例3
場景:用戶需要新建工單,并且支持查看工單明細和時間維度的數據統計情況。
原信息結構缺點:信息分類凌亂,不符合場景實際需要。新建和查看是獨立的場景,卻被冗雜在了一起。新建工單頁面用戶的目的是簡單快捷地創建工單,而不會新建過程去查看工單數據統計情況;
另外用戶想要查看數據統計時,就頁面結構來看,沒有告知的情況不會認為在新建工單里,因此查看數據統計的信息設計是失敗的,甚至可以說反人類的。
如上圖所示,將查看數據統計放到了列表頁,可直觀查看數據和明細,整個信息層次更清晰,且減少了查看詳情的跳轉步驟,明細更合理,提高了查看的效率。
二、怎么識別結構層的偽需求
從以上三個案例我們可以得知,產品或業務有時候傳達的需求可能只是他個人的方案,那這個需求就是不成立的,直接推翻嗎?不是的!作為設計師我們需要有能力去挖掘用戶本質需求,判斷方案的可行性。
那怎么判斷需求真偽?我們可以圍繞系統可用性、可閱讀能力兩方面,在對接需求的過程中進行初步分析。
1)有效性
指用戶完成特定任務或者達到特定目標所具有的正確和完整程度。是否有效可以通過“5WHY”分析方法得到答案。拿到一個需求的時候,我們通過不斷地問為什么要這樣做,直到剝離表象,理解用戶真實訴求。
然后再拋開需求內容,從用戶的需要出發,分析產品給到的方案是不是能夠解決用戶痛點。
5WHY分析法,是指對一個問題連續多次追問為什么,直到找出問題的根本原因。
舉個例子:針對以上案例一的問題,我們可以做以下提問:
- 為什么要加刷新————因為怕用戶感知不到打卡按鈕狀態變化
- 為什么會感知不到————因為加了一個時間限制,非打卡時間不可打卡
- 為什么要限制————因為方便后臺數據統計……
- 為什么不使用無感知自動刷新,可以直接避免用戶困擾————因為擔心開發不能做
- 講解開發實現方式,讓產品確認……
1-3題其實已經確認了需求目的是有效且合理的,也就是說這是一個真需求;4-5題是對產品給到的方案的追問與確認。
溫馨提示:需求對接過程中,不要直接否定產品的方案,因為產品和設計視角不一樣,可能會有基于產品角度的考量,我們可以先為什么,再提出疑問,給出解決方案一起探討。
2)效率
指用戶完成任務所消耗的時間或其他資源的占比。完成任務的途徑與方式通常不止一種,在眾多的方案里,選擇成本最小且最易操作的方案是至關重要的。
成本可以根據用戶完成任務所消耗的時間成本和該方案實現的開發成本兩方面綜合衡量。我們可以通過產品需求給到的方案是否能夠輕松閱讀、簡單操作去判斷用戶所耗費的成本大小,怎么算輕松閱讀,簡單操作呢?其實有很多現有的判斷標準,例如:尼爾森十大法則、格式塔原理、席客定律、費茨定律……這里就不展開說明了。
開發成本判斷是比較難的,懂代碼的設計師也比較少,我們可以不懂,但是不可以不具備開發思維。系統的復雜是守恒的,用戶操作越簡單則開發實現就越復雜,用戶操作越復雜則開發實現越簡單。
因此想要在這兩者之間進行合理判斷與抉擇,需要設計師有豐富的項目經驗,知道一些簡單的交互開發與實現原理,如果沒有經驗,可以大膽地詢問開發的小伙伴,合理地說服,慢慢形成開發思維。
3)用戶滿意度
指用戶完成任務過程中主觀上感受到的滿意和接受程度,是使用系統可感知效果與其期望值比較的程度。
能夠輕松閱讀和簡單操作是滿意度來源的根本,除此之外情感化的設計、適時的系統反饋與幫助、好的視覺體驗等等,都是提高用戶滿意度的關鍵。用戶的滿意度比較主觀,需要我們用同理心去感知用戶情緒,以用戶視角洞察設計機會點進行有溫度的設計。
4)閱讀能力
包含易讀性、可讀性、可理解性。易讀性指是否能夠讓用戶輕易的看見、區分界面中所顯示的文字,主要考驗的是設計師的文字排版能力,只要掌握好親密、對齊、對比、重復四大原則,基本沒有問題;
可讀性是指文字或句子構造的復雜程度,通常簡短的句子比長句更易讀,要學會提煉文字和合理分段;可理解性是指文字是否容易理解,界面中盡量使用用戶熟悉的語言進行表述有助于用戶快速理解。
以上就是對接需求過程中,判斷和處理結構層遇到問題的一些方法,歡迎一起探討和補充!
本文由 @?? 原創發布于人人都是產品經理,未經許可,禁止轉載。
題圖來自 Unsplash,基于CC0協議。
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
案例2中“增加了左右滑動頁面切換tab的手勢”,不還是看不到排隊的數字么?用戶肯定想知道自己前面有多少人,數字是最直觀。這個案例是否再講細點?
我的tab下有不同狀態數據總計,由于涉及隱私信息被我隱掉了,所以滑動是可以看到排隊數字的。具體場景具體分析,如果下面沒有合計數據,(數據不會特別大的情況)用戶想看總計也是可以在tab上加的