結構層主要包含交互設計和信息架構設計，要充分理解用戶的心智模型，才能設計出對用戶友好的系統。那麼，如何識别結構層的僞需求呢？本文通過實際案例進行了分析，一起來看一下吧。

産品角度的僞需求是指沒有價值的需求、不符合用戶需要的假需求，産品和設計師通常會憑借經驗或調研來辨别需求，剔除那些不符合用戶需要或沒有商業價值的需求。本篇文章我們不談産品角度的僞需求，會基于需求成立的前提下，以一個更貼合設計師日常工作的角度去介紹怎麼處理設計師在結構層遇到的僞需求。

結構層主要包含交互設計（怎麼通過系統操作更好的完成任務或目标）、信息架構設計（怎麼将信息有效傳達給用戶）。對于結構層的設計，需要做到充分理解用戶的心智模型，從而設計出對用戶友好的系統。友好的系統不是簡單滿足用戶需要，而是以最有效的方式滿足用戶需要之外，還給到用戶情感上的滿足。

一、什麼是結構層的僞需求？

怎麼理解結構層的僞需求呢？我們通過案例來了解下。

案例1

場景：用戶每天會在以下界面打卡，有固定打卡時間。

産品需求：為了後台更有效地統計考勤數據，在非打卡的時間段内用戶不可以打卡；同時為了避免用戶在非打卡時間打開該界面，因長時間停留未刷新導緻到了打卡時間仍然顯示不能打卡，所以需要一個刷新的功能。

這個需求看起來是不是很合理？有明确的業務場景，交互方式符合用戶認知，視覺設計簡單（加一個icon）。新手設計師遇到這種情況可能就直接開始設計，快速交付了。但是其實更合适的解決方式是：在可以打卡的時候後台自動刷新界面，變更打卡按鈕狀态為可點擊。這樣才是從根源解決用戶的問題，避免造成困惑和不滿。

案例2

場景：用戶通過以下頁面查看不同庫位車輛排隊情況，排隊共5種狀态，可切換tab可查看不同狀态下的車輛總計和明細。

業務需求：用戶比較關注園外排隊情況，目前隻能通過點擊tab來切換查看不同庫位園外排隊中這個狀态的數據，覺得比較麻煩，想在tab上加上園外排隊中的車輛數，如下圖：

業務的需求痛點是存在且合理的，但是這個解決方式明顯是不可取的。通常在【tab 數字】這個形式用戶會認為是該tab下的所有數據的總和，而不是該tab下某一類數據的和。

若按照業務要求實現了，會造成更多用戶的困擾。用戶的痛點的關鍵是“點擊查看麻煩”，那怎麼讓用戶能夠快速、方便地查看，有效地幫用戶解決問題。最終方案是：增加了左右滑動頁面切換tab的手勢。

案例3

場景：用戶需要新建工單，并且支持查看工單明細和時間維度的數據統計情況。

原信息結構缺點：信息分類淩亂，不符合場景實際需要。新建和查看是獨立的場景，卻被冗雜在了一起。新建工單頁面用戶的目的是簡單快捷地創建工單，而不會新建過程去查看工單數據統計情況；

另外用戶想要查看數據統計時，就頁面結構來看，沒有告知的情況不會認為在新建工單裡，因此查看數據統計的信息設計是失敗的，甚至可以說反人類的。

如上圖所示，将查看數據統計放到了列表頁，可直觀查看數據和明細，整個信息層次更清晰，且減少了查看詳情的跳轉步驟，明細更合理，提高了查看的效率。

二、怎麼識别結構層的僞需求

從以上三個案例我們可以得知，産品或業務有時候傳達的需求可能隻是他個人的方案，那這個需求就是不成立的，直接推翻嗎？不是的！作為設計師我們需要有能力去挖掘用戶本質需求，判斷方案的可行性。

那怎麼判斷需求真僞？我們可以圍繞系統可用性、可閱讀能力兩方面，在對接需求的過程中進行初步分析。

1）有效性

指用戶完成特定任務或者達到特定目标所具有的正确和完整程度。是否有效可以通過“5WHY”分析方法得到答案。拿到一個需求的時候，我們通過不斷地問為什麼要這樣做，直到剝離表象，理解用戶真實訴求。

然後再抛開需求内容，從用戶的需要出發，分析産品給到的方案是不是能夠解決用戶痛點。

5WHY分析法，是指對一個問題連續多次追問為什麼，直到找出問題的根本原因。

舉個例子：針對以上案例一的問題，我們可以做以下提問：

1. 為什麼要加刷新————因為怕用戶感知不到打卡按鈕狀态變化
2. 為什麼會感知不到————因為加了一個時間限制，非打卡時間不可打卡
3. 為什麼要限制————因為方便後台數據統計……
4. 為什麼不使用無感知自動刷新，可以直接避免用戶困擾————因為擔心開發不能做
5. 講解開發實現方式，讓産品确認……

1-3題其實已經确認了需求目的是有效且合理的，也就是說這是一個真需求；4-5題是對産品給到的方案的追問與确認。

溫馨提示：需求對接過程中，不要直接否定産品的方案，因為産品和設計視角不一樣，可能會有基于産品角度的考量，我們可以先為什麼，再提出疑問，給出解決方案一起探讨。

2）效率

指用戶完成任務所消耗的時間或其他資源的占比。完成任務的途徑與方式通常不止一種，在衆多的方案裡，選擇成本最小且最易操作的方案是至關重要的。

成本可以根據用戶完成任務所消耗的時間成本和該方案實現的開發成本兩方面綜合衡量。我們可以通過産品需求給到的方案是否能夠輕松閱讀、簡單操作去判斷用戶所耗費的成本大小，怎麼算輕松閱讀，簡單操作呢？其實有很多現有的判斷标準，例如：尼爾森十大法則、格式塔原理、席客定律、費茨定律……這裡就不展開說明了。

開發成本判斷是比較難的，懂代碼的設計師也比較少，我們可以不懂，但是不可以不具備開發思維。系統的複雜是守恒的，用戶操作越簡單則開發實現就越複雜，用戶操作越複雜則開發實現越簡單。

因此想要在這兩者之間進行合理判斷與抉擇，需要設計師有豐富的項目經驗，知道一些簡單的交互開發與實現原理，如果沒有經驗，可以大膽地詢問開發的小夥伴，合理地說服，慢慢形成開發思維。

3）用戶滿意度

指用戶完成任務過程中主觀上感受到的滿意和接受程度，是使用系統可感知效果與其期望值比較的程度。

能夠輕松閱讀和簡單操作是滿意度來源的根本，除此之外情感化的設計、适時的系統反饋與幫助、好的視覺體驗等等，都是提高用戶滿意度的關鍵。用戶的滿意度比較主觀，需要我們用同理心去感知用戶情緒，以用戶視角洞察設計機會點進行有溫度的設計。

4）閱讀能力

包含易讀性、可讀性、可理解性。易讀性指是否能夠讓用戶輕易的看見、區分界面中所顯示的文字，主要考驗的是設計師的文字排版能力，隻要掌握好親密、對齊、對比、重複四大原則，基本沒有問題；

可讀性是指文字或句子構造的複雜程度，通常簡短的句子比長句更易讀，要學會提煉文字和合理分段；可理解性是指文字是否容易理解，界面中盡量使用用戶熟悉的語言進行表述有助于用戶快速理解。

以上就是對接需求過程中，判斷和處理結構層遇到問題的一些方法，歡迎一起探讨和補充！

本文由 @