使用者與網站設計開發的關係

雖然透過上一小結的研究結果可以知道，台灣網路產業的網站設計方法與團隊分工 並不符合使用者中心設計取向的特徵，但為了可以進一步瞭解，他們通常是如何進 行使用者考慮及會考慮哪些事情，因此將在這個小節作相關研究發現的整理與分析。

一、如何在設計開發過程中考慮使用者

本研究發現使用者對不同的人或公司來說，可能代表不一樣的事情，而當使用 者指涉的是一個可以直接互動對象時（例如幫客戶架設網站或內部網路平台等），

受訪者及其公司會比較傾向與他們在合作過程中積極互動，來收集明確有用資訊，

也相較會依賴他們作為主要的資料來源，自己反而不會直接去關注太多使用者考 慮。但如果面臨的使用者是模糊不可知的一般使用者，考慮的重心往往會迴歸到公 司的產品特性、目標，甚至是公司的文化面或受訪者自己對使用者的重視度上。也 就是說使用者的意涵不同，會影響他們進行使用者研究或考慮所採行的策略，而至 於實際上在網站設計開發會進行那些活動來考慮，或透過什麼樣的方法來收集有用 的參考資訊，則可以進一步整理如下圖所示（詳見圖表 4-5）。

這個示意圖是根據本研究所收集到的資料進行整理分析所歸納出來的，中間軸 線代表的是研究對象及其任職公司的開發流程，從上而下分別是指開發流程的初始 規劃到完成上線的各階段之考慮或瞭解使用者的相關設計活動，上面三個為企劃階 段，包括了：透過客服的「使用者意見」；各種「前置資料收集」，如行銷業務資 料、市場研究分析報告、與團隊（包括客戶）討論；及依據公司的目標、策略將這 些資訊做為參考來進行「最佳猜測（best guess）」，以想像出可能的目標族群需求 與評估可能帶來的契機等。另外在設計開發階段，少數受訪者提到其公司會透過「原 型法」進行確認；或是以擬定測試計畫的方式，透過層層把關的內部「反覆測試

（debug）」程序來確保網站品質；或等到產品幾近完成的時候進行「使用者測試」，

但測試的對象有可能是便利樣本，及根據目標族群的描述去實際募集外面符合的使 用者來進行。不過有更多的受訪者表示其公司會先跳過這些步驟，而認為一切等網 站完成「上線再說」。

在左右兩欄，則分別是在之前的資料分析時已經說明過的—目前台灣業者進行 其設計開發工作時最主要依賴的方法—包括其自身與團隊的各種經驗之累積。在「團 隊方面」，例如參考前人或別人的設計、專案檢討、專責分工或設置檢核點及透過 組織分層的把關等；而在設「計開發者自身」則有過去的經驗（設計上或使用上的）、

自我進修、與朋友同事交流、錯誤中學習或採取便利樣本來提供相對客觀的意見等。

以下將引用研究對象的敘述來作進一步的闡明。

例如設置 interaction design er 協助 p roducer 進行網站介面設計

Prototype

有些公司會透過 protoype 進行 溝通、測試與確認

反覆測試

有些公司會透各種測試把關與 QA 來提升網站品質

Best guess

根據搜集到的資訊及公司目 些公司會進行 usability test

上線再說

另外，從訪談中可以發現大多受訪者的公司雖然都會在開發前期進行各種資 訊收集，但這些大多還是從自己的產品特性、市場脈動觀察，或以其他現成的統 計調查數據為基礎進行推測。而作這些資料的分析，主要的目地除了是協助公司 評估可能的市場規模來做出決策外，也是為了給後續實際進行網站設計規劃時的 考慮與參考之用。

「它[指使用者研究]不會變成一個獨立的項目，它通常會變成Market Survey 中的一塊。就是目前為止，能夠去做的都還是市場的調查，然後從這邊去訂 出原則，去決定所謂的Guidelines，然後去完成∼去依照這樣的Guidelines 去進行這樣的規劃，以及上線之後的調整。」（F01）

「我們會先去看一下，就是現在市場上的兒童網站大都是怎樣的設計風 格…」（F07）

「其實應該動腦會議前，…∼就是∼可能各自會自己去蒐集一些資料，或者 是多觀摩一些網站。」（F02）

「比如說∼恩，Marketing或Sales∼或像我們這樣子PM的人，發現一個東 西，然後他去寫一個企劃∼一個產品開發計畫，…Present之後，大家覺得應 該有錢賺，然後就開始作了。」（M03）

「像我們老闆他是∼必須經常接觸很多不同的團體，然後他自己在網路∼就

∼就∼很多訊息的人，那∼你就會不斷的接收到很多新東西，然後你趕快瞭 解、然後∼去看…我覺的坊間應該都是這樣吧。大概都是說我感到大家都在 ㄏㄤ這東西，我趕快去作∼」（F06）

其中少數公司或許會參考公司行銷資料的既有使用者之人口變項等內容，定 出網站的目標族群，可是也僅止於此，對於如何設計出符合這些人需求的網站，

主要還是憑藉團隊成員的經驗與討論，來做出最佳的猜測。

「我們有買很多行銷資料∼資料庫，…比方說你要找網際網路的使用習慣

∼」（M05）

「會有一些描述，一個∼一個目標使用者的描述，比如說假設我現在要作一 個交友網站，我可能覺得∼會預設這些使用者是男性啦、未婚啦、18~22歲 啦，這樣子一個社經地位的描述，that’s all。」（M03）

「那是還沒有成型∼還沒有具體成型的∼發想，可能大家天馬行空∼亂想的 階段∼有需求，可能很多東西還不太確定，比方說風格阿、哪些人會用這些 東西阿，需要確認我們的使用者有哪些…」（F02）

「我們的方式是說∼比如說我們的target是青少年，那我們不是說是先去想 要提供什麼服務給他，而是先考慮說∼有點像mind mapping那種畫法∼就是 說一群人就是關在一個房間裡面，然後沒想出來就不能出去就對了。」（M01）

「說實在∼ㄟ這行實在是太辛苦了，錢也不多，我意思是你真正generate出 來的revenue不多，他又不像作廣告可以什麼target什麼focus group，然後 要幹嘛∼事實上∼我們大部分就是平常自己∼企劃[通常是一個專案的主要

planner]就要自己去 collect很多人的意見，到市場上去問人家阿；去看產品

啦∼幾乎變成是∼就看你自己的誠意了，你隨時間都要 prepare 你自己。」

（F05）

而在開始進行設計開發之後，也只有少數的公司會透過原型（prototype），

由開發成員、主管或行銷業務人員來進行先驗，甚至更進一步在這個階段或稍後 的成品找來使用者進行測試，但這些其實都受制於公司的資源與時間、人力，一 般都不是開發過程必須或絕對要進行的工作。

「Prototype會針對我當初design的部分∼可能有些技術上的盲點…可能技術 最困難的、他會影響到整個成功關鍵的…這個prototype之後呢，還是一樣回

到review board，去決定說這個東西還可不可以繼續作…我如果已經有

buyer[指銷售代理商]的話，我先確保我開發出來的是符合他們要的。」（F05）

「paper prototype比較少作，honestly真的比較少作，但是我們在wireframe 的階段可能會作這些測試…可能在 visual mockup 的時候可能會作 usability test…」（M04）

「每一個專案不見得都會有user research這樣子的一個研究∼研究動作，那 要考量的是說，在人力允許的狀況之下，我們會∼或是針對某些必要的產品 對他去作一些有關使用者經驗，或是usability部分的研究。」（M04）

通常公司比較依賴傳統的除錯測試（debug）流程，進行網站品質的把關（是 由開發團隊與公司其他部門人員，而比較少是找真正的使用者來測試），

「反覆的做測試…就是Planning的人要去做這樣的規劃，然後他們自己要去 做反覆的測試…那技術部門的人會去做正確性的測試，上線前測式的時候就 會開放給其他部門去做∼以使用者的角度去做這樣的測試。」（F01）

但多數受訪者表示其公司的測試階段並非有正式固定的流程，通常也不會為 這些測試活動制訂明確的審核與把關標準，而且在求趕上 deadline 的前提下，往 往會進行取捨，先求功能或內容運作不要發生錯誤，而對於一些被認為是影響程 度小的如操作合理性或介面使用性順暢的問題，則會先被擱置，

「那個 的過程是在開發的過程就一直在做的，所以到要上線的時候就

「我們製作團隊會先測…然後再內部announce，然後在大家一起測…測試應 該需要一天吧…」（F07）

「如果會影響到服務的進行的話，可能就沒有辦法上線，如果是一些∼小問 題，機率小的、不會直接影響到功能的∼可能像使用者碰到時會沒那麼順，

但還是可以用…對，配合時程，如果時間緊迫的話，可能容忍度會高一點。」

（F01）

「像我們整理user feedback的部分會分為兩大塊，第一個我們會整裡正確 性，那第二個是合理性…一般來講就是說∼或者是等到∼ㄟ或者是說，比較 閒∼比較有空的時候。…對品質當然是製作是時間越長越好（慢工出細活）；

市場反應當然是製作時間越短越好（發現商機 立刻推出商品）…[因此]常常 會牽涉到一個就是當你的品質與市場反應的能力有衝突的時候，其實這個往 往到最後∼是沒有辦法被兩全的。」（M01）

當然也有受訪者表示這些難以有定論的意見，會等到上線之後根據使用者的 反應再做定奪，

「其實∼很多問題其實都是上線之後才會發生。所以我們一般都會去抓，上 線之後一個月去作一次整體的review，那這個review來的回應就會更直接。」

（M01）

「因為∼通常你要作一個網站的話，你是有迫切性的需求，急切的需求才會 去作…所以一開始還是會以∼針對這個project的需求去作出來，然後再慢慢 接收到一些feedback，再做調整。」（M06）

「因為∼通常你要作一個網站的話，你是有迫切性的需求，急切的需求才會 去作…所以一開始還是會以∼針對這個project的需求去作出來，然後再慢慢 接收到一些feedback，再做調整。」（M06）