中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

本文從產品設計的兩種極端現象出發，探討了“請求原諒，而不是請求許可”的設計理念，即在設計中大膽地為用戶提供預設的解決方案，而不是讓用戶在每一步都進行繁瑣的確認。

PART1 產品設計碰到過的兩種極端

說到產品設計（這里甚至可以適當泛化，交互設計、硬件設計、多媒體設計等），很多人容易走向兩個極端，“有（不）幸（料）”在產品設計的經歷中我都見到過：

第一種，用戶都是小白，得聽我們的！

“他們根本不知道自己想要什么，他們不會知道怎么做，他們很容易犯錯。”

這是很多設計者一廂情愿的擔心。這種情況的假設前提是，設計者自認為深諳背后的地圖全貌，站在上帝視角俯瞰用戶，自然會覺得用戶的思考淺顯而無知。設計者就像大包大攬的父母一般，制定好成長、前進的路徑，約束好各種邊界和規則，不允許任何的違逆和回旋。

用戶在這種環境的活動受到嚴格的限制，沒有絲毫的自由空間和創造性，甚至于既定的規則和路徑并不與用戶所處的使用場景事實相符合。

第二種，必須要讓用戶自己做決定，產品不能承擔任何后果！

“出了問題怎么辦？不能說是產品/系統導致的吧！必須要讓用戶自己一步一步明確的確認和操作。”

這是另外一種極端情形。作為設計者，從一開始就想要剝離所有的糾紛和瓜葛，所有的確認、授權、提示，都要求用戶明確并給出操作才能繼續，這樣一來，就像是保險須知的條款，非常完備，除了問題，那是用戶自己的責任啊。

用戶在上面這種環境中，如同原始社會，已經失去了任何的工具支撐，想要喝水，系統會問你是不是想要水？是河水、湖水、海水？怎么取水，自己還是他人？用什么取水，手捧、葫蘆？只怕一連串的確認操作之后，用戶也快渴死了，至少也被煩死了。

PART2 產品設計理應如何思考呢？

《交互設計精髓4》一書中有一段話，我想可以用來呼應上述part1的現象。

“大部分的時間里面，我們應該做很可能是正確的事情，而不是每次嘗試都必須做好充分的判斷。軟件只應該做很可能是正確的事情，然后為用戶提供強大的工具來調整第一次的嘗試，而不是給張白紙，挑戰用戶。這樣一來，應用程序不用請求權限去采取行動，而是做了之后再請求諒解。

對大多數人來說，從空白開始很困難，而在別人做好的基礎上開始則會更簡單。用戶能夠輕易微調程序提供的近似值，以精確達到自己的要求?！?/p>

PART3 現實世界里的花花綠綠

大包大攬的家長式設計（第一種設計）現在可能并不多見了，畢竟市場會教育他們，用戶也會用腳投票，嚴格制式的系統邏輯怎么可能面對發展的業務和各式各樣的團隊。

但如果是面對b端/g端用戶，卑微的乙方或者沒有話語權的自研團隊可能更容易出現的是第二種情形，設計者想盡辦法的規避軟件/系統的責任，一切的操作需要用戶的許可、授權、選擇、確認，最終的結果會是：無盡的提示彈窗+二次確認彈窗+無盡的“我知道了”、“確認”、“下一步”、“提交”。

如此的設計雖然說很好的規避了產品的責任，把一切都推給了用戶，同時也盡可能保證了產品/系統邏輯的清晰明了、簡化，也不需要額外復雜的兜底邏輯。但b端、g端產品更注重的生產力和效率，這里你說是不是完全相背了呢？

PART4?多做一點點，改變世界

所有的許可都拋給用戶，只能說是產品設計的懶惰造成的（這個鍋多半得產品經理自己來背），不夠深刻理解用戶/業務場景，對任務流程把握不準確，這樣的設計拿出來根本不是一把利斧（工具），而是“原石”（白紙）一堆。

用戶打開一個信息頁面，數據刷新都不做，這是不是偷懶呢？即便用戶不需要，但是我們也應該在做一些基本的預設：

1、打開頁面時進行數據查詢刷新
2、用戶點擊已閱讀、知道了之后，就應該自動執行下一步操作，而不是再讓用戶點下一步
3、提交數據之后，就應該自動返回信息列表或者詳情預覽，并展示最新數據

產品/系統應該做到的遠不止上面這些，更多的應該在業務場景、用戶場景、流程協作中體現出來。

最近偶然翻看到一篇工作筆記（正是基于產品設計視角大膽的做可能正確的事情），是2021年剛到上個團隊時，做的2個迭代版本，功能不大，它們都是干的同一件事情：“信息結構優化”，這當然屬于是提供給用戶一定的功能分類基礎，而不是讓用戶像白紙一樣在系統里自己去盲目探索。

信息結構是呈現給用戶的支撐性框架，信息結構構建了用戶的大腦導航地圖。當時接手的產品基本也到了近2.0的階段，可是在對于業務貼合的信息結構構建上做的很不足。我猜當時大概率有幾種可能：

1. 當時團隊的普遍能力模型，在信息結構上是有待提升的
2. 調研草草沒有深入到用戶的場景里面去

用戶一定沒有錯，如果有問題一定是設計者需要反思的！

導航的視角不只是當一個用戶，對于B端產品來說（很多企業級應用產品），用戶其實是協作網絡上的不同角色。我們有不同角色的用戶，他們可能互相獨立、也可能互為依賴，而對于一條主業務流程上的串聯用戶的來說，信息結構不只是對于當前用戶的事情，也要考慮信息隨著主流程在用戶鏈條上的傳遞。

類似此類的識別、判斷，我們大可大膽的讓系統去先做了，然后提供一些兜底、容錯、撤銷、撤回機制給到用戶用于修正不符合事實的操作。“請求原諒，而不是請求許可”，更像是一種設計思想，需要設計者能夠深刻共情用戶與場景。