dosomething 觀察室：從金點獎專案，聚焦設計服務的不同面向
這篇文章從何而來，又有何可看之處？
金點獎這個十幾來歲的設計獎項，在業界有著一定的份量，但一直以來，線上報名的入口處是很分散的，評分也以紙本進行。所以，在 2019 年的今天， dosomething 承接了「金點獎・參賽與評選系統」的任務，將制度與流程數位化。同時，從這個超過一季的專案過程中，梳理出 dosomething 的設計觀點，並透過這篇文章，分享給大家。
但有些前題，還是得先說明說明。一來是，筆者沒有參與該專案，大多只能從第三者的角度，去釐出事後觀點。二來是，在諸多現實面的考量下， dosomething 的設計專業，多少有無法納入本案之處、也非事事如理論值般的完美無瑕，所以透過本文，去留下專案與技術層面之外的觀點，期望往後在相似量級的案型中，得以展開更縝密的討論。
p.s. 金點獎是什麼？
金點設計獎有針對不同的設計族群，落出分眾的獎項。對台灣設計圈的學生而言，或許不見得知道「金點獎」，但若提到「新一代」，那聽過的人可能就多了，誇張點的視 <新一代設計展> 為設計相關科系，畢製 AAA 級戰區也不為過。而新一代的獎項，便是金點設計獎的項目之一。
（備註：2015 年起的新一代設計競賽，已改為「金點新秀設計獎」，詳情可參考這份連結的資訊，文中以簡稱代之）
換言之，金點旗下有多座獎項的報名與評分機制，需要透過本專案，做一回通盤的整合。
咦，為何 dosomething 有扛下這項任務的能力？
提出這個問題的前提，必須先瞭解這項任務的本質，與此同時，才能更通透的認清對應解法，與應該具備的能力。
為釐清任務本質，本文會先透過下方的第 1 階段，帶領讀者一步步聚焦，最終會在第 3 階段，回答我們為何有承接這項任務的能力。
- 專案需求：整理成三大項目
- 從三大需求去理解本質，去掌握它的核心到底為何？
- 聚焦出核心後，來討論解法
Stage 1：專案需求
既然談到「線上」，或許你會想，那需求不就是個網站嗎？難怪會找 dosomething。這個答案不能算錯，但這麼簡要的擦邊球，並非是專案的核心。
我們先來談談，表-面-上 最～好理解的三大需求：
- 報名系統：使用者 → 想參賽的民眾，與外部單位
- 評審系統：使用者 → 主辦單位邀請來的評審
- 後台系統：使用者 → 主辦單位的管理之用
很明顯的，系統這個字眼，被再三點名了。那為何必須用「系統」這兩個字，和「網站」的意義差在哪呢？
是網站 / 系統 / 還是其他的什麼？？？
使用「網站」這個字眼不算錯，就是過於籠統。在多方溝通時，容易產生認知上的落差，而認知一旦失焦，就會產生驚天地泣鬼神的結果。
你們心想，都這個年代了，哪需要你解釋網站的字義啊。好，以下舉個浮誇點的例子：
甲方心想的網站，或許是…包山包海，搞定上架、金流、結帳功能，通通說是網站，都-對-。換言之淘寶、PChome、露拍都是網站。但同時，乙方心想，誒不是吧！原本理解的是，就上些美麗怡人的商品照功能，就水水地陳列照片，怎麼會說乙方沒做到淘寶等級的功能呢？
因為前後兩者，都被籠統地稱作網站，然而淘寶跟線上 Lookbook 的量級差距，這麻瓜也知道。
所以，以 <金點獎> 這類層級的案型來說，使用網站這個字眼溝通，會因失準，而產生不必要的成本。這也是為何，上方陳述的 3 個需求，會以「系統」一詞去指稱的原因，因為這樣才能涵蓋一連串的報名步驟，抑或是評分 機制的需求。簡言之，團隊能釐清任務需求，有著許多層面的意義，而這也是我們所在乎的。
Q: 喔～所以這不是網站，有系統功能的需求，那就是「系統案」囉?A: 哎，還是不太對。Q: 那倒底是 ???（以上對話，是筆者在追蹤、釐清專案的途中，所產生的疑問。）
Stage 2 : 任務核心
Q: 明明是３個系統需求，又怎麼不能說是「系統案」呢？
A: 因為這些系統，最終會架構出「一個產品」喔～!!!
（套回到上一段，在談「淘寶、PChome、露拍」的舉例，就說得通了。
那不僅只是系統，而是叫「產品」）
首先來解釋解釋層級，「產品」是啥，與「系統」的差距在哪？
按理說，系統完成後，只要工程師能理解、會操作，大概就萬事如意了。然而，在「產品」這個概念中，就需要意識到「使用者」的存在; 這裏所說的系統呢，則是滿足「使用者需求」的工具。
好，有人眼神渙散了。以下舉例：
以外賣系統來說：產品名：
APP 如 Food PＯＯda, UＯＯr Eats使用者：
不想出門，但又很餓的人類，想透過這個產品，來點些食物使用者情境：
1. 某人拿著手機，打開 UＯＯr Eats 的 APP
2. 開始點餐、選送餐地址，拿出信用卡付帳
3. 外送員送餐到家門口
4. 拿到食物後，發現，什麼！少給了一顆肉粽！
可是，都刷卡結完帳單了，該怎麼辦～～～
透過上述的模擬情境，我們可以想見，從產品角度來說，它需要經得起成千上萬人的操作。所以，理想情境是，使用者無需他人解說、也不用具備特殊知識，就能自在順暢的使用這套產品。
換言之，設計團隊對「產品的使用情境」，有越深刻的見解，就越能獲得正面的情緒回饋。
再代換回金點獎一案，就可以理解到， dosomething 其實是在開發一款產品，讓參賽者、評審與主辦單位三種角色，都能自在使用這套工具，譬如操作介面的引導，碰到問題時，能立即獲得一個說明、一句短短的提醒，去消除使用上的不愉快。
當然，設計團隊沒有讀心術，很難設想得到 100% 的使用者情境。以 APP 這種產品來說，即便是大獲好評的 APP，也常常會透過更新，去補足、照顧到先前疏忽掉的一些使用情境。
所以，問題就會落到，團隊該如何以設計，營造更細膩的使用者情境呢？
Stage 3 : 切題的解法
以金點獎為例，dosomething 從數位產品的設計經驗出發，去試想三種角色…我是參賽者、是評審、又或是主辦單位的使用情境。但更有效率的來說，也可透過觀察、訪談這 3 種角色，直接藉由對話建構使用者情境。
如此一來，就有機會向需求面靠攏，設計出更貼近人心的工具，去優化使用者的體驗。上述的這些，便是落在 「顧客體驗」的層級，換言之：
在產品開發的思維下，「顧客旅程」是設計的一大重點
這裏，讓我們有請雙鑽石模型，來帶出較詳盡的步驟。
延續著參賽者＋評審＋主辦單位，將三者的角度，帶入模型中討論：1. 發散：創造一個使用情境，去同理思考，如果是使用者，會有哪些需求？2. 收斂：定義問題後，建立出一套，比需求還更精準的「洞見」。3. 再度發散：如何透過設計，去回應洞見，讓使用者能順暢的操作。4. 逐步收斂：
4–1 | 製作原型（prototype）－ 因為在解決未知的問題，所以採用小規模的模擬，去反覆考量設計的可行性。
4–2 | 測試－即便經過了原型階段，在現實世界上場後，免不了有些疏忽、或超出預期之處。此時，可能回在拉回第一階段，再次的逐步修正下來。
在近年的設計思維中，可以從 User Experience 的角度，來提出顧客旅程的設計。但本質上，不論是線上的、還是實體世界中的，都有一份對使用者的照顧，也是 dosomething 所設定的服務品質。
只不過，理論模型歸模型，實際開發一款產品時，總有出人預料之處。最後會發現，以產品專案來說，技術點恐怕不是最難的，反倒是仰賴…
雙方良好的溝通品質，與細膩的流程設計，就像是在編導一齣劇本、或一篇漫畫的分鏡，在構思劇情時，找到貼近人性的合理之處。
文末快速總結
筆者從理解金點獎這項專案的途中，所觀察到的要點，可歸納成下列 3 點：
- 從客戶需求，掌握產出的設計，是歸屬於「那一類」的設計本質？
- 理解本質後，才能以切題的「設計服務」評估，並回應客戶的需求
- 切中要害的設計 ＋ 客戶背後的種種種種考量 ＝歷經討論、權衡後，落下最終的設計解法 ( 辛苦大家了… )
白話來說：
這個「釐清任務本質」的步驟，會對應到不同成本、溝通、管理等層面，這些都是設計服務中，會產生的隱性項目，而不只是「視覺產出」這麼單純的事，不可不慎吶～
所以，下回甲方說：我想做一個「網站」～ 具有設計專業的乙方，就得從需求面一步步切入評估，去理解它是要個系統、抑或是個產品，再進行後續的設計作業。
以上，倘若有檢核到這些要點，或許設計團隊，也具有朝產品開發來挑戰的能耐。
在這篇文章的最後，要特別感謝：台灣創意中心（TDC）金點團隊的耐心與信任
讓我們有機會協助改版，台灣重要的設計比賽系統還有耐心閱讀至此的各位～
