對于設(shè)計師來說，如何才能確定他的原型圖是否做的好，一般來說，在制作好之后都是需要經(jīng)過多方面加工的，而這些修改的原因就是因為用戶的反饋以及我們在后臺收集的數(shù)據(jù)通過分析得出的結(jié)果。

今天，我們就來講一下，如何通過大數(shù)據(jù)分析來制作原型圖。

1.產(chǎn)品定位，定義形式及交互模式

產(chǎn)品定位主要需要考慮三個問題;什么樣的用戶想要什么?我們要做什么樣的產(chǎn)品(也可以只是個模塊或功能)?我們要做什么樣的?

這是一個產(chǎn)品要考慮的基本問題，但如果這些問題都沒考慮清楚，那么后期的設(shè)計一旦出了問題，全部將會重頭開始。一般可以根據(jù)需求，用戶畫像，反饋痛點，運營同事，老大要求等對產(chǎn)品定位展開分析。

定義形式可以理解為用戶會投入多大的注意力和產(chǎn)品互動，產(chǎn)品的行為會對用戶投入的注意力做出何種反饋。定義形式可以通過產(chǎn)品使用的情景場景，環(huán)境等做出決策。

交互模式即用戶與產(chǎn)品互動的方式，受到產(chǎn)品定位和形式的影響，如果是手機應用，那么交互模式基本就是單手觸控。手指點觸，滑動等。web產(chǎn)品則是鼠標點擊等，VR產(chǎn)品用視覺停留等，不用的交互模式會有不同的限制，應該在早期就規(guī)劃清楚。

2. 定義功能和數(shù)據(jù)

這里的定義功能則是指的較為具體的功能及對應的數(shù)據(jù)元素，與產(chǎn)品定位中考慮的功能不同。這里將需要將宏觀的功能具體化。

比如設(shè)計一個打車軟件，產(chǎn)品定位通常是簡短的一句話：用戶打開打開軟件發(fā)送打車請求，然后車就到了。 具體的功能則需要考慮到：打開軟件是否要告訴用戶附近有哪些車?發(fā)送請求是不是要多個催司機功能?

而數(shù)據(jù)元素則需要考慮到：告訴用戶附近有哪些車的時候，要告訴他們具體是多少米?催司機時是否只用發(fā)送催司機的文本消息?

每個功能及元素的定義要針對需求，考慮周全了，產(chǎn)品各方面都有會有清晰的意圖。

數(shù)據(jù)元素通常都是彼此關(guān)聯(lián)的，建議在定義產(chǎn)品數(shù)據(jù)時可以通過畫數(shù)據(jù)流圖來分析，視覺化的數(shù)據(jù)元素將會讓你更能結(jié)構(gòu)化地去管理，去分類排布，讓你的設(shè)計逐漸清晰具體，讓開發(fā)人員更好理解你的意圖。

功能及數(shù)據(jù)就可以形成一個較為初步的設(shè)計方案了，這時就可以開始對這個方案進行檢測了。檢驗解決方案最好是從情景場景開始，分析人物畫像，用戶的目標，用戶的的心理模型。一個簡單的需求將會有多種解決方案，這時候需要考驗設(shè)計決策能力，通常可以從以下幾個方面著手：

最有效滿足用戶目標

最符合設(shè)計原則

最適合當前的技術(shù)水平和成本

能滿足其他條件等

滿足用戶目標應該是一個順暢的過程，減少用戶理解或?qū)W習成本，讓用戶能夠順暢地操作軟件達成自己的目標。檢驗這個過程有個好方法，即用戶對該產(chǎn)品產(chǎn)生控制感，能夠潛意識地完成操作。

android和iOS的原則已經(jīng)考慮地較為詳細和周全了，使用它們將會對你的抉擇有很好的幫助。

3. 確定層級和頁面

確定一個頁面應該放多少東西，一個任務(wù)要分多少步來完成，通常情況下，一個頁面能夠完成的任務(wù)不要分多個頁面完成，盡量不要超過3個頁面。

當頁面元素居多時要保證用戶合理的視覺線，最需要用戶知道的東西要在最顯眼的地方，次級居之，就算是一個頁面也是有層級之分的，可以通過元素大小，顏色，來強化用戶對層次的感知。

也并非所有情況下都需要減少元素或是頁面來幫助用戶快速完成任務(wù)，比如支付頁面，多級確認讓用戶減少犯錯成本。一些重要的操作多一個頁面確認反而更能讓用戶安心。

在這個階段通常需要考慮這樣一些問題：

哪些元素需要在一起

如何組織才能優(yōu)化用戶工作流

哪些元素需要捆綁使用，哪些不需要

相關(guān)聯(lián)的任務(wù)使用的順序如何

哪些元素能幫助用戶做出決定

采用何種交互模式和原則

人物模型的心智模型如何影響元素組織

塔式塔原則也許能夠幫到你，即相關(guān)聯(lián)的控件應該組合在一起，控件應該靠近所要控制的對象。

4. 繪制原型草圖

有了以上的構(gòu)思這一步就會變得容易，但要注意的是，最好是從整體且高層次的框架開始構(gòu)建，(若使用axure繪制原型，這個地方就可以考慮好使用母版避免以后較多重復的修改)不要被細節(jié)分散了注意力，細節(jié)留到最后去仔細推敲。

5. 構(gòu)建用戶行為路線

當然不是原型畫完了工作就結(jié)束了，在拿去評審或是交付給研發(fā)之前，要盡可能詳細地完成自檢。構(gòu)建用戶行為路線則是考慮好用戶使用產(chǎn)品不同界面的主要路徑。

如當用戶打開app后，新用戶在什么地方提示登錄，用戶在什么時候，什么樣的場景下先點擊什么，再點擊什么，在不同的頁面之間是如何跳轉(zhuǎn)完成任務(wù)的等等。

這里需要考慮的是用戶最頻繁也是日常的一個行為路徑，可以通過給用戶設(shè)想不同的情景下完成什么任務(wù)來構(gòu)建。構(gòu)建完成后可以自己先行走查，刪除不必要的元素，優(yōu)化重要的元素，使得用戶的主要任務(wù)行為路線是最為清晰且易記憶的。

注意用戶的行為也可能不是線性的過程，可能會在幾個頁面之間往返。

6. 通過場景驗證檢查設(shè)計

通過用戶行為路線調(diào)整了整個流程或框架，確保主要場景沒有問題后，可以將重心轉(zhuǎn)移到一些次的流程和場景之中，目的在于，找到原型或邏輯的漏洞，調(diào)整并優(yōu)化。

通�？梢愿鶕�(jù)以下四類主要的場景驗證

(1)路徑分岔點：指的是用戶對多種選擇時停留的位置。

用購物行為來舉個例子，你的用戶行為中，用戶是加入購物車，下訂單，付款等一整套流程，這個流程中，加入購物車，下訂單，付款都有分岔點，如用戶取消訂單，用戶放棄付款，這些行為背后的邏輯該是如何的?

(2)必要場景：指的一些必定會發(fā)生的，但又不常用的場景，比如清除緩存，注銷賬號等。雖然用戶會較少用到，但這部分的設(shè)計也是需要合理且易用的。因為用戶不經(jīng)常用到， 缺少對這種操作的學習過程，用戶可能會忘記如何操作。

(3)邊緣情景場景：也就是通常說的邊緣情況，這部分的問題測試同學會經(jīng)�？紤]到，但在測試之前應該考慮清楚對應的邏輯。比如昵稱重名，重復提交取消訂單，頻繁發(fā)送好友申請等等。

邊緣情景通常還需要考慮一個極限值問題，比如一天可以添加多少好友?達到好友上線后如何?

這部分需要特別關(guān)注，也許還需要向研發(fā)咨詢對應的代碼策略。

(4)特殊場景：通常不是用戶主觀造成的問題，比如app崩潰，網(wǎng)絡(luò)請求延遲，網(wǎng)頁404錯誤等情況。

嘗試著在畫原型之前多考慮這些步驟，畫原型應該是一個占時較少的過程，嘗試著在畫原型前更加系統(tǒng)地思考，這樣在評審會上才能更好占據(jù)主導權(quán)。

達內(nèi)時代科技集團致力于培養(yǎng)面向電信和金融領(lǐng)域Java、C++、C#/.Net、3G/Android、3G/IOS、PHP、嵌入式、軟件測試、UID、網(wǎng)絡(luò)營銷、網(wǎng)絡(luò)工程、會計、UED、web、Unity3D、大數(shù)據(jù)、童程童美等17大方向中高端軟件人才課程與少兒教育課程。選擇太原大數(shù)據(jù)培訓，不再孤軍奮戰(zhàn)，輕輕松松做IT高薪白領(lǐng)。