企業系統的開發過程中，End User 是資訊系統需求的最主要提供者以及系統的使用人。
如何了解使用者的需求以及系統是否合用，是資訊部門相當重要的一個課題。

唯有滿意的使用者，才有所謂好用的系統。進而才能有提昇工作效率的實際意義。
要怎麼知道使用者心理在想什麼？當然，直接面對面溝通是一種方式，但每個人表達能力或思考的方式不同，你所獲得或接收到的回饋，可能與事實有一段差距，或者詢問的方式或理解的方式，讓雙方的溝通有隔閡，突然增加許多時間成本，若使用者的涵蓋層面大的時候，面對面的訪談又不見得能夠實施。

這時候，不妨設計一份問卷來協助你蒐集資訊、讓使用者的意見能夠確實的表達。

當然你會說，使用者忙都忙死了，哪還有時間理你！

如果是這樣，那麼是不是大家都不要提需求了？還是您只是在幫自己找藉口？

對的事情，做，就對了

怎麼樣把事情做對，才是我們要去思考的問題。

現在有很多很好又方便的問卷設計工具，不要再幫自己找問卷難設計的藉口。Google Doc 方便使用、樣式多元，又能統計結果，在邁向 Web 3.0 的時代，Web Apps 已經取代掉傳統應用程式的思維，不用凡事都自己動手，而是要學會怎麼去運用它。

今天，不是要教大家怎麼設計問卷，而是在什麼時機運用什麼樣的問卷。

我們以一個系統平台轉換為例，並將專案的過程簡單區分為：專案萌芽期、專案耕耘期以及專案成熟期三個階段，來討論可以怎麼設計問卷。

專案萌芽期

萬事起頭難，平常大家老是抱怨系統哪裡不好用，哪裡有欠缺，可是要他們講哪裡不好用，哪裡有欠缺，又好像說不出來，想了半天，最後總是一句：總之都不好用啦，這不是我要的菜！

這個階段，我們問卷設計的重點在於，怎麼樣了解使用者的想法以及想要解決的問題。

例如，我們將平常與使用者互動的過程中所了解的問題，大致區分為操作介面、系統功能、執行速度等層面，在每個部分去設計我們想要知道使用者偏好的項目，以及系統有哪些功能上的限制，藉由給分的方式來顯示使用者看待問題的重要性，同時搭配開放式的意見提供，可以知道更多使用者的期望。

很重要的一點是，要將問卷調查的結果，公布給使用者知道，並提供初步的解答與規劃方向，當愈多人願意回答時，並且問題都能認真的被看待與處理，這就會造成一股風氣，大家就更願意提供建議與提出想法，整體就會往一個好的方向前進。

以前我也認為做這些沒用，但真正跨出去之後，我只能告訴你：傑克，這真是太神奇了。

專案耕耘期

有了使用者的意見反饋後，我們在產品的 Survey 上就有依據，知道哪些產品可以符合我們最大範圍的功能需求，你的工作是幫使用者（公司）找對廠商，除了廠商來進行產品介紹外，書面的資料大都經過美化，看實際的 Demo，實際的操作才會有感覺。

這時候，可以在公司內部挑選幾個較具代表性的使用者，一同參與廠商的評選，讓他們實際看 Demo，可以實際操作系統更好。使用者有了這些經驗後，我們就可以設計一份產品評選的問卷，來蒐集使用者使用經驗的意見調查，以作為我們評選廠商的依據。

例如，就功能面，各項功能是否能滿足需求？請使用者給予廠商/產品評分，以及他們使用此產品的意願。這點很重要，當然我們不是讓使用者來畫押，而是讓他們可以認真去看待產品，畢竟他們才是真正的使用者。

專案成熟期

專案好不容易完成了，終於鬆了一口氣，但真的結束了嗎？上線才是專案奮戰的開始。因為使用者實際使用系統後，才會真正發掘問題，真正提出意見。這個時間點，問卷的重點在於滿意度調查，而且最好能夠三個月、半年或一年就做一次滿意度調查，這樣才能真正知道，系統的運作狀況以及的成效，作為日後專案規劃與執行的參考。

例如，當初我們所規劃以及答應使用者要達到的功能，目前使用者使用的滿意度如何？是否有達到原先的期望？可以再做怎麼樣的改善？而我們可以就使用者的反應，擬定改善計畫的方案以及目標。

說到這邊，是不是我們又可以套用到 CAPDCA 的階段？這樣專案進行起來是不是就有條不紊，也很容易上軌道。

全系列文章列表