我們爲什麼要寫PRD？
簡單來說就是把我們具體要做一個什麼樣的東西很詳細的描述出來並傳遞給團隊其他成員知曉，最終一起執行。這裏面我覺得有3個點特別重要，詳細描述、快速傳遞、一起執行，一份不管是什麼形式的PRD最終都必須做到這3點。
從打開axure準備開始進行原型設計開始，我會把文件分成這樣幾個部分：修改記錄、產品結構、（用例及信息架構）、具體頁面原型設計。在具體頁面的原型設計的時候會再根據這個頁面的負責程度看是否要增加一個流程圖頁面進去。
修改記錄
修改記錄模塊主要是對該原型的迭代歷史進行記錄。修改記錄可以使用文本面板完成，主要記錄比如，什麼時候修改了什麼模塊，原因是什麼。每次對原型進行修改都必須記錄下來，這種內容迭代的記錄方式一方面便於自己後續回憶與總結，同時也對項目管理的需要，每次的修改都有據可查。
產品結構
產品設計本身是個從大往小的過程。所謂大就是指的產品整體的結構所謂小則是具體的交互設計頁面佈局等。我個人非常不建議一開始就進入到具體的頁面設計，即使是一個具體的頁面設計也建議先把頁面模塊及相應模塊的佈局想清楚，然後再開始填充內容；而如果是一個會涉及到很多步驟的設計，如果流程沒有事先想清楚畫出來，千萬不要動手去設計。
按照我個人的習慣，產品結構部分一般會採用結構圖的方式調用流程圖模式把這個產品的結構關係畫清楚。目的有這樣幾個：搞清楚用戶的主要路徑，用戶會從什麼地方進入產品，在裏面會經過哪些頁面，然後會從什麼地方退出；弄清楚產品的層級關係，從移動端的設計上看，產品的層級關係一定要避免太深；梳理一下整個產品的頁面，不要有遺漏。
用例及信息架構
在畫原型的時候把用例標識出來的重要性。個人感受，移動端的產品需要比Web端更加深入的考慮模塊複用，一來保持整個客戶端的統一性，同時複用的模塊在一定程度上是可以減少開發工作量的。
就一個Apps而言，這個部分通常會包括一級頁面的頁面結構、二級頁面的頁面結構、三級頁面的頁面結構、….；彈層的樣式及出現方式；是否出現menu鍵、樣式及內容（android）等內容。
當進行需求評審的時候也建議按照這個順序來說，先介紹一下整個產品的結構，向整個團隊成員說清楚我們大概要做一個什麼樣的產品，他包括哪些部分，這些部分的關係是咋樣的；其次開始介紹一下這個產品他從一個框架上看是什麼樣子的，有一個感性的認知；再次開始按用戶任務/流程分模塊進行介紹，詳細的說明其中的策略問題。
具體頁面原型設計
具體頁面的原型設計分爲2種，1種是頁面行爲比較單一，簡單的幾個圖加一定的文字就可以描述清楚的；一種是頁面行爲的流程及邏輯性比較強，有比較多的中間狀態和用戶行爲的分支，這種頁面我一般的方式是先畫出流程圖，然後再相應的給出頁面原型。
第一種頁面比較簡單，設計的時候想着點各個平臺的設計規範（指南）就可以搞定。同時可以在頁面原型的邊上把每個模塊部分取的元素內容及相應的策略也寫出來。
不過，需要有一個提醒，在移動端會存在不少頁面的長度是超過1屏的，在原型設計的時候一定要畫出一條屏幕高度基線，將第一屏內容和第二屏內容隔開。一方面重要的內容都必須在第一屏有所體現，另一方面注意節減頁面高度，同時在原型評審的時候也讓其他角色提前有所瞭解。
另一方面，如果一個模塊涉及的交互流程比較複雜，比如一個輸入框，在初始狀態、開始輸入狀態、輸入完成狀態、輸入出錯狀態（超過字數限制）等不同狀態下的表現及相應的操作提示都是不一樣的，建議分別拆成幾個不同的狀態完成。這部分之前在Web端的時候可以直接用axure的交互來完成，但是mobile端的屏幕有所限制，再去做這些交互效果，往往也隱藏比較深，不如拆出來畫。
一些關於移動端原型設計的其他問題
1、工具永遠都是工具，不要讓工具限制了你。axure也好，viso也好，OmniGraffle也好，做出來的東西無分好壞。
2、除非腦子裏想的比較清楚了，不要衝動性的就開始用axure畫原型。在我看來，畫原型只是20%的功夫，更多的功夫應該在原型之外，包括對要做什麼，爲什麼要這麼做的思考。同時，紙面原型是更好的選擇，幫助鋝清思路。
3、在原型設計的過程中需要注意沉澱一些規範性的組件出來。每個團隊每個項目都應該有一套自己的原型組件，而不應該是直接找別人要來原型組件然後直接導入（當然，系統通用的組件除外）。
4、原型設計的過程中，酷炫的原型交互需要適可而止。