約1年多前我寫了一篇《基於axure的prd寫作思考》，其主旨思想是將文件版本的prd與線框圖及流程圖結合起來，統一由axure來輸出，降低pm與研發之間的溝通成本及交付物的傳遞成本。
當時這個文件是基於我做web端產品設計的經驗為藍本完成的，這1年多來我從web端完全轉到mobile端，還在繼續的使用著這套方法。在不斷的實踐過程中略有心得，遂更新一篇，詳細的講述一下這套思路。
當然，肯定會有很多人說axure是個很笨重的工具，從來不用；也肯定會有很多人說我們團隊有嚴格的文件規範，你的這套東西不適用…..是的，你們都是對的。這套方法的最大好處就是快速、直接，適用於扁平化的團隊。如果你是產品與研發異地的團隊，那麼，建議還是有詳細的文件比較合適。
關於乙個prd文件需要包含的內容及相關的結構，之前《基於axure的prd寫作思考》已經說的比較清楚，不再贅述。我們為什麼要寫prd？簡單來說就是把我們具體要做乙個什麼樣的東西很詳細的描述出來並傳遞給團隊其他成員知曉，最終一起執行。這裡面我覺得有3個點特別重要，詳細描述、快速傳遞、一起執行，乙份不管是什麼形式的prd最終都必須做到這3點。
從開啟axure準備開始進行原型設計開始，我會把檔案分成這樣幾個部分：修改記錄、產品結構、（用例及資訊架構）、具體頁面原型設計。在具體頁面的原型設計的時候會再根據這個頁面的負責程度看是否要增加乙個流程圖頁面進去。
修改記錄
修改記錄模組主要是對該原型的迭代歷史進行記錄。修改記錄可以使用文字面板完成，主要記錄比如，什麼時候修改了什麼模組，原因是什麼。每次對原型進行修改都必須記錄下來，這種內容迭代的記錄方式一方面便於自己後續回憶與總結，同時也對專案管理的需要，每次的修改都有據可查。
產品結構
產品設計本身是個從大往小的過程。所謂大就是指的產品整體的結構所謂小則是具體的互動設計頁面布局等。我個人非常不建議一開始就進入到具體的頁面設計，即使是乙個具體的頁面設計也建議先把頁面模組及相應模組的布局想清楚，然後再開始填充內容；而如果是乙個會涉及到很多步驟的設計，如果流程沒有事先想清楚畫出來，千萬不要動手去設計。
按照我個人的習慣，產品結構部分一般會採用結構圖的方式呼叫流程圖模式把這個產品的結構關係畫清楚。目的有這樣幾個：搞清楚使用者的主要路徑，使用者會從什麼地方進入產品，在裡面會經過哪些頁面，然後會從什麼地方退出；弄清楚產品的層級關係，從移動端的設計上看，產品的層級關係一定要避免太深；梳理一下整個產品的頁面，不要有遺漏。
用例及資訊架構
用例之前在web端我通常是直接採用母板來完成的，最近在做mobile的產品設計，倍感在畫原型的時候把用例標識出來的重要性。個人感受，移動端的產品需要比web端更加深入的考慮模組復用，一來保持整個客戶端的統一性，同時復用的模組在一定程度上是可以減少開發工作量的。
當進行需求評審的時候也建議按照這個順序來說，先介紹一下整個產品的結構，向整個團隊成員說清楚我們大概要做乙個什麼樣的產品，他包括哪些部分，這些部分的關係是咋樣的；其次開始介紹一下這個產品他從乙個框架上看是什麼樣子的，有乙個感性的認知；再次開始按使用者任務/流程分模組進行介紹，詳細的說明其中的策略問題。
具體頁面原型設計
具體頁面的原型設計分為2種，1種是頁面行為比較單一，簡單的幾個圖加一定的文字就可以描述清楚的；一種是頁面行為的流程及邏輯性比較強，有比較多的中間狀態和使用者行為的分支，這種頁面我一般的方式是先畫出流程圖，然後再相應的給出頁面原型。
第一種頁面比較簡單，設計的時候想著點各個平台的設計規範（指南）就可以搞定。同時可以在頁面原型的邊上把每個模組部分取的元素內容及相應的策略也寫出來。
不過，需要有乙個提醒，在移動端會存在不少頁面的長度是超過1屏的，在原型設計的時候一定要畫出一條螢幕高度基線，將第一屏內容和第二屏內容隔開。一方面重要的內容都必須在第一屏有所體現，另一方面注意節減頁面高度，同時在原型評審的時候也讓其他角色提前有所了解。
另一方面，如果乙個模組涉及的互動流程比較複雜，比如乙個輸入框，在初始狀態、開始輸入狀態、輸入完成狀態、輸入出錯狀態（超過字數限制）等不同狀態下的表現及相應的操作提示都是不一樣的，建議分別拆成幾個不同的狀態完成。這部分之前在web端的時候可以直接用axure的互動來完成，但是mobile端的螢幕有所限制，再去做這些互動效果，往往也隱藏比較深，不如拆出來畫。
一些關於移動端原型設計的其他問題
1、工具永遠都是工具，不要讓工具限制了你。axure也好，viso也好，omnigraffle也好，做出來的東西無分好壞。
2、除非腦子裡想的比較清楚了，不要衝動性的就開始用axure畫原型。在我看來，畫原型只是20%的功夫，更多的功夫應該在原型之外，包括對要做什麼，為什麼要這麼做的思考。同時，紙面原型是更好的選擇，幫助鋝清思路。
3、在原型設計的過程中需要注意沉澱一些規範性的元件出來。每個團隊每個專案都應該有一套自己的原型元件，而不應該是直接找別人要來原型元件然後直接匯入（當然，系統通用的元件除外）。
4、原型設計的過程中，酷炫的原型互動需要適可而止。
PRD編寫Axure內直接編輯
流程 頁面 互動 邏輯 功能點 1，選項類 設定預設值。2，輸入文字類 設定最多最少字元數。3，功能按鈕，如提交 發布。判斷敏感詞，如果有，則點選發布的時候，懸浮提醒 含有敏感詞已替換為 請檢查並重新發布。判斷是否含有 則懸浮提示 請檢查 並修改，然後重新發布！直到沒有敏感詞才能發布。4，互動說明，...
基於ZooKeeper實現主從協作
主 從模式的模型中，主要包括三個角色 主節點 主要負責監視新的節點和任務，分配任務給可用的從節點 從節點 通過註冊自己，確保主節點看到它們可以執行任務，收到主節點分配的任務後，執行並記錄狀態 客戶端 建立新的任務並等待系統響應。現通過zookeeper的api完成簡單的主從協作。在此之前，需了解下z...
基於Unity的多人協作遊戲開發
小組成立與大型應用軟體設計第一周課堂，小組由一共5名成員組成，由王虎林擔任組長，組員分別是 陳志健 李子釗 楊捷 林博韜。下面將是我們第一次迭代的主要歷程。小組組隊好了以後，第一次小組會議就是討論選題，剛開始不是打算做遊戲的，本來是打算做乙個樂譜的識別和演奏軟體，但是由於知識儲備不充分，所以後面就放...