案例分析|一次消滅產品文檔的實踐探索
之前CTO對產品文檔提出了新的要求,這是我們在要求下的新嘗試,給各位分享。
在剛入職眼前這一份工作的時候,CTO就對產品組提出了新的要求:
“以后不用再另外輸出產品文檔,直接在原型上標注就可以了,而且以后要輸出動態原型?!?/p>
先介紹一下我本人的情況,產品經驗2年,對于Axure的交互設計有一定實踐經驗。但從來沒有想過把動態的原型與產品說明結合來表達需求。對于CTO的決定,我想了一下,大概是出于以下三點原因:
- 太多文件數量不利于產品檔案管理。原先產品資料至少會分成產品文檔與產品原型兩個文件,每次產品經理對產品資料進行更新后,則至少要對文件進行兩次的上傳。東西一多,就容易亂。
- 打開多個文件,切換窗口使用的效率低。比方說,原先在產品文檔與原型分開的時候,開發人員往往需要打開原型文件的瀏覽器窗口與產品文檔Word窗口進行切換查看。每一次查看功能點的時候老是要重新鎖定需求說明的位置,又累又浪費時間。
- 靜態原型的表達效率不高。雖然靜態原型也可以直接增加產品文檔注釋,但其在產品資料的交互、邏輯表達能力上較弱,開發、設計、測試等同事在利用上容易造成理解偏差。
實際上,我要做的事情不是消滅產品文檔,而是將產品文檔與動態原型進行最大限度的結合。而經過思考,有下面幾個問題需要解決。(以下內容皆是以Axure RP工具為載體進行說明。)
第一個問題
那么多需求點,怎樣在一個頁面上富有條例地展示出所有的產品資料?
依據我以前的經驗,Axure RP中的“內部框架”(Inner Frame)將會起到非常大的作用。
對Axure RP交互熟悉的產品朋友們,應該能熟練地使用“內部框架”功能來表達一整條產品邏輯線——只要先對所有子頁面進行編輯后,確定鏈接打開的對象即可。
但是,如果本次的產品需求出現了多條不相關的邏輯線(例如,A邏輯線條的功能點的分布是從購物車頁到訂單確認頁,而B邏輯線條的功能點分布是從個人中心頁到個人信息修改頁),又該如何處理呢?
有兩種解決辦法:
- 多放幾個內部框架,以同時展現不同的邏輯線。
- 制作一個遙控臺,在一個內部框架中對多條邏輯線進行切換(靈感來自類似遙控器對電視節目的切換、大學寫論文時通過目錄對內容的定位)。
我選擇了第二種。
在多個項目的實踐過程中,我發現邏輯線數量眾多是很常見的情況;在第一種方式下,會需要放置非常多的內部框架,太多太亂。而第二種解決辦法下,只會存在控制臺與一個內部框架,簡潔明了。
另外,控制臺還能發揮類似“目錄” 的作用。我將每一個邏輯線條的初始頁面與控制臺上的按鈕建立聯系,并且邏輯線條下的頁面也會我被分別整理到文件夾中,這實際是在對產品進行重新梳理的過程。
對于開發、設計師來說,可以一目了然地看到本次項目的邏輯線條,理清產品結構思路,更容易富有條理地利用產品資料。
第二個問題
一個頁面可能會有數十個功能點,怎樣收納這些功能點,又不會超出內部框架的范圍呢?
首先,我個人會將每一個功能點基本分成5個角度記性描述,包括:
- 功能序號
- 優先級
- 展示:文案、功能樣式描述
- 交互:功能相關的交互描述
- 邏輯:功能涉及到的內在邏輯描述
- 數據:功能涉及到的數據收集需求
當然,上述的六點不是必須的,在實際情況中可以選用。例如給公司內部人員使用的產品一般都是不需要記錄使用數據的。
在解決方案上,我使用了大量的Axure RP中“隱藏/展示”的交互效果,以及矩形工具、連線功能。
基本思路是:
優先并始終展示功能序號與優先級,通過點擊功能序號與優先級,再將原本隱藏的展示、交互、邏輯、數據幾個維度進行切換顯示。
圍繞上述4個可能帶有大量文字說明的維度,我又添加了矩形工具,在幾個矩形中填寫說明文案,當使用者點擊某個維度的時候,可切換矩形的顯示情況。
當然,還需要連線工具將矩形與對應的維度進行連線,其中線段也要進行對應的切換顯示處理。
通過這樣的方式,就能很好地對頁面上的功能點進行收納,就算是在移動端頁面上收納數十個功能點也是綽綽有余的。
另外,為了提高標注的效率,可以將標注的整體進行粘貼復制,再修改上面的文案;如此可以保留其中的交互,而不需要重新對標注進行交互設計。
主要是因為Axure RP的母版工具不夠靈活,沒有對單個母版的個性化編輯功能,否則效率可以更高。
第三個問題
如何告訴產品經理的協同伙伴原型上哪里可以進行交互操作?
我的做法是,在Sketch上繪制了一個特殊圖標,這個圖標將表明該處可以進行交互操作,例如點擊、左右拖動之類的。
下方“菱形圓圈”的圖標就是我自己設計的提示圖案:
第四個問題
如何修正標注的字體?
由于在不同的瀏覽器下,默認展示的最小字體不同,所以有的時候會發現本來在原型上設置好的字體突然在瀏覽器中變大了許多,甚至會超出矩形的范圍。
此時只要對瀏覽器進行設置,將最小顯示字體進行修改即可。我個人一般改成6號字,或“特小”。
通過本次的探索,我基本達到了領導的要求,之后會繼續深入,爭取給大家分享更多心得想法。
也歡迎大家一同指教,多多給我提意見。
作者:Dougee,努力中的東方小狼狗
本文由 @Dougee 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自 Unsplash ,基于 CC0 協議
點子相當好,就是會把產品累死!
復制粘貼其實還好,交互都不用重新做,往里面改內容就可以
原型的預覽文件就有高亮功能判斷有交互的菜單,你加標志明顯是多此一舉啊。
但生成的html文件木有耶
html有的,左側欄的右上角圖標了解一下,打開新大門。
有這些時間,不如放在對需求的整理上和重新發現上
我個人是覺得不矛盾,需求的整理與重新發現當然是更重要的工作,可以另外寫一篇文章分享。本文介紹的方式,也不會太影響時間,還可以增加協同伙伴的效率。
說明里可以自定義字段,可對不能描述進行定義
可以,這個可以按需要增加
不難描述有哪些情況啊,我想想感覺自己沒有想明白
你讓交互同學怎么活啊? ?
哎我們公司比較小,所以交互的活都是產品經理來干~直接原型就體現出來了,不過產品原型做的時間就會長些。
小團隊不是應該更注重效率嗎,把原型文檔搞那么復雜沒啥意義還費時間,復雜的當面溝通效率更高。我們公司的開發都懶的看文檔,都是產品會議的時候討論,做的時候當面溝通!
我們這邊項目比較多,開發天天來找,給他們一直解釋中間就不能規劃新的項目。產品做細點,是能節約很多時間的。