大家都知道，在入門時想要提升 UX 研究、設計能力的話，實際練習必不可少，但各個實作機會常常具備著不同的團隊組成以及專案目標，而不同類型的專案會學到的東西其實不太一樣！經歷過不同的團隊組成、專案類型，以及數份實習經歷後，以下是我認為在學生時期，每個不同類型的實作機會具備的差異，希望有助於大家了解自己當下最需要什麼類型的專案實作經驗哦！( ´ ▽ ` )ﾉ
內容分為上下篇，上篇將會說說 Side project 有無開發實作需求的差異，下篇則會分享實習 vs side project 的不同學習點。
文章中描述的專案以我個人經驗、學生時期接觸到的為主。我曾經嘗試過各種實作經驗，包含自己入門練習的個人專案、被工程師邀請的 side project／黑客松、主要和設計師合作的設計競賽、跨領域團隊角色的商業競賽等。而實習的部分，過去都是在新創文化的小團隊中實習，公司員工不超過 100 人，並且都是做公司自己的產品、會參與到現有產品的主要開發流程。
各種實作機會沒有孰優孰劣的區隔，而是透過不同的過程、環境，可以幫助提升自己不同面向的能力。如果各方面條件允許的話，我認為如果能夠各種不同實作經驗都具備是最好的！
有開發實作需求
一、可以了解如何和工程師溝通
若設計專案有開發實作需求，最大的優點就是能夠練習如何和工程師溝通，並從他們的角度思考。從他們提出的問題以及需求，可以去了解在實現設計稿的過程中他們在乎些什麼。舉例來說，剛開始練習設計 UI 的時候，很容易只做到最理想狀態的頁面呈現方式。以搜尋頁面為例，最理想的狀態就是用戶輸入關鍵字，而搜尋結果出現和關鍵字有關的內容。但其實光是這一個頁面，就會有其他的不同狀態會出現，例如找不到相關搜尋結果時，該怎麼呈現？又或者是，用戶為離線狀態時，要呈現什麼給用戶呢？這些都是實作上非常重要，但若沒有和工程對接，初期入門時便很容易漏掉的部分。
二、不斷練習產出更高保真的成果
為了要幫助工程師更具體地理解自己想要表達的意思、頁面間的關係、預期達到的效果等，因此會逐漸練習產出更高保真的成果，來確保設計師和工程師之間的理解一致。例如當要解釋一個頁面的動態效果時，有很多種不同的表達方式。從口頭描述、提供範本、製作動畫效果的 prototype，一直到實際提供具體的 CSS 數值等，前幾個可能需要雙方不斷地來回確認，而後幾個更有可能可以讓溝通過程一步到位。
三、對技術可行性以及開發成本差異有更多了解
在向工程師提出需求、詢問技術可行性時，依據他們的反應可以一次次的了解什麼需求對他們來說很麻煩，什麼其實還好。進而也促使自己在提出想法時，嘗試依據可能的開發成本分別提供數種不同的方案，說明什麼是具備最佳體驗的做法，而哪些環節可以依開發成本做出取捨、哪些部分有討論空間等。
此外，「有沒有和工程師意見不合的經驗？最後如何解決？」是我在幾乎每一次的面試都一定會被問到的問題，多一點和工程師合作的經驗，能夠讓人嘗試找到自己的一套方法。
四、提升抗壓性
因為團隊內很有可能只有自己一個設計師，且工程師的數量比設計師多的情況是常態，需要學會把一件可能沒有其他人懂的事情，解釋到其他人也可以理解。自己提出的設計見解、決策被質疑很常會發生，尤其是面對可能會增加開發成本的情況時，需要去更清楚地解釋這一個設計決策的價值、重要性。
五、學習更好地輸出 Spec，弭平認知落差
現在有許多工具可以幫助輸出 spec ，讓過程方便了許多，例如 Figma 或 Zeplin，但是設計稿到開發後的產出會有什麼樣的差距，真的是沒經歷過不會知道。經過一次次地協作、和工程師溝通，可以更加清楚地了解在交付設計稿時需要注意的細節。盡可能附上適當的註解及說明、多想一步，可以讓工程師對 spec 的理解和自己預期的畫面一致。要共同打造出心中理想的介面，需要顧慮非常多的眉眉角角，透過一次次的實作及溝通合作來學習，會讓設計 → 開發這個交付過程更為順暢。
整體而言，有開發實作需求的 side project 會充滿著較多限制、考驗不同職能角色的溝通及團隊合作能力。設計稿的用途在這樣的 project 中，更偏向「溝通工具」，各個階段的產出若要轉化為作品集中的內容，可能需要更多心力梳理及詮釋。但這樣的實作機會更可以了解真實業界的合作方式，幫助自己和職場接軌，設計稿開發後上線也能接觸到更多使用者，接受市場的考驗。
以上說了一些此類型設計專案的學習機會點，那它會有些什麼樣的限制呢？
一、設計稿是溝通的工具，不一定會做得很完整
在有開發實作需求加上時間限制的情況下，製作設計稿的重點並不在做出一張張美美的、完整的 畫面，而是「溝通」。只要是讓工程師理解你的想法、需求的方法都是好方法，若他需要的是頁面的 layout，即便 Wireframe 很粗糙、陽春，若能讓雙方的畫面是一致的，那就可行。（但前提是要真的確保雙方畫面一致，不是自己覺得可以就可以）如果有其他更加有效且快速的方式讓雙方有共識、且互相清楚地理解對方的想法，其實不需要去拘泥設計稿上的細節。例如一次參與黑客松的經驗，在緊迫的時間限制之下，由於介面的細節不是比賽要求的重點，我們在比賽當下只有產出 Wireframe ，然後讓前端工程師套用 Material Design 的元件，來呈現最後的作品。
這個特點會對應到，如果你想要在作品集中很好的呈現這一項作品，就會需要在事後花更多時間重新做完整的設計稿、梳理當時的設計過程。
二、專案時程很趕的話，使用者研究的時程可能會很有限 🙃
對於設計師來說，利用使用者研究的各種方法先了解用戶、市場現況是一件很自然的事情，但其他夥伴未必會有跟自己一樣的想法。加上開發其實需要很多時間，時程很有可能不允許團隊在前期投入太多的時間資源。這時便會需要練習如何權衡、如何採用比較精實的方法來達成研究的目標（這也是一門大學問！！）。
小結
整體而言，有開發實作需求的 side project 會：
- 充滿著較多限制、考驗不同職能角色的溝通及團隊合作能力。
- 設計稿的用途更偏向「溝通工具」，各個階段的產出若要轉化為作品集中的內容，可能需要更多心力梳理及詮釋。
- 可以了解真實業界的合作方式，幫助自己和職場接軌，設計稿開發後上線也能接觸到更多使用者，接受市場的考驗。
無開發實作需求
設計產出不需要實際開發出來的 side project，可能出現於提案內容不需實際上線的設計競賽、商業競賽、最開始練習實作時的個人小專案等或者是專案目標以學習為主，由一群設計師、研究員組成團隊，合作進行需求研究、解法發想，最後製作 Prototype 等呈現階段性成果。
一、設計表現自由度較大
設計方面可以著墨許多的細節，以及探索不同的可能性，想要藉此練習做複雜的動態效果、運用不同的 Prototype 工具，像是 Protopie, Lottie, Principle 等等都可以（沒有工程師管你開發起來麻不麻煩）。若是和工程師合作，多半要在開發成本及設計表現上作權衡和取捨。
由於我的作品集會分別以不同作品來呈現自己的能力，例如 A 作品強調工作經驗，B 作品強調自己的 UI 設計能力等。沒有實作開發考量的專案給我比較大的自由度，可以從 0 到 1 規劃出想呈現的視覺風格、嘗試現在最新的設計趨勢，所以我就會以設計自由度高的作品來強調自己的 UI 設計能力。不過這樣的作品以開發、營運的角度來看，就容易出現元件維護成本較高等等的問題。
在過去的面試過程中，了解許多面試官很重視「美感」，甚至也有聽到面試官認為美感是設計師的各項能力中，最難培養出來的。如果能有設計表現自由度大的實作經驗，可以讓作品集的讀者更好地看見自己不同面向的設計能力。
二、設計流程可以做得比較完整
因為不會有工程師在等著自己把設計稿生出來的狀況，相對來說可以更為從容地做更精細的使用者研究，或者是可以分配比較多時間在研究及設計上，並且嘗試不同的研究方法，把結果分析、設計稿做得較為完整。較為充足的時程，可以有機會產出更高品質的結果，以突顯自己的研究或設計能力，作品集也可以有一個具備完整脈絡的專案。在將內容整理至作品集時，也可以花費相對較少的心力。
三、設計產出可能較不具說服力
由於沒有開發實作的需求，因此容易錯估特定功能、解法的開發成本，或者是部分解法容易欠缺長期營運的考量，所以在呈現這類型作品時，較難以讓聽眾信服此解決方案的成效。如果能夠在解法發想後，至少以 prototype 驗證設計上的假設，了解是否真的有滿足使用者的需求，設計的產出會更為落地。
小結
少了開發環節的 side project 具有以下特點：
- 相對來說讓設計師更能夠做自己，可以幫助自己練習並熟悉新的設計趨勢、嘗試當下興起的產品形式。
- 失去了更實際、嚴謹的練習機會，可能會有一些盲點存在。
對我來說，有開發實作需求的設計專案經驗是非常必要的，但充滿天馬行空的嘗試、想像的設計專案也能夠調劑身心，於我而言算是小酌怡情，就像每天吃正餐，偶爾也會想要吃個千層蛋糕一樣。專案進一步走到開發、上線的階段，才能更進一步了解自己設計上的盲點，以及如何在現實的考量下，運用設計為使用者創造價值。
希望以上的分享，能夠讓大家對於有無開發實作需求的 side project 具備的差異有更多了解，在選擇實作方向時，找到最適合自己的類型！接下來請期待下篇 side project vs 職場實習啦 🤩
UX 實作東西軍 (⁎⁍̴̛ᴗ⁍̴̛⁎) 今晚你要哪一道呢？
