可以叫我才哥 - 關於數據分析類產品設計迭代的小案例－鑽石舞台

大家好，我是才哥。

今天和大家分享一個朋友在做數據分析類產品的設計迭代優化需求時的小故事。

沒錯，這就是俺！

在一些比較大的版本更新中，有時會對某個模塊進行較大的功能翻新或者Redesign。這種複雜的需求通常會牽扯到很多不同頁面和模塊，導致整個邏輯不止複雜，而且會伴生更多細枝末節處的設計問題。

這些細枝末節的設計在整個模塊的討論中並不會被深究，更多的情況是通過後續的走查或者是在設計的過程中被挖掘出來。這也意味着設計師不一定有充足的時間來妥善的處理這些問題，產出的質量也會被影響，甚至打亂項目的整體節奏。

那麼如何快速地對這些細節進行設計上的迭代，並在團隊內部達成共識，就是這次主要討論的問題。

記得那天剛完成了一個比較複雜的需求，打算把終稿的方案和團隊設計師傅們過一下，就開始愉快的摸🐟的一天。就在這個時候某位設計師傅說了一句：

我當時就這個心情

不過慶幸的是，最後的問題只聚焦在「一個button放在哪裡」的問題上。在TA的設計規範中，取消按鈕永遠在最左邊，但是一個這麼長的按鈕放在取消和確定中間明顯不合適，意味着這裡的交互方式要做出妥協和讓步。

既然問題已經提出，這個頁面也馬上要移交前端進入開發，就需要儘快修復。然後就開始了關於這個問題的頭腦風暴，於是設計師傅們開始各顯神通...

有找交互案例的

有當場擼設計稿的

還有在設計群里口頭設（bi）計（bi）的

場面一度非常精彩，短短10分鐘內大家就發散出了一堆方案。

大體上分為兩種方案，第一種主張把信息分層，把主要的確定，取消，取消日期對比三個功能放在第一層，和當前的日期一起展示，把用來切換時間的日曆部分進行收納。

這樣做的優點：信息的層級更加明確，用戶在每個界面的體驗都能更加聚焦，不會被大量的信息干擾。但是在調研過程中我們發現，用戶修改日期的頻率遠大於取消對比日期，這個方案的缺點在於收納了更高頻的操作，反而增加了操作成本。

於是第二種方案應運而生，層級上不做改變，但是要讓按鈕處在一個符合規則同時方便用戶使用的地方。關於如何決定最後的結果，也在這次討論中開闢出了新的方向。

通過統一的模版展示每個設計師傅想法的關鍵部分，展現在同一個稿子裡進行投票。因為第一次的討論已經臨近下班，這個部分放在了第二天才進行。最後大家選擇了第一種方案，用一種更清晰的信息層級，計劃排入下一期的優化里開發。我也能夠繼續愉快的摸🐟生活。

我覺得在這次的經歷中，值得繼續討論的有兩點。

首先，這一整套流程在我看來更像一個緊急機制，在發現了一些設計細節上的疏漏，同時不再有足夠的時間來走完整的設計評審流程，就可以採用這種機制。通過集思廣益能夠快速地找出新的方向破局，之後利用投票機制也能更快的做出決策。存在完整周密的設計評審流程的同時輔以一些靈活機動的評審，能讓設計師在應對這些細節的設計的時候不會因為時間不夠而忽視，也不會拖慢產品更新的節奏。