文字紀錄 / 穎軒
講者背景介紹
Ivy的經歷很特別，畢業於成大工業設計系，擔任兩年工業設計師後發現自己志不在此，便選擇出國繼續深造，到喬治亞理工學院修習HCI，並在亞特蘭大執行HCI相關的工作。在公司經歷了金融風暴後，Ivy自願離職，並得到公司的支持回到學校取得MBA碩士學位，接著便回到台灣進入趨勢科技直到現在。
容許多方嘗試的企業文化
Ivy一開始在趨勢的HIE部門也是負責UI設計，後來成為組長及Design Manager，目前則是擔任Project Manager的工作。趨勢科技的文化是較為自由的，容許職位的更動和自主的調整，若是想要多方嘗試其他角色的職務，公司皆會適時給予機會。Project Manager隸屬於RD部門，裡面主要的成員包含RD、 QA和Architect等較偏技術專業的人員。在這樣的部門可以認識到他們是如何以不一樣的角度去思考產品，也可以了解到他們對於設計師的看法。
企業型軟體相關經驗人才的斷層
和一般開發消費型產品的科技公司不同，趨勢科技的產品主要是針對企業型用戶，對於這樣的目標族群，設計師需要更多的經驗和方法，才能達到更精準的用戶體驗設計目標。而現在熟悉企業型用戶的設計師或是研究人員較少，在公司招募新人時往往找不到有相關經驗的人才。這可能是台灣目前產業類別造成的影響，台灣規模較大的軟體公司本就不多，而針對企業型用戶的又更少了。因此本次的演講會分享企業型軟體的開發經驗和方法，並從設計師的角度去探討在開發這類型產品時需具備的觀念。
今天Ivy將以PM的角度，並從下列三個面向來分享過往經歷，探討設計師如何優化產品的用戶體驗：
USER 什麼是使用者
DESIGNER 設計師的核心價值
PROJECT 設計師如何和開發團隊合作
1. USER 什麼是使用者
設計師不等於使用者
在產品開發的過程中，設計師是最接近使用者的，往往會擔任使用者的代言人，去和開發人員溝通用戶想法，但應該注意的一點是，設計師畢竟還是設計師，並不能完全代表使用者，尤其對於企業型產品的設計更是如此。因為這些產品通常是為了特定工作需求所開發出來的，設計師本身可能並沒有使用這種產品的經驗，使用者是特定領域的技術人員，設計師必須付出非常多時間才有可能較為熟悉這樣的對象。設計師自己本身的假設不能代表使用者真正的需求，而是要配合使用者研究的調研結果去做分析，並一定要在產出原型後經過驗證。此設計流程能提升設計結果的可信度，也可避免後續產生更多的開發成本。設計師必須很密切的與使用者接觸，才能更深入的了解他們的工作內容，通常一週一次會是最理想的接觸頻率。
產品的驗證
企業型軟體的用戶是較不易接觸到的族群，因此用戶研究者一定要有自己的口袋名單，並能快速地反覆驗證正在開發中的產品。多利用自己能取得的各方資源，並且發揮設計師的特長去做用戶研究，情況允許的話，還可以帶著RD或PM一起進行。要找到關鍵性的Key Person，才較有機會有力地推動想法；也可以試著建立能夠一起進行用戶研究的團隊，將UX的概念直接帶入團隊當中，大家一起親身參與、面對使用者，會比單方面的說服和轉述更有強度。
對於自己不熟悉的領域，如何挖掘UX的核心價值？
對不熟悉的領域做用戶研究本身就已經比較困難，可能要經過多次的訪談才能對該領域的知識有足夠深入的了解，此時設計師容易犯下的錯誤就是，把用戶的要求原封不動當成了產品的核心目標，直接把用戶所提出的要求和意見當成解決方案。為了避免這種情況的發生，就要更深入去問「為什麼」而不是「要什麼」，去挖掘背後的真正動機和目的，往往要在問了五個「為什麼」之後才能達到問題的核心。
2. Designer設計師的核心價值
User Experience應該是一間公司整體的文化，而不是單一職務負責的事情。
許多人會自動把User Experience這頂帽子往自己頭上戴，但這樣的風險非常大，因為UX的範圍實在是太大了，要考慮的面向和因素都是非常複雜的，有時候UX和UI甚至是完全沒有關係的，所以設計師在用到UX這個詞的時候要更加小心。可以自發性地去執行，在自己的設計中帶入UX的觀念，但不用刻意提出自己在做的是UX。
若要在公司中建立UX文化，由上到下的方式是最有效率的，由領導階層的人開始推行、引領模仿，慢慢將使用者中心的觀念內化，較能快速地塑造文化。
溝通的重要性
溝通能力及對人的關懷是設計師必須具備的特質，這也是企業在找設計師的時候會特別關注的。此外，對於在跨國企業工作的設計師，英文能力的培養也非常重要，良好的語文能力可促進工作中與不同角色間的溝通協調。
確實的UCD Process
由於工作排程可能很趕，在時間不足的情況下，許多設計師會忽略UCD Process中驗證的部分，而只停留在設計的階段。驗證是一個需要不斷循環的流程，是產品開發中非常重要的步驟，因此設計師需要儘可能地和Project Team溝通，大家要有共識並對專案排程有所了解，在專案一開始就要將驗證流程考慮進去、規劃預留時間，在完成初步設計方案時一起進行驗證。
過去會以Water flow的方式去進行驗證，等到產品已經接近開發完成階段才去執行一個很正式的驗證，工作時程的安排是將時間做大塊狀的切割。而現在Ivy比較偏向採用更敏捷即時的方式，將工作階段分成較細小的段落，在每個段落都會去做驗證，且設計師執行驗證必須跑在段落之前。敏捷式的開發流程雖然被詬病太過零碎，但Ivy認為要看狀況去做調整，大方向的擬定是必須在流程初始階段和每個季度就訂好的，並不會影響整體的UX核心價值。
3. PROJECT 設計師如何和開發團隊合作
設計v.s.開發的距離比你想像得小
設計師和開發人員的距離其實比設計師和使用者的距離還要來得小，兩者之間應該是合作夥伴的關係，因為是為了共同的目標在做事，設計師可以發揮自己溝通協調的能力與開發人員交換想法。
和他們坐在一起
距離和空間的影響因素很大，目前趨勢的HIE部門和產品開發部門在不同的樓層，溝通上就會形成斷層，錯失很多討論的機會，也會花費更多時間在傳遞訊息。組織並不是說變動就能變動，但設計師可以試著融入開發團隊，例如規畫特定時間去坐在開發團隊旁邊，增加與他們的互動和溝通，但自己還是隸屬於原本的HIE團隊，因此依然有團隊在背後的支持和歸屬感，也不會影響設計師的發展。也可以一起參加公司內部的活動，此外，互相了解與鼓勵等正面的相處模式也是很有助益的。
擁抱改變
面對並接受它，不斷的變動和調整是一定會發生的，但若改變會讓產品更臻完善，能避免後續更大的損失，那麼執行是必然也是必要的。
