作者:迪達
來源:知乎。
-
作者:張金義
先簡單說壹下上面的框架。
1.背景
妳為什麽要這麽做?這個需求從哪裏來,都有說明,方便開發和團隊知道,讓參與者感覺不那麽像“產品經理,除了找茬什麽都不懂”。
2.總體框架
可以放個圖什麽的。,主要是壹個大綱,有可能的話可以放壹個超鏈接在裏面,方便用戶在閱讀的時候點擊對應的章節。
3.原型設計
可以通過反應的變化來區分。比如KEVIN主要是調整界面和交互,所以分類是基於相應的目標。當然,根據自己的需要,比如添加功能的情況,可以用功能區分的方式來表達,用腳註來標註,並對圖片或圖標進行相應的裁剪。
4.原型操作說明
這個KEVIN覺得為了自己的推廣,PM還是應該寫壹個相應的內容,尤其是讓用戶或者BOSS知道自己在相應的功能上花了多少心血。當然還有更敏捷的方法,就是讓他們自己摸索,或者不懂再問。
5.腳註
作為之前的原型設計,對應腳註的具體解釋便於對照原型理解。當然,腳註也可以和原型設計的對應功能結合,對應功能有壹個腳註會更直接。凱文這裏的腳註不算太多,跨越的頁數也比較多,所以算作壹個標題。
腳註
6.時間和日程安排
如何做到這壹點可以參考KEVIN在產品叠代和項目進度安排之前的壹篇文章。這裏補充壹下,讓項目人員知道這個函數優化的優先級,也了解壹個大概的輪廓。這樣便於PM後期安排和跟蹤項目。
好了,今天就到這裏。大家這周繼續努力吧!