于AxureRP的快速原型設計法確實能提高原型設計的效率和提升用戶演示的效果,產品設計、交互設計或者是產品經理在做完原型設計,確認好需求之后,都不可避免的要寫PRD文檔或者是交互設計稿。大公司才會有交互設計師這個崗位,也就才會有交互設計稿這種文檔產出,一般的公司都是只有產品設計師、需求分析師、商務分析師或者產品經理這樣的崗位,這個崗位基本會包辦了從需求收集,需求分析,需求設計,原型設計,編寫PRD這樣的一個過程,所以說小公司比較鍛煉人,會練就全能的本事。
編寫PRD文檔是個較為苦命的工作項,具體的編寫要求參見《如何書寫好的產品需求文檔PRD》,這份文檔將會作為產品的指導性文檔,告訴開發、測試產品的需求點,實現的要求,驗證的邏輯,運營人員也需要參考,以獲知當前產品所能達到的功能層次。寫文檔的時候事無巨細吧,人家會嫌你寫的太繁瑣了;寫的太簡單吧,人家又會嫌你沒說清楚該說的;開始使用敏捷模式要求文檔弱化了,但其實只是在過需求的時候不需要提前先把PRD寫好,事后還是得補的;寫文檔耗掉的時間多了,人家會說能否除掉一半,功能需求都確認好了,你只是將它描述出來為什么要用掉那么多的時間?凡此種種,都讓做產品的我們感覺命怎么這么苦,因此開拓一種寫PRD的新思路新方法是相當有必要的。
現在都講究用工具來輔助,工具用的好,確實能事半功倍,那要是工具用的不好呢?那就只能自求多福了。原型設計軟件的主要功能還是用來做原型,那是否原型演示完了之后就沒有用了呢?這個我想有點工作經驗的人都不會這么認為,當然我們還是可以發揮一下原型的剩余價值的。大家都知道,如果一份文檔里面可以圖文結合,所描述的東西更能吸引到人去閱讀,也更能幫助別人理解。AxureRP所設計的原型支持HTML格式的瀏覽,相較于其他原型設計軟件直接產出圖片,AxureRP的原型即可以直接導出成圖片格式,也可以通過在瀏覽過程當中用截圖軟件來截圖的方式使用,當然后一種方式更為繁瑣,后面說明為什么直接生成圖片反而不方便。
使用AxureRP自帶的文檔生成功能去生成PRD文檔
這點我在之前寫AxureRP使用教程的時候有提到過,AxureRP是支持通過即定的word模板格式來導出生成文檔的,可以參考《AxureRP教程–生成規格說明書》。不過使用這個功能對自身的要求是比較高的:
1、要對AxureRP所提供的注釋功能非常熟悉,其默認提供的注釋字段是國際通用的,并不適合中國國情,要根據產品和項目的需求進行修改和自定義。要了解組件注釋和頁面注釋的使用方式,以及這些注釋會出現在文檔的什么位置等;
2、要在做原型設計的時候就做好注釋的錄入,每個組件的交互,前置觸發條件,后置反饋事件,以及每個頁面的功能說明等,這是一項細致活,挺耗時間的,和快速原型設計的要求不大相符;且萬一在確認需求的過程當中需要修改的,這個維護量也比較大;
3、要熟悉word的格式排版設置,用AxureRP默認提供的word模板生成出來的PRD文檔,估計不符合大多數公司的文檔編寫要求,如果沒有要求的則可以直接使用,否則就得自己倒騰一個word模板出來,這個對word的功底要求較高,再就是還得熟悉AxureRP里面模板導入的機制和模板使用機制;
4、綜上所述,這個功能雖然很強大但實際應用的較少,其實比較雞肋,個人是已經放棄了,有興趣的朋友可以深入研究一下,到時分享一下;
基于AxureRP原型的PRD文檔編寫
這個方式其實就是截圖,然后用截圖+文字的形式來書寫PRD文檔,有人就說了,圖片制作軟件那么多,為什么非得用AxureRP來做原型,還得截圖呀,這里有個已經使用AxureRP的前提:
1、AxureRP提倡快速原型設計法,可以大大減少原型設計的時間,這是選擇使用AxureRP的一個原因;
2、AxureRP支持HTML格式的瀏覽,極大的方便了原型的演示效果,可以很清楚地告訴演示對象每個頁面的跳轉,每個按鈕的操作效果,每個連接點擊結果等,這是選擇使用AxureRP第二個原因;
當然AxureRP的優點不止于此,原因可能很多,但主要的是這兩個方面,這兩個前提決定了我們當前都是使用AxureRP來做原型設計的,然后再討論如果在已經使用AxureRP的情況再來優化截圖寫PRD的方法,否則就沒法進行下去了。
1、為什么是HTML格式頁面的截圖而不是直接導出圖片?這個從操作層面上來講,導出圖片的模式操作流程如下:
導出為圖片>>>打開word>>>選擇插入菜單>>>選擇插入圖片>>>搜尋圖片所在文件夾>>>選擇圖片>>>點擊按鈕完成插入圖片操作;
或者是下面這種方式:
導出為圖片>>>打開圖片所在文件夾>>>選擇插入圖片并打開>>>復制圖片>>>打開word>>>粘貼圖片完成插入圖片操作;這個比上面的省一個步驟;
從HTML頁面截圖的模式操作流程如下:
打開對象所在HTML頁面>>>用截圖工具截圖>>>復制所截圖片>>>打開word>>>粘貼圖片完成插入圖片操作;
對比一下就知道,用截圖的方式所需的操作步驟是最少的,也就是最能節省時間的,這里推薦一個截圖工具:Snagit(下載地址),可以對所截的圖進行一些簡單的編輯,比如畫個圈圈提示一下,畫點箭頭什么的。
2、基于AxureRP原型截圖這種方式更能適應需求變化。大家都知道AxureRP是支持單個頁面的修改單個頁面重新生成原型的,不需要整體原型重新生成一遍,這樣某個地方修改了,只要重新生成一下原型,然后再截圖修改即可,而導出圖片的方式AxureRP只支持導出主頁和導出全部頁面兩種方式;
3、截圖工具的輔助功能,上面也提到了,可以對圖片做一些必要的處理;
這是截圖+文字的模式,有了截圖之后,編寫描述文字應該就方便很多了,避免出現大段的文字。另外PRD編寫一般都是有格式要求的,有些內容不能用工具來解決,一般一份PRD文檔要包含以下這些內容:
1、概述部分:簡單介紹一下產品的背景,產品的價值或者愿景,產品的簡單介紹,一些預估的風險點,干系人,名詞解釋等等;
2、業務需求描述部分:定義好目標用戶群體,業務流程圖,業務架構圖,腦圖等等的介紹;
3、功能需求描述部分:這部分才是用到上面所述方法的點,每個功能點都可以用那樣的方式描述;
4、非功能需求描述部分:與產品相關的一些輔助功能,性能要求、易用性要求等等;
5、接口描述部分:與外部有相關接口的需要在這個部分描述;
6、附錄部分:培訓信息、參考資料等,還可以有運營計劃等等;
完整的PRD文檔中,最多的部分就是對功能需求的分解描述,AxureRP可以很好的支撐這個部分的全部內容,另外其實AxureRP也有流程圖、UML圖的功能,業務流程圖、業務架構圖等都可以在AxureRP里面實現出來。
基本上我自己目前就采用的是如上的方式來編寫PRD文檔,在原型已經設計好并演示確認了的情況下,編寫PRD文檔一般都比較快速,30頁到50頁之間的文檔,如果時間利用充分的話,可以在1天到1天半之內搞定。產品經理都是很忙的,時間擠擠總會有的,要在有限的時間內做更多的事,一是要充分利用工具,二是要發掘一些新的方法,雙管齊下,應該就可以找到適合自己的Style!
PM完成Axure原型評審后,一定不能忘記備份這些原型html,后續可能需要查詢以及技術撕逼。
希望通過Axure原型的幾種使用場景,讓初級PM對它的來龍去脈有個清晰的了解。而不是停留在“我知道”“大概會用”的水平。
PM會經常修改AxureRP源文件,然后生成不同的原型。
但是對外評審的原型應該是唯一的。
并且該版本的產品需求文檔PRD就是這個原型。
請注意兩者不能混為一談。
一般來說我們是在Axure生成原型Html的時候,自動在瀏覽器中打開了原型并查看。
但是如何打開已備份在電腦中的原型呢,很多初級PM摸不著頭腦了。其實也不復雜,如果你學會一點html網頁的知識。
請進入該原型對應的目錄,比如APP名稱V2.0版,我們會發現存在data、file、images、plugins、resources等文件夾,以及很多html網頁。請找到start.html,然后雙擊打開就是你熟悉的原型啦。
當原型評審后,PM需要將原型放到網上供所有團隊成員進行設計和編程。
不管是放到內網展示,還是外網展示。其本質都是將Axure原型的所有文件都上傳到服務器,包括所有的html文件,圖片文件,js文件,css文件。不能缺少任何文件,否則就無法正常顯示。
如果你只是修改了某個頁面,也切記生成并將所有文件上傳一遍,而不僅僅是該頁面對應的html文件。因為其對應的js,css文件,圖片文件也可能被修改
上傳之后然后把對應的原型網址發給其他團隊成員即可查看。
由于Axure原型是由html+js+cs組成的文件,我們在生成的時候將他們放置在指定目錄。
嘉定我們將該產品的所有原型存放于D://PM/APP名稱,那么建議以“APP名稱V1.0版”的格式命名,并生成原型。
當然你也可以繼續壓縮之后存起來,不過就不太方便后續的查詢。
有時候我們需要回退版本的時候,需要把舊版本的原型也拿出來。那么請用舊版本的原型html去替換當下的原型目錄。
不過不太建議這樣,還不如新增一個版本來處理。
由于Axure生成的原型,是以Html文件進行索引內容的。而Html是以你在Axure中新建的頁面來作為基礎的。如果你畫Axure原型的時候是以你產品中的頁面來進行命名和創建的。那么我們可以通過搜索“頁面名稱”關鍵詞去查詢你想要查詢的頁面。
如果你使用的搜索工具支持搜索文件內內容,比如Windows下面的everthing,Mac自帶的spotlight。那么可以通過搜索“頁面內文字”關鍵詞去查詢你想要查詢的相關頁面。
不過我更建議你進入到具體版本的原型html文件夾里面進行搜索,而不是進行全局搜索。
以上就是Axure原型的使用場景。請一定要理解Axure原型的本質是html+js+css,每次生成原型的時候會在本地生成目錄并寫入這些文件。
浪子,業務型PM,浪子PRD系列51prd.com,公眾號langzisay,個人微信nuanai88。
本文由 @浪子 原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自 unsplash,基于 CC0 協議
多PM使用Axure畫原型,然后通過口述、word、visio、標簽、原型旁邊文字標注等方法來表達產品邏輯。很少有PM使用Axure官方推薦的notes,而事實上這才是正統高效的產品邏輯表達法。
可能是因為Axure官方沒出過相關的中文教程,網上很少有人總結過類似的經驗。今天我來完整的講解一下notes表達法,希望對大家有所啟發。
曾經寫過一篇文章介紹各種產品邏輯表達法,可以輔助閱讀。
notes邏輯表達法相比于其他方法,具有以下優勢,其中易讀性特別重要。
Axure官方對notes的定義是,與控件或者頁面相關聯的文本元數據。可用于記錄規格,將控件和頁面與需求本身相關聯,記錄更改,并與隊友進行溝通。
通常控件和頁面自帶一個名為“note”并且類型為文本的注釋字段。
部分漢化包將notes命名為“元件說明”或者“備注”,請知悉。
我主要講一下如何寫控件的notes,頁面的邏輯寫法相似的,會一帶而過。
進入你要修改的頁面,在畫布中選擇需要的控件。此時右方檢查器那邊,點擊中間的選項卡。
如果是設置頁面注釋,直接進入畫布不要選中任何控件或者單擊空白區域,此時右方檢查器自動切換成頁面檢查器。
填寫你對這個控件定義的邏輯。比如這樣子:
具有筆記或互動的小部件在畫布上顯示時,會在小工具的右上角顯示一個藍色的腳注圖標。
然后,如果你覺得這個注釋命名note不合理,想修改。請點擊上方的Customize Fileds,進入彈窗。然后雙擊名稱,即可修改。
用著用著,你會發現一個注釋字段無法寫清楚多方面的邏輯。此時可以新增幾個注釋字段。
點擊Add,新增注釋字段,選擇類型:文本、選擇列表,數字、日期。注意頁面注釋只有文本類型。
比如,我們新建一個“視覺邏輯”,成功之后,回到任何一個頁面的畫布中,再次選擇控件即可看到該新增字段。注意如果類型是選擇列表的時候,需要在右邊填充列表項。
在查看HTML輸出時,Axure RP界面和瀏覽器都可以看到注釋,但只能在RP源文件中進行編輯。
生成原型之后,進入到對應的頁面。點擊該控件旁邊的藍色小圖標,即可展示該控件的全部邏輯。
另外你可以在左方的Tab中選擇notes,查看該頁面所有的控件邏輯,其中頁面邏輯顯示在做上面。
點擊邏輯,此時右方會藍色高亮選中控件的邊緣。表示這個控件對應的注釋是哪些。這種體驗比拖拉一個便簽好用太多。
我用此方法完整撰寫的APP案例-閃電約,也可以下載原型學習。
事實上三四年前我就開始使用notes邏輯表達法了,當Axure RP升級到版本8的時候,notes功能才真正的算是很實用。推薦大家都可以試試notes邏輯表達法。
另外有英文基礎的朋友建議看一下官方對該功能的定義和講解,WIDGET AND PAGE NOTES。
*請認真填寫需求信息,我們會在24小時內與您取得聯系。