在設(shè)計日報中，你應(yīng)該站在不同的角度去幫助用戶解決問題，將你的設(shè)計進(jìn)行可視化。

為什么要寫設(shè)計日報？

1. 管理需求的必要

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

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

b.同步進(jìn)行的需求不知如何分配優(yōu)先級，只是一味遵循先后順序，最后導(dǎo)致項目流程中出現(xiàn)這樣那樣的延期問題；

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

d.不清楚做完需求的各自進(jìn)展如何，哪些已經(jīng)可以驗收了、哪些卡住了，是否需要設(shè)計調(diào)整、哪些已經(jīng)上線了，數(shù)據(jù)反饋是否已經(jīng)可以查了……

2. 關(guān)注用戶問題的必要

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

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

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

我上篇文章講了一個關(guān)于賣煎餅的故事，意思就是：你硬是把“我今天必須賣出200個煎餅”這樣的產(chǎn)品目標(biāo)設(shè)為你的執(zhí)行目標(biāo)，大概率會失敗的。

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

3. 輔助我們?nèi)ソ巧伎嫉谋匾?/h3>

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

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

看到?jīng)]，這就是角色化思考帶來的風(fēng)險，我說的風(fēng)險不是被打，而是兩個角色化的人在一起討論問題就好像兩小兒辯日，是不會有結(jié)果的。

輔助我們?nèi)ソ巧伎歼@件事就好比練字，沒有人天生字就好，那些字好的人一般都照著字帖練了好幾年。字帖這個東西其實就是我們需要的思考范式，在你沒把字練好之前，請老老實實照著字帖練。

你的設(shè)計日報寫對了嗎？

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

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

項目進(jìn)度只是設(shè)計日報其中的一個方面，你更應(yīng)該站在“解決用戶問題”的視角去可視化你的設(shè)計日報。

如何制作設(shè)計日報？

1. 制作日報目錄

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

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

1.1 確認(rèn)需求，評估制作時間，加入to_do文件
加入to_do文件的需求必須確認(rèn)兩個細(xì)節(jié)：

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

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

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

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

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

1.2 給doing文件設(shè)置極限值

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

1.3 更新項目進(jìn)度

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

1.4 更新數(shù)據(jù)日報

我們需要留意done文件內(nèi)需求的數(shù)據(jù)變化，是否符合我們之前預(yù)期，如果不符合，問題出在哪？后續(xù)優(yōu)化計劃是什么。

2. 開始制作設(shè)計日報

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

2.1 當(dāng)前需求的進(jìn)度

當(dāng)前進(jìn)度可以分為：設(shè)計中、待評審、UI效果圖評審、開發(fā)中、待驗收、數(shù)據(jù)分析6個狀態(tài)，在需求進(jìn)度后需要添上預(yù)計完成時間，每天需要對“當(dāng)前進(jìn)度”進(jìn)行更新。

2.2 上線后效果評估

能夠評估我們設(shè)計的東西效果怎樣，有兩個方式：數(shù)據(jù)埋點(diǎn)、用戶調(diào)查。

數(shù)據(jù)埋點(diǎn)

對將要優(yōu)化的路徑節(jié)點(diǎn)設(shè)置埋點(diǎn)（圖中數(shù)據(jù)是我虛構(gòu)的）：

根據(jù)埋點(diǎn)建立評價指標(biāo)表（圖中數(shù)據(jù)是我虛構(gòu)的）：

用戶調(diào)查

比如我們想要評估一個關(guān)于進(jìn)場加載優(yōu)化方案的效果如何：

自變量：原方案（小菊花）與當(dāng)前漸進(jìn)式加載方案；

因變量：用戶對于產(chǎn)品品牌感知分?jǐn)?shù)。

實驗方式：

a.組內(nèi)設(shè)計，30個被試，分別對兩個方案進(jìn)行體驗，體驗后，再進(jìn)行李克特量表評價；

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

2.3 確定設(shè)計背景

你為什么要設(shè)計這個功能？是因為線上數(shù)據(jù)的某個節(jié)點(diǎn)轉(zhuǎn)化率低？還是因為競品研究過程中，發(fā)現(xiàn)我們?nèi)笔Я艘恍┲匾獔鼍?？或者源于用戶反饋說某個功能沒法用。

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

缺失設(shè)計背景，會導(dǎo)致我們無法認(rèn)同將要做的需求，從而和需求上游形成“甲方-乙方關(guān)系”，這種關(guān)系下的互動模式是應(yīng)付，應(yīng)付是不可能做出好東西的。

以線上數(shù)據(jù)為例（圖中數(shù)據(jù)是我虛構(gòu)的），發(fā)現(xiàn)在點(diǎn)擊分享這個節(jié)點(diǎn)上，整體分享率低，原本至少10%的分享率由于入口的因素變成了2%。于是我們把分享率低確定為設(shè)計背景。

2.4 定義用戶問題

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

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

上篇講了一個關(guān)于賣煎餅的故事，意思就是說，如果去賣煎餅，我們不能圍繞如何提升200這個銷量目標(biāo)，制定設(shè)計策略；而是應(yīng)當(dāng)圍繞，用戶吃煎餅時，在意哪些體驗細(xì)節(jié)去構(gòu)思自己的煎餅策略。

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

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

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

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

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

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

2.5 確定設(shè)計策略

針對用戶問題構(gòu)思與之相對應(yīng)的設(shè)計策略，比如針對提升入口分享的設(shè)計策略有：

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

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

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

2.6 完善交互細(xì)節(jié)

針對上述的3個設(shè)計策略，進(jìn)行交互細(xì)節(jié)設(shè)計，比如針對策略1–如何前置分享入口，需要確認(rèn)的交互細(xì)節(jié)有：

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

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

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

如何去確認(rèn)這些細(xì)節(jié)呢？其實很簡單，遵循上一步的設(shè)計策略即可：

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

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

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

2.7 完成設(shè)計日報制作

小結(jié)

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

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

2. 逼迫你在開展設(shè)計前思考要當(dāng)前的背景是什么？對應(yīng)的用戶問題有哪些？

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

#專欄作家#

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

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自 Unsplash，基于 CC0 協(xié)議