01 | 團隊目標
建置醫學資料的檢索庫，包含前後台，提供符合使用者的操作習慣以及持續更新資料等關鍵需求。
02 | 角色與產出
與 PM 進行需求訪談後，我提出設計方案與視覺提案，定案後進行 UI 介面設計，包含前後台與 RWD；持續與工程師保持溝通，最後切版完成交付工程師。
03 | 專案挑戰
整理與掌握現有兩百多筆案例資料的內容架構與層級，載體從 PPT 轉移到網頁瀏覽，我們如何賦予良好的閱讀體驗？
04 | 專案成果與影響
如期完成系統建置，我們在第一階段上架全部兩百多筆案例資料，成功轉移並串聯現有的 PPT 檔案，使用者可在前台瀏覽與搜尋案例，亦可在後台更新以及維護資料，透過更有系統的管理來擴大資料的使用價值，並進行更廣泛與靈活的應用。
許多先天性心臟畸形及結構性異常，或因為罕見等造成診治困難，故需要具專門知識及技術才能拯救病患生命，尤其心臟疾病的診斷及治療日益新進，許多先天性症狀在臨床上減少，這也表示可參考的資源逐漸減少，故相關資料的保存與傳遞更為重要。
有鑒於此，台中童綜合醫院兒童心臟醫學中心的黃碧桃執行長，行醫近五十年、累積上百則相關研究案例，想將這些現有資料（PPT 形式） 製作成網站教材，供有興趣的醫師與相關醫事人員參閱學習，發揮資料的價值，受益於醫界。
前台
後台
1
了解使用者需求
與 PM 進行需求訪談，了解客戶關鍵需求，定義專案範圍與目標。
2
發想解決方案
針對客戶需求提出適合解決方案，同時設計整體風格，在解決方法上達成與客戶與工程隊的共識。
3
設計執行
確定解決方案後進行介面的 UI 設計與切版。
4
工程交付
將切版後的靜態網站交付工程師，並協助最後的系統測試。
透過需求訪談，我整理出系統會有的兩種主要使用者 : 案例提供者以及案例閱覽者。
How Might We...
使用者可以快速地找到特定案例，或是有關聯的其他案例，並確認其內容是否符合所需。
使用者可以清楚且快速的閱覽特定單一教案的內容，了解其大綱，獲取所需資料內容。
呈現清晰的網站架構，簡化階層，在流程設計上要讓使用者容易回到案例列表頁，且確保導航清楚明顯。
給予每個案例關鍵字
透過關鍵字串聯相關的案例，將這些原本獨立的案例連結成更全面的知識網絡。
良好的閱讀體驗
案例的閱讀載體從原本的 PPT 轉移到網頁，我們如何提供好的閱讀體驗 ?
提案一
解構原有的 PPT 資訊架構，區分層級，呈現於側邊導航欄。
提案二
ppt 線上閱讀器
設計決策
最後選擇提案二，主要原因有:
1. 每個案例的階層與內容並不一致，差異性大，會造成側邊選單的層級與標題不一致。
2. 承上，在後台維護與新增案例時亦容易造成混淆，也不易定義欄位。
3. 考量到主要使用者之一 : 案例提供者的操作習慣，維持 ppt 的載體可降低學習曲線。
提案一
提案二
提案三
最後選擇提案三的風格，並經歷三次設計迭代優化:
第一版
第二版
第三版
視覺準則
因為網站內容與醫學相關，希望網站給人的感覺呈現的是專業、沉穩但不死板嚴肅的視覺氛圍。
資訊架構上清晰不複雜，不會有過多階層，讓使用者在查閱相關案例時可以快速取得所需內容。
不採用過多的圓角，避免讓人有過於活潑而有失專業感。
設計系統
成果一
上架兩百個以上的案例至網站，建構清晰的資訊架構，提供醫療人員完整檢索。
成果二
新增模糊搜尋功能，更快更準確的查詢案例。
成果三
新增站內留言機制，對於案例有疑問或建議可以反饋給管理者，建立雙向互動，讓案例資料即時更新。
與專案經理（Cherry）
在原本的專案開發流程中，是由專案經理與客戶進行需求訪談，但這個專案遇到需求遲遲無法確定的情況，我主動提出與專案經理一起進行跟客戶的需求訪談，在經主管同意後，我開始協助專案經理一起進行會議的主持直到需求定案。這個合作的過程中，我理解到雖然之前我提供了畫面讓專案經理呈現給客戶，但非設計當事者的她在與客戶的表達上仍覺得吃力。於是我負責了在會議上向客戶展示模擬介面，說明設計用意、操作功能與流程。並提供技術面的建議與想法，協助專案的推動。
與工程師（Sten）
這是我第一個同時負責前台與後台的專案，為了確保前後台欄位的串聯、資訊架構的規劃，以及技術的可行性，我在每個階段持續與工程師保持溝通。
設計前期 : 這是確認設計方案是否解決核心需求的階段，在這裡我如果不確定技術可行性，會與工程師進一步詢問跟討論。
設計中期 : 在產出 Wireframe 後，會再與工程師簡單約個討論，確認頁面或資料結構設計，同時讓工程師對資料來源、頁面間的因果關係有更清楚的了解。
設計表達
實際與客戶訪談確認其需求，讓我理解如何透過 Prototype 等原型來確認需求以及設計表達，提供不同提案來與客戶確認功能。
核心需求是甚麼?
客戶所提出的需求很有可能不是核心需求，而是帶著預先設想的解決方法，希望我們幫他實現，起初會誤以為這個解決方法即是需求本身。 如何透過提問、設計思考來釐清使用者需求，可以避免無用的設計。
小心不要陷入「知識的詛咒」
專案前期與客戶溝通花了很多時間，後來發現雙方對於專案的進程與 prototype 的操作有很大的落差。 因此後來改用同步線上會議的方式溝通，實際操作 prototype 講解以及開發流程等，才順利地繼續推動專案前進。這讓我提醒自己避免陷入知識的詛咒，保持開放的心態，持續確認與溝通至關重要。
✤ 謝謝你的觀看 ✤