碼農與設計的角色帽不妨換著戴
這個標題源自於Podcast UX Coffee設計咖的其中一個我很喜歡的分享。剛好與我的現況很切合。
升上研究所前的暑假，很幸運的在趨勢科技實習，負責了幾個很棒的專案。
在公司實習的優點就是這些系統都是真的很多人在使用的，可以實際操作一些資料，做樞紐分析找出有意義的資料才做Persona與設計。對於UX學習來說，選擇有埋Tracking在系統中並取得的使用資料的公司是一件很重要的事，因為在學校我們常常只能針對小的系統做使用者經驗訪談跟問卷。而專案也一定要解決某樣問題，公司端出來的東西是真的，不是過一陣子就會消失的東西。最近在負責給外國人使用的軟體，英文的使用者經驗訪談對我而言亦是非常可貴難得的機會，因為在與外國人溝通時，語言上常常會有語意不夠精確而不能問出關鍵問題的狀況。
以下是我實習三週左右感受最深的一些現象還有心得。
跨領域討論如何有效？
跨領域溝通最怕的就是無止境的發散，討論了半天不是重點，也沒有結論。
這種狀況的由來是因為訓練的單一性，在學科中有的人學習的是問題學科，有的人是解答學科。
- 解答學科
擅長解答學科的人如果不從問題學科發散，就容易視野扁狹做出只有功能的成品，沒有辦法發現新的問題。
比如說會AI技術如果只使用開放資料庫的數據做訓練，就只能做出跟別人大同小異的產品。這時候就必須從問題領域去尋找尚未解決的問題，像是利用足夠多的一心二葉的茶葉圖片，就可以訓練出協助茶農的ＡＩ。 - 問題學科
擅長問題學科的人如果沒有學習解答學科的方法與觀點，就容易發現了一堆問題，但發現了半天也沒有什麼結論。或是有了一個簡單的假設，卻做不出成品的狀況。
最棒的尊重專業不是都交給某個人負責某部分，而是時時去理解，時時去發散跟收斂。
而設計的本質，就是把各個領域的能力跟限制都考量進來，完成一件事情。
我很喜歡台大共教中心黃仲菁的能力養成講座，他很明確的交代了什麼是跨領域合作與設計思考的定義。
『設計』並不只是有趣或漂亮的成品，不是出一張嘴很有想法，Design的本意是完成一件事情。
跨領域討論如何有效率：收斂主題，聚焦討論
以我實習的UX角色為例，當我想要獲取其他設計師更好的設計體驗建議時，應該明確交代現在進行到的步驟，而在這個步驟你要注意的工作是哪些。
在我的團隊採取的是Agile開發方法。在一個使用Agile方法開發的團隊，應抱持著MVP(Minimum Viable Product 最低可行產品)想法，不要完美主義。選好命題後，快速測驗並得到反饋。快速失敗，快速修改。
最近剛設計好一款聊天機器人的Userflow，找了用網路速成工具做了一個Prototype，可以用Dialogue-flow吃到Intent參數與模擬操作，但並不是非常漂亮，排版很多並不支援。
雖然我已經交代工具本身的限制，給其他設計師評價時，常常會有人給介面太過呆板，字體層級，UI方面的建議。
但這個並不是這個階段的重點，而是下個階段功能與流程確定後，才開始的Visual Design。因為這時候工程師也是要同步進行開發的。
其他產品的有趣度，故事性與包裝也都不是這個階段該討論的事情。這個很重要，也會關係到產品成敗，但並不是這個階段的重點。
當我們發現開會建議又開始發散時，回歸『限定階段主題討論』跟列出『問題優先層級表』的老方法非常有效。
碼農與設計的角色帽不妨換著戴
因為舊的總管聊天機器人系統過去接受資訊量太複雜，NLP Intent如果有中，常常會一次吐出很多答案，而答案並不是使用者要的，造成使用者離開。新服務如果直接開發在舊系統上會導致答案不準確。
解決方案是再重新訓練一個輕量級的單一專業服務聊天機器人，而由使用者可以總管機器人去呼叫這個輕量的機器人。
基於新舊系統並行的狀況，我在總管機器人做了一個簡單的按鈕呼叫專業型機器人，使用者不會知道其中機器人已經發生轉換。
在交代了這段過程後，就得到了設計師們『如果像Google Home從總管機器人呼叫出精靈機器人該有多有趣』的建議，還有『像是台北捷運大亂鬥，讓專業機器人跟總管機器人在同一個聊天室一定很有趣』的建議。
這兩個想法都非常有趣，這是設計最迷人的地方，總是有出人意表的想法💡。
不過我們系統的載體是文字，少了Google Home聲音的豐富度，對於使用者來說，太過囉唆的文字聊天機器人其實是一種負擔。（使用者：我不想被文字聊天機器人耍，浪費生命，也不想看到太多不是重點的字。）
如果變成很多機器人在同一個聊天室，當大量使用者創了聊天室，並在覺得厭煩之後，按下退出，對於系統負載量而言絕對是一種災難。經過放鬆😌的聊聊想法後，我們也在一個舒服的狀況下知道技術不可行的地方。
如果程式開發者與設計師常常互相交流想法，彼此知道窒礙難行的地方，而不是指著別人鼻子痛罵別人不實際，或很無趣、沒有美感，一個雙贏的局面才會誕生。
公司當中的角色與運行
這3週實習下來的心得，就是先搞清楚幾個角色的課題，再開始設計。
團隊合作是互相了解窒礙難行的部分才開始提出想法。團隊合作是提出想法並承認錯誤。
跟別人意見不一樣時，記得一件事，時時刻刻修正自己的Vision，並替自己的觀點找到充足的數據與理由。
並不是別人沒尊重專業，如果一個公司都是同溫層，每個角色都做同一件事持相同意見就完蛋了，這樣根本做不出一個產品。或是產品推出後才感受到巨大的失敗感。
因此發想功能時，我們需要注意的幾個角度如下：
- 技術方面：
時時刻刻注意最新技術，並瞭解最新技術可以做到什麼程度與資料儲存的機制。
與工程師常常保持溝通，了解團隊現在工作分配，每個工程師擅長什麼，以及團隊目前系統可以做到得程度，修正這兩者之間的差別。
( 常常並不是工程師能力差，或是他們趕著做功能讓使用者體驗不好，而是公司大部分不會是從0到1的開發一個系統，舊的系統與新的系統都會有過渡期。）
- 商業目標：
開出一個簡單的想法的人為何想做這件事？
這個想法想解決的痛點有沒有明確的目標族群？
有時候有，有時候不夠明確。不夠明確時，正是需要利用User Analysis 重新定位清楚的地方。
詢問PM或大主管多半可以得到一個大略的答案，但是這個答案通常會包含一個長遠的Vision，Vision Target user跟Currently Target user要做User Research 的族群有時候會不一樣。
常常跟主管保持溝通去修正這個落差。
而且公司團隊通常會有一個開發時程，按照時程才能確保產品能夠順利產出，主管需要壓一個進度，讓團隊優先完成最重要的事，避免大家多做很多無意義的事，因此需要常常有明確數字與項目可以回報。
- 設計方面：
設計其實不應該是純粹的天馬行空，而是落地的解決問題。
而設計師其實不要覺得一堆限制感到失望，『了解限制』其實才會激發更好的創意。
Ex. 從0到1做一個很精緻的又天馬行空的傢俱，使用者往往只會說一聲：哇！但是不會買單，原因可能是成本過高，沒有解決痛點等。（瞄準的是想要買藝術品的客群則例外）
而在歐美盛行的Ikea改造風潮，則使用了『限制為Ikea』的傢俱，去打造了更多實用的想像，幫助使用者解決問題。
對不同角色的報告方法：Bottom-up / Top-down
在跟不同人報告的時候，報告的方法也要隨之調整。
如果要跟Manager或工程師報告，要報告的方法就要Top-down。先交代MVP是什麼，使用哪些量化數據佐證，再端出完整的設計方案，比較不會讓他們感受到：哇！又一個大夢想家（翻白眼）
一個好設計一定要經過不斷的Iteration，並了解其他設計師的建議。而在跟設計師討論時，他們的思考模式很有可能是Bottom-up的細節取向，所以讓他們了解你在哪個設計階段並希望得到哪方面協助就非常重要，詢問得當他們是一本好字典，能查到任何細節與有趣想法。
