在設計日報中，你應該站在不同的角度去幫助用戶解決問題，將你的設計進行可視化。

為什么要寫設計日報？

1. 管理需求的必要

我們有些人對待需求任務比較渾渾噩噩，不擅長管理自己的需求，具體表現為：

a.不清楚要做的需求有哪些，只有等別人說了，才開始適應需求，“缺乏準備就去做”就好比連刀都沒磨就去砍柴一樣；

b.同步進行的需求不知如何分配優先級，只是一味遵循先后順序，最后導致項目流程中出現這樣那樣的延期問題；

c.對于正在做的需求缺乏時間意識，理論上說，應當以每個小時為單位，時刻思辨需求的進展，鞭策自己高效一點。明明一個可以4小時做完的需求，偏偏搞了12小時，最后效果還差，如果是4小時做完，意味著還有2次調整機會，但12小時就意味著只能這樣了，因為馬上就要上了！

d.不清楚做完需求的各自進展如何，哪些已經可以驗收了、哪些卡住了，是否需要設計調整、哪些已經上線了，數據反饋是否已經可以查了……

2. 關注用戶問題的必要

有時為了追究快，我們會避開一些看起來麻煩、瑣碎且未知的事情，去選擇那些簡單、直接且處于經驗內的事情。

比如拿到需求的第一件事應當是去定位用戶問題，而不是立馬開展需求設計，盡管Steve?Krug?已經把如何理解用戶的時間成本壓縮至幾分鐘，但又有多少人真正去用呢？

項目匯報上面，我們聽到最多的就是我做了什么功能，預期多少人會用我這個功能；很少聽到有人說，我發現了什么用戶問題，為什么我的策略可以解決這些人的問題。

我上篇文章講了一個關于賣煎餅的故事，意思就是：你硬是把“我今天必須賣出200個煎餅”這樣的產品目標設為你的執行目標，大概率會失敗的。

用戶在意的煎餅細節（用戶心理模型）與你提供的（系統模型）完全不匹配。用戶期望煎餅醬料好吃、夾心脆香、面皮薄，而你提供實現200個煎餅銷量的策略是性價比——便宜且分量足。

3. 輔助我們去角色化思考的必要

我們很多人其實并不會思考，討論問題時容易角色化，總是“我覺得應該怎樣怎樣”，這種狀態很難說服你的需求上游，憑啥“你覺得就對”?。

之前有產品經理想做一個可以根據手機殼顏色變化的UI主題，然后就被程序員打了……

看到沒，這就是角色化思考帶來的風險，我說的風險不是被打，而是兩個角色化的人在一起討論問題就好像兩小兒辯日，是不會有結果的。

輔助我們去角色化思考這件事就好比練字，沒有人天生字就好，那些字好的人一般都照著字帖練了好幾年。字帖這個東西其實就是我們需要的思考范式，在你沒把字練好之前，請老老實實照著字帖練。

你的設計日報寫對了嗎？

我們看到最多的設計日報都是在講項目進度的事情：今天我做了哪些功能，耗時多少小時，絲毫沒有提及今天我解決了用戶的哪些問題。

既然都是講項目進度的事情，那干脆就叫“項目日報”好了，項目日報最好的呈現方式是早上例會，項目成員匯報昨天工作進展以及今日計劃，而非一個文檔，扔群里就完事了。

項目進度只是設計日報其中的一個方面，你更應該站在“解決用戶問題”的視角去可視化你的設計日報。

如何制作設計日報？

1. 制作日報目錄

目錄是給自己看的，因此不需要在意什么形式，自己能看懂就行。

目錄共分為4個子文件：要做的（to_do）、正在做的（doing）、需要驗收的（check）、已經上線了，可以查到數據了（done）。

1.1 確認需求，評估制作時間，加入to_do文件
加入to_do文件的需求必須確認兩個細節：

a.該需求是否清晰、具體，“感覺”類的需求一律不接，比如做成喜馬拉雅感覺、做成魔戒中某個情節的感覺……

b.需求是否有用戶問題或用戶目標的支撐，可以是來源于線上數據分析的結論、可以是來源于電話回訪之類的用戶調查、可以是來源于競品分析后的規則抽象。缺少的必須補充完成，否則不加入to_do文件。

確認無誤后，評估需求的制作時間，如3天，然后加入to_do文件。

這里的3天僅是代表一個時間段，不是說從現在開始計時，3天后就要交付這個需求，因為你還得根據項目時間節點、需求本身重要性對文件中的所有待做需求進行優先級評估。

結合中間可能涉及測試驗收，你需要在每個需求前后預留半天左右時間，最終確定時間計劃表；有時我們還會遇到一些臨時插入的緊急需求，就需要調整計劃表，并將調整后的信息同步到位。

1.2 給doing文件設置極限值

doing文件的容量一般設為3天，代表我們處理問題的極限，超過這個極限需要等這個doing完成，再拖進來。這樣做的目的是保證我們不會失控，能夠聚焦當前任務，腳踏實地把每一件小事做好，累計起來就是了不起。

1.3 更新項目進度

已做完需求會進入項目開發，你需要每天更新項目的進展情況：什么時候進入開發、預計多久可以測試驗收。驗收過程中需要將問題、當前實現、預期效果列下來，并通知開發進行調整，調整通過之后，將需求拖至done文件。

1.4 更新數據日報

我們需要留意done文件內需求的數據變化，是否符合我們之前預期，如果不符合，問題出在哪？后續優化計劃是什么。

2. 開始制作設計日報

目錄完成之后，我們就可以開始制作設計日報了，一個完整的設計日報需要包含以下6個內容：

2.1 當前需求的進度

當前進度可以分為：設計中、待評審、UI效果圖評審、開發中、待驗收、數據分析6個狀態，在需求進度后需要添上預計完成時間，每天需要對“當前進度”進行更新。

2.2 上線后效果評估

能夠評估我們設計的東西效果怎樣，有兩個方式：數據埋點、用戶調查。

數據埋點

對將要優化的路徑節點設置埋點（圖中數據是我虛構的）：

根據埋點建立評價指標表（圖中數據是我虛構的）：

用戶調查

比如我們想要評估一個關于進場加載優化方案的效果如何：

自變量：原方案（小菊花）與當前漸進式加載方案；

因變量：用戶對于產品品牌感知分數。

實驗方式：

a.組內設計，30個被試，分別對兩個方案進行體驗，體驗后，再進行李克特量表評價；

b.品牌感知評價體系的建立：功能預期（覺得比較厲害）、產品印象……

2.3 確定設計背景

你為什么要設計這個功能？是因為線上數據的某個節點轉化率低？還是因為競品研究過程中，發現我們缺失了一些重要場景？或者源于用戶反饋說某個功能沒法用。

這些都是我們開展設計的背景，它的作用可以幫助我們從意識上更加認同這個需求。

缺失設計背景，會導致我們無法認同將要做的需求，從而和需求上游形成“甲方-乙方關系”，這種關系下的互動模式是應付，應付是不可能做出好東西的。

以線上數據為例（圖中數據是我虛構的），發現在點擊分享這個節點上，整體分享率低，原本至少10%的分享率由于入口的因素變成了2%。于是我們把分享率低確定為設計背景。

2.4 定義用戶問題

我們很多人容易忽略這一步，拿到設計背景后直接開始設計策略，以提升入口分享率為例，對應的設計策略有很多：把分享入口前置？去Feed流投個廣告？在分享入口上加個微動效？

選擇哪些策略？其實你也不確定，這就是紙上談兵帶來的“心虛”，因為你不了解實際戰場的地形是怎樣的。這里的實際戰場地形指的就是定義用戶問題這個環節，它的作用是讓我們更加落地、更具同理心，能夠始終站在用戶的視角看問題。

上篇講了一個關于賣煎餅的故事，意思就是說，如果去賣煎餅，我們不能圍繞如何提升200這個銷量目標，制定設計策略；而是應當圍繞，用戶吃煎餅時，在意哪些體驗細節去構思自己的煎餅策略。

對于提升入口分享，定義的用戶問題有：

a.由于入口可見性差，導致原本至少10%的分享率降至2%（數據反饋）；

b.分享前底部工具條樣式的美觀性，一定程度上影響了用戶的分享動機（電話回訪）；

c.分享后的鏈接形式一定程度上影響了用戶的分享決策（電話回訪）；

d.分享后的鏈接形式一定程度上影響了回流（電話回訪）；

e.選股、診股場景下工具條體驗不一致，一定程度上影響了用戶的慣性行為（自己分析）。

2.5 確定設計策略

針對用戶問題構思與之相對應的設計策略，比如針對提升入口分享的設計策略有：

a.分享入口前置，提升分享入口的可見性；

b.優化工具條樣式，提升分享頁面整體的美觀度；

c.梳理各個渠道滿足用戶預期的分享形式。

2.6 完善交互細節

針對上述的3個設計策略，進行交互細節設計，比如針對策略1–如何前置分享入口，需要確認的交互細節有：

a.入口前置至什么位置？左邊？中間？右邊？

b.入口形式是怎樣的？是Button？還是類似微博那樣的工具條菜單？

c.工具條菜單是否有場景重復項？需要合并同類項處理？如果需要，對應的工具條菜單形式是怎樣的？

如何去確認這些細節呢？其實很簡單，遵循上一步的設計策略即可：

a.入口放在中間位置，有助于提升入口可見性；

b.由類似微博那樣的工具條菜單組成的分享頁面不僅不會影響入口的可見性，還會提升分享頁面整體的美觀度；

c.對工具條做減法，合并相似場景的操作，突出分享入口的可見性。

2.7 完成設計日報制作

小結

設計日報的本質其實就是個字帖，如果你的字還沒那么好，考慮問題還沒那么成熟，那么請老老實實照著字帖練，這個字帖可以給你帶來的價值有：

1. 幫助你更好的管理自己的需求，明確自己的邊界，持續聚焦自己的任務；

2. 逼迫你在開展設計前思考要當前的背景是什么？對應的用戶問題有哪些？

3. 給你提供一個去角色化的思考框架，幫助你選擇正確的設計策略，做正確的設計。

#專欄作家#

UE小牛犢，微信公共號：交互實驗獅，人人都是產品經理專欄作家。關注產品思考、用戶體驗分析、交互研究，致力于UX方法論的探索和實踐。

本文原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議