2020年第一篇，轉換一下寫作思路，就寫點最近真實項目中覆盤的經驗吧，考慮不周全的地方和寫的不對的地方大家儘管提出來哈，一起研究！2020年Flag先立一下，不得不說的一個事實是，單純的視覺UI設計師真的已經不能滿足現在的市場需求了，事實就是你要懂產品，會運營，會交互，會插畫，到你這Part反饋出來的問題還得有深度，代碼啥的只要跟技術小哥哥無縫配合好就行，具體看自己的職業規劃哈，這也不一定。現在的UI設計師真的是要把自己打造成滅霸級別的全棧設計師才能出去打怪升級，太不容易了~來，一起品一下。
01
—
數字多怎麼辦
不論大小APP，數據都無處不在，它可能存在列表中、詳情頁、調研測試頁等等~哪哪都有~，不同頁面不用層級我們處理的手法也不一樣，分類治理~。
尤其是B端類和金融類的產品，數據相對來講比較多，且數據之間有種種複雜的聯繫和嵌套關係。我們要做的並不只是把數據按照原形規規矩矩展示出來，我們要做的是 從拿到的原形中挖掘數據之間的聯繫和產品想表達的想法，並從結合產品本身的利益點出發，去思考、去闡釋這個關係，然後輸出到畫面當中。
我們公司是B端類的業務，基本每個頁面都會時不時蹦躂出來一串數字，一串算法，一串電話號碼~，這就得跟我們的上游產品確認想法了，目前這塊設計圖出來跟我們產品的思路還都挺吻合的。還有字段長短的保留問題，Float轉字符串，以及一個Int和一個Float的關係，這部分內容有點多到時候單獨列出來一篇說吧，有興趣的小夥伴記得關注下哈~接下來說一說乾貨。
02
—
這樣的原型圖你應該怎麼設計
當你拿到上游產品如下的設計圖，梳理完流程大致一看基本沒錯，可以進行下去。這時候你照著這樣做的話，無疑暴露了一個初級錯誤，到時候開發出來，用戶體驗極其不好，這是誰的GUO ？今天就兩張原型圖牽扯這一系列的設計和交互問題吧！
大家也可以想一下拿到這樣的圖你會怎麼做哈，歡迎留言討論。
這也是分水嶺，如果只捋順流程和邏輯，只停留在視覺表面層次的話，顯然應對B端的業務就會出點紕漏（我也是這麼漏過來的）。B端行業錯綜複雜的業務線真的是令人頭禿~，產品給你的原型圖不可能面面俱到，如果公司有交互設計師還好。總之你最後交給產品的設計圖裡，不僅要有設計，還有有交互，還要有邏輯，還要有營銷手段和利益點的爭取，總之一鍋亂燉營養全面，這樣你過稿的幾率還是蠻大的，起碼能說出來幾條別人沒想到的問題；這在個重視交互的年代，清一水的純視覺設計已經有些難了，這也不一定，有些C端的業務，就是要炫，我上面闡述的主要僅針對B端來說哈。
下面分析一下問題，這個頁面算是比較常見的。產品跟我們看問題的視角是不一樣的，我們要為用戶著想，交互做的順暢了、方便了才真正能解決到用戶的問題，讓用戶意識到在線上做操作就是很方便，他們才會慢慢產生黏性。舉一個例子吧，我們公司剛開始上架的業務就是把線下的操作流程搬到線上來，線下都是手寫填單、蓋章，審核速度慢，效率不高等等，但是我們的用戶群體已經習慣了這樣的操作，突然要改到線上來，其實他們是很牴觸的，改變一個人的習慣很難，一群人更難，我們是怎麼做的？當然我們的產品也是很給力的，我們設計師能做的就是不斷的優化用戶體驗，讓用戶感到方便，方便、高效說三遍!接下來說點設計吧！（因為我們公司APP只針對企業頁面開放，頁面暫時不做公開哈，但是我會給大家描述清楚噠，無圖勝有圖系列~）
先看第一張原型圖，就設計問題來講：
- 界面的設計其實沒有可發揮的餘地，只能加一些icon和卡片設計劃分一下板塊；
- 背景色和模塊顏色的區分，tab 欄和 button 的設計，可發揮空間其實很小。
交互問題：
- 這些內容如果都放在一張頁面，用戶要滑動多少屏才能填完內容？
- 信息是否能用OCR智能識別，幫助用戶減少填寫操作 ？
- 姓名手機號這些如果不是熟人應該很難記得吧，是否能添加通訊錄的功能？
- 發件信息是否能用定位功能？
- 收發信息是否需要儲備常用地址？
- 收發信息是用戶經常容易顛倒寫錯的信息，能否區別設計？
- 期望提貨時間是否要設置默認時間？
- 發件信息這塊是否需要默認展示註冊時候本人的信息？
- 最重要的來了，填寫完信息，當前頁面還在可編輯的頁面，滾動信息檢查的時候是否會誤操作，這樣是否增加了用戶煩惱和操作難度？（編輯和預覽界面一定要區分開）
- 二次編輯的時候，打開頁面重新填寫某一項，查找信息的時候是否又增加了用戶的工作量？
- 物品信息是可以操作增加和刪除的，這樣不可預測的操作怎麼把控？
- 添加貨物如果新開一頁其實又重複了之前的問題，新開一個界面，如何實現編輯、刪除和新增？
- 底部按鈕是否需要做成響應式的，當用戶填寫完所有的內容再高亮？
這些問題可能不是所有的都可以被實現，但是作為設計師，這些潛在的問題我們都要看到，及時止損， 以及反饋給我們的上游。
再來看第二張原型圖，
這張圖的問題相對比較少，當你們的APP還沒有涉及很多板塊， 嵌套多個應用的時候，這種嵌套式的應用最好不要使用，況且還得要考慮下你們用戶群體的接受度。這個頁面還處在三四級，這樣的做法會讓用戶感覺到又跳轉到了一個APP的感覺，從一二級操作過來，到這步因為多級Tab突然換了個風格跳躍度還蠻大的。 我們最後的解決方案是：換成tab+標籤 展示在頂部。
03
—
解決方案
其實看到這裡大家心裡應該都有答案了，能看到問題就可以被解決，下面給出我的解決方案。當然我的也不是最優的哈，大家可以當做參考，落地項目牽扯因素太多了，不是設計師一個就能定的，最後解決不下來的問題，只採取了適中的解決辦法。
問題答案不放在一起就是為了給大家一個思考的空間哈，說不定你有更好的問題和方案，嘻嘻~。像一些基礎的問題，通訊錄的添加或者定位什麼的，這些你反饋給上游是一定會給增加的，下面看一個比較核心的解決方案，（為了大家有自己的想法，文末再展示我們最後確定的方案哈，大家有更好的方案歡迎補充
）。
第一個問題：長頁面精簡，編輯預覽分開
一個很長的編輯頁面，涉及多維度的信息，那麼，從編輯到預覽，這個操作一定要區分開來的。尤其的信息比較多的頁面，還可能會涉及大概率信息會被填寫顛倒的可能，比如“收發信息”，就得十分注意。
還有一個比較重要的點需要考慮，二次編輯。用戶修改信息是肯定的，所以，再次修改信息時一定要做到明確、快速定位信息。
給大家舉個例子，我們本來第一期的想法是當用戶進入收貨信息的時候，填寫完成全部的信息後，響應式按鈕高亮，但是按鈕文案改成“下一步”，點擊之後讓用戶直接進入收貨界面填寫。這個方案看似是幫用戶節省了時間，不用返回再點擊收貨再進入填寫，但是還是漏洞百出。
問題：1.用戶要是二次編輯呢？是否需要再重新全部走一遍流程？一步一步點下一步？系統是否可以直接識別，直接按鈕變為“完成”？這其實是給我們技術增加了難度，但是考慮到目前的情況和該頁面的重要程度還是捨棄了。
2.加上 上一步、下一步和提示性文案呢？還是被駁回了，用戶二次編輯只是想修改一下信息，我們卻在這裡給用戶增加了難度，需要用戶再考慮上一步、下一步等等之類的邏輯，相比之下，用戶是寧願多點一下也不願意思考其中的邏輯。
第二個問題：問題升級，繼續設防
到了“東西”這塊，進入下一級頁面，本想著按照原型圖邏輯直接讓用戶編輯就可，（如圖方案一），但是B端就是層層邏輯的嵌套，不妨不行啊~ 如果增加少還行，但是要有二三十條的增加量，還必須保留一條數據，這就……，而且還得可刪除可增加，技術在實現的時候怎樣的完成度算一條可用的數據？掉頭髮掉頭髮~~說一下我們想出來的方案和被PASS掉的方案。
1.第二個給出的方案是這樣的，（如圖方案二），我們在頂部增加編輯框，相當於編輯添加的信息在上，完成的信息在下，做了很好的區分~，按鈕做成響應式的，用戶沒有填寫完成就不給高亮，這樣就保證了至少有一條數據，這樣子應該沒什麼問題了吧！
看上去沒什麼問題了，但是問題來了，往下推敲就發現問題來了，這樣的操作是可以用的，但不是最好，還是存在歧義的。這就涉及一個技術的問題，“什麼情況下算是一條可用的數據？上面的輸入框輸入了一半的數據，算一條數據嗎？”我們的答案是不算！必須點“完成”才算一條完整的數據，點擊完成之後上面的輸入框內容清空。“下面已經輸入完成的信息如何排序呢？”新增加的在最頂部。“添加貨物”的按鈕意義何在？和頂部固定的編輯框是否會誤導用戶？用戶的年齡層是否有考慮？到這步還是妥協了，換方案！這樣的操作可以用，但是對用戶來講是有一定的學習成本，進入頁面用戶還是會有點蒙，點擊“添加貨物”，我們頂多能反饋個吐司提示，頁面基本無變化，對不敏感的用戶來講根本看不出來哪裡不一樣，所以此方案能用但還不是最全面的最好用的！
最後衍生到如下方案，點擊“添加貨物”直接就Action sheet,再也不用擔心編輯一半想退出了怎麼辦，怎樣的數據算一條完整的數據。底部彈窗的操作也給用戶很明顯的反饋，不想要就取消。
下圖是部分拆解的步驟，大家有更好的方案歡迎留言。
上述修改的方案操作也是很常見的，也是平時操作中我們經常使用而且無學習成本的，但是從一張原型圖拆解到一系列的層層方案還是得費工夫去研究的，有挑戰性的東西無疑也是最鍛鍊我們設計師的！項目落地要牽扯到很多因素，所以最後方案也不是最完美的，也有待優化，重要的是我們能意識到存在的潛在問題，並且及時止損。
近半年來加入了一些很有意義的交互群和設計群，對自己幫助很大，感恩優秀的同行者~
end
閱讀更多 PMTalk產品經理社區 的文章
