全栈工程师?
嗯.....目前并不是!

你的設計日報寫對了嗎?

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

為什麼要寫設計日報?

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 協議

版权声明:本文采用知识共享 署名4.0国际许可协议 [BY-NC-SA] 进行授权
文章名称:《你的設計日報寫對了嗎?》
文章链接:https://www.pmbear.com/archives/9448
本站资源仅供个人学习交流,请于下载后24小时内删除,不允许用于商业用途,否则法律问题自行承担。

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

大前端WP主题 更专业 更方便

联系我们联系我们