prototyping（原型）設計你做了嗎?

　　朱海成 教授於系統分析與設計--結合理論與實務應用 (電子書)提到資訊系統發展模式分為三大類：瀑布式(Waterfall)、漸增式(Incremental)、雛型式(Prototype)。雛型式(Prototype)意指先將系統使用者需求較明確的部份，或是資訊人員較有把握的部份，按照系統分析、系統設計、系統建置等大方向，在短時程內，快速地開發出來的簡單系統雛型。本篇針對雛型式(Prototype)之資訊系統發展模式說明其重要性與個人經驗與大家分享。

　　以自身專案經驗為例，在取得客戶提供的RFP後，就要進行大方向的需求釐清並著手進行系統功能盤點及整理列出功能清單。有了初步大架構後，再繼續衍生細項功能，並著手進行Prototype製作。Prototype製作技巧：

1. 用灰階稿取代彩色稿：比較不容易會有顏色的干擾效果，藉此觀察用戶是否「理解」產品。

2. 介面設計是引導，而不是選擇：大多的用戶在操作介面時是沒耐心的，通常會無意識下被介面引導，這是設計時需要謹慎思考的事情。

3. 不同的路徑相同的結局：一個 prototype 至少有 3~4 種行為路徑，但可以導向一個行為結果，會比較符合用戶真實的操作體驗。

　　看似簡單的Prototype涵蓋的需求層面其實非常廣，但往往容易讓人輕忽。包含了功能所需欄位、型態、操作動線、畫面呈現。製作過程中產生的相關問題，也將成為需求訪談的題材，透過和客戶確認後修改，修改後再次確認的反覆過程，此時的Prototype因客戶已有一定的熟悉度，也在開發前期看到日後交付測試的半成品，彼此間的鴻溝在訪談過程中已大大縮小並大幅降低前期專案風險。

　　你問我有沒有可能有製作Prototype但仍深陷專案失控風暴？答案當然是：有。Prototype可以想像成是樣品屋，初步完成隔間，並放入主要家具、電器用品。使用者可以先針對隔間、各用品擺放正確性做初步的確認，如果把馬桶放在客廳，使用者可以馬上看出問題，在前期就避免這個錯誤！但至於家具、電器用品要如何使用以及各用品間彼此的關連是如何，則要透過訪談過程中引導客戶提出細部需求及規則，釐清後寫入需求規格書，供系統分析人員做出貼近客戶需求的後續實作開發規劃。

　　曾經遇到過使用者因為之前專案廠商沒有用過Prototype跟他作需求確認，初次看到Prototype以為系統已開發完成，便要求我們實際登打案例並存檔給他看。現在聽起來大家一定覺得很不可思議，但這樣的例子真的常聽到，不願意在前期實作Prototype的廠商真的不少，只能說系統分析師的能力和溝通功力真的要非常深厚，才能保佑案子進行到UAT階段看到的和想像中沒有太大落差。

製作Prototype好用工具推薦：

• APP版

• WEB版

• 更多好用工具介紹可參考如下網址：

https://blog.akanelee.me/posts/260806-noteprototype-software/