薄荷網設計總監：我是如何設計體重記錄功能的？

有什麼事情是減肥人群的剛需呢？她可以不吃（節食），不運動，但一定會記錄體重。從 薄荷 的數據來看，體重記錄也的確是使用人數最多的工具。

今天我們就來聊聊體重記錄那些事兒。

在設計體重記錄功能的時候，要解決兩大問題：如何輸入數據，如何展示數據。我們先來說說前者。

輸入體重數據的組件有兩種：滾輪和數字鍵盤，哪一種更好呢？我們從三個情況來分析：

p.s. 這裡談的滾輪組件，不僅是系統自帶的豎著的那種，還包括自定義的，橫向滑動的滾輪組件。

滾輪與數字鍵盤

1、初次使用

滾輪：如果用戶的體重和初始值的差距比較大，滑動起來就有點費勁了；

數字鍵盤：在大多數秤都是數字顯示的，從腳下的數字到手上輸入數字，過程是比較自然的；

第一回合，數字鍵盤小勝。

2、以後的使用（除了第一次輸入）

滾輪：體重的波動一般都不大，用戶只需要在上一次體重的基礎上微調就行了，輸入效率高；

數字鍵盤：一般人的體重是不會超過100公斤的，要輸入的是兩位數加一個小數點，得點三下，輸入效率低。

第二回合，滾輪完勝。

3、錯誤信息反饋

滾輪：能出現在滾輪上讓用戶選的數值，都是在合理範圍內的，不需要額外的反饋。

數字鍵盤：對用戶的輸入範圍沒法控制，當用戶輸入了明顯不合理的數值，還得提示，然後讓用戶重新輸入。

第三回合，滾輪完勝。

4、結論

滾輪適用於有一定數值範圍，每次輸入差異不大的情況；數字鍵盤適用於沒有數值範圍，每次輸入沒有關聯的情況。在體重記錄這個場景下，滾輪比數字鍵盤更合適。（具體情況要具體分析，切勿生搬硬套）

2012年，薄荷的添加體重記錄

三四年前，大多數的 App 都是用數字鍵盤的，開發難度低嘛。那時候薄荷用滾輪組件，而且是自定義的組件，那是相當前衛的。很感謝當時的程序員皮皮，花了很大工夫，開發出穩定強大的組件（見上圖，當時還是流行擬物風格的）。現在，自定義的滾輪組件已經成為行業標配了。

5、小心，此處有坑

別笑，這些坑都是我們曾經踩過，或者看到別人踩過的

說完怎麼輸入數據，我們再看來怎麼展示數據。常用的組件有兩種：日曆和曲線。

也許你會想，還有TableView（表格）啊。沒錯，哪一天體重多少，一行行的排列下來，是可以解決問題。只不過，這麼朴（jian）素（lou）的組件，作為一個有理想有追求的設計師，會用嗎？（表哥：我躺槍了……）

表哥（TableView），表難過，我們不嫌棄你，待會還有讓你出場的機會啊。

日曆和曲線，哪種形式能更好的展示用戶的體重數據呢？（即使你不想二選一，想兩個都做，像薄荷就是既有日曆也有曲線，但是主角肯定只有一個，另一個只能充當配角）。幾乎所有減肥類的 App 都選擇了體重曲線（至少我看到的都是這樣），薄荷卻特立獨行的選擇了日曆，為什麼呢？

1、拼顏值

日曆是很難玩出花兒來的。iOS自帶的日曆很難用，自己開發的難度又太大，所以用的都是第三方的開源組件，一旦你和程序員一起挑中了哪個組件，樣式基本就是那樣了，可以設置的參數很少，沒有太多花頭。

曲線的話，你可以用第三方組件，也可以讓程序員自己開發，發揮餘地就大多了：是折線還是貝茲曲線（又稱貝塞爾曲線），曲線上的數據點是空心還是實心，曲線與橫坐標之間的區域是透明的還是漸變的……你有很多種選擇，淺色背景的可以做得乾淨整潔，深色背景的可以做得時尚酷炫。

從美觀的角度上，曲線完勝日曆。

2、談實用

日期與體重，這兩個數據並不是孤立的，單純的一個日期或體重都沒有意義，得兩者對應了，才能組成完整的一對數據。

日曆與曲線

日曆的好處是，日期與體重這兩個數據是緊挨著的，兩者容易對應。（見上圖左）你要查某一天的體重是多少，一目了然。如果你是重度用戶，要看看比上周減了多少，比上個月減了多少，都很容易。

曲線的好處是，容易看出變化的趨勢。缺點是，日期與體重這兩個數據是分離的，被分離成橫坐標和縱坐標，兩者難以對應。（為了保持頁面的簡潔，我們通常只會在最近一個記錄點上註明日期和體重數據，曲線上的其他點就不會註明了。見上圖右）你得自己看橫坐標對應的是哪一天，再看縱坐標對應的體重是多少。所以你要查某一天的體重是多少，是挺麻煩的一件事兒。

另外，在短時間內用戶的體重變化是不大的，不容易看出趨勢來。也就是說，曲線的好處沒有發揮出來，反而有壞處。日曆有好處，沒有明顯的壞處。這麼一對比就可以看出，日曆比曲線實用。

3、結論

如果你的用戶大多是輕度用戶，那就選顏值高的曲線；如果你的用戶大多是重度用戶，那就選經濟實用的日曆。 薄荷為了重度用戶，所以選擇了用日曆。

慢著，MyFitnessPal 應該也是重度用戶多啊，為什麼他會選擇用曲線呢？

MyFitnessPal 的曲線與列表

其實，你看看 MyFitnessPal 的曲線，下面還有列表呢，列表正好彌補了曲線的缺點。（表哥終於有出場機會了）

上面也提到過了，日曆組件可以發揮的餘地很小，這裡就不說了。曲線是個有故事的組件，咱們來好好聊聊。

1、橫坐標：按次數 vs 按自然日期

用戶記錄體重，不像股票和天氣，不一定每天都有數據的。橫坐標雖然都是用來顯示日期，但是有兩種截然不同的日期：

1.1 扯個八卦

有一次電話面試，應聘者也做過體重曲線，那我就問她，這兩者之間的優劣，你是怎麼考慮的。她回答道：「這是產品經理決定的，我不用考慮」。事後，她在朋友圈發牢騷，正好被我一個同事看到了，她抱怨道：「面試官真奇怪，居然拿產品經理的問題來問我。」

這個問題真的只有產品經理才需要關心嗎？作為設計師，只要跟用戶體驗相關的事情，都值得去研究吧。另外，在薄荷，產品經理和設計師的兩個角色的界限不是那麼涇渭分明，我認為這是好事，我們鼓勵人人都當產品經理，鼓勵設計、開發、運營的同事都參與到產品設計中來。

好了，言歸正傳。

1.2 優劣比較

瘦身旅程 和 Same

按次數的好處是：

1、好看，每個點的間隔是均勻的，不會太密或太疏。

2、開發難度較低。

缺點是：不能反映體重變化的真實趨勢。兩個點之間可能相差一天，也可能相差一個月、一年。（見上圖右）

按自然日期的好處是：能真實反映體重變化的趨勢。缺點是：開發難度高。（見上圖左）

1.3 開發難度高？

按自然日期為什麼會開發難度高呢？舉幾個栗子：

栗子一：跨屏幕的連線

曲線上的點與點之間是要連起來的，很簡單是嗎？但是考慮到跨屏幕（翻頁）的時候，情況就變得複雜了。當前屏幕最左邊的那個點，它的前一個點在哪裡呢？先查上一周，沒有。再查上上周，又沒有。再查上上上周……啊，終於找到了，兩個點尋尋覓覓，終於把紅線牽起來啦！（背景音樂：有緣千里來相會~~~）

栗子二：周期的切換（周/月/年）

每個用戶記錄體重的頻率是不一樣的，有人每天記，有人每周記，有人每月才記一兩次，所以你覺得合適的周期，對於別人來說，就會顯得點太密了，或者太疏了，沒法用一個固定的周期來滿足所有人，於是得有個周期的選擇，在周、月、年之間切換。

或者，你可以向更高難度挑戰，用手勢來動態調節：兩根手指向內捏，點就密一些。兩根手指向外捏，點就疏鬆一些。

栗子三：取樣

一個屏幕顯示多少個點比較合適呢？5~7個點看起來是最舒服的。當你用比較大的周期，比如月和年，那一個屏幕里顯示的點可能會非常密（可能會高達365個點），先不說難不難看吧，也不說載入速度慢不慢吧，在性能不好的機器上，可能馬上就崩潰了。

所以需要後端幫你取樣，一年的數據，每個月取個平均值，只返回12個數據。

1.4 結論

看了這三個栗子，你明白了吧？如果是按次數的話，這些問題都不復存在了。很多看上去很美好的事情，並不是那麼簡單的。

按次數，就像一個不太聰明但很細心的學生，最多能考80分，但他會的題就不會丟分，最終考了80分。按自然日期，就像一個很聰明但不細心的學生，全都會，理論上能考100分，但這裡錯一些，那裡錯一些，最終只考了70分。

如果你對開發團隊的能力不是很有信心，或者他們能力雖強，但沒法投入大量精力，持續的改進這個功能，我勸你還是選擇「按次數」的形式吧。（背景音樂：啊，多麼痛的領悟~~~）

2、縱坐標：靜態分布 vs 動態分布

除了橫坐標的這個大坑，跳進去就很難挑出來了，縱坐標也有個小坑。

縱坐標的數據分布有兩種形式：

雪球

說起曲線，技術含量最高的曲線就是股市的k線圖了。股市類App的曲線，在橫向滑動的時候，縱坐標都會動態的改變。

很顯然，當然是動態分布的效果好啦，否則你的體重數據就是在一個很窄的區間里小幅的波動，完全看不出趨勢。

程序員也許會為了快，趕進度，怎麼簡單怎麼來。但你得清楚，自己要做動態分布的，即便這個版本實在來不及了，先做靜態分布的，下個版本也要改過來的。

3、橫屏 vs 豎屏

曲線是用橫屏來展示好呢，還是豎屏好呢？首先，要看這個頁面有沒有其他元素，有的話只能用豎屏的了（見下圖左）。

iPhone 自帶的「健康」App

在沒有其他因素干擾的情況下，只展示體重曲線，那用橫屏還是豎屏好呢？

我的觀點是：

最好是：先看豎屏，支持橫屏；

其次是：只有橫屏，不能豎屏；

最差的是：只有豎屏，不能橫屏；

不知不覺寫了這麼多，有些超出我的預計。不是我經驗有多豐富，而是我踩了多少坑啊。