遠端合作：印度工作坊經驗分享
較有規模的公司往往都會遠端的團隊去做合作，原因有時候除了節省成本，再來是針對地域化的設計會能夠融入當地市場的使用模式。然而在遠端的團隊常常會遇到溝通、時區以及工作風格的不同而產生困難。
小編此篇主要分享去年在公司時，與印度團隊合作時所遇到的困難、解決方法以及有幸飛去印度辦公室舉辦工作坊的經驗分享。
困難(Challenges)
遠端工作的同事，他們在文化上已經是根深蒂固的不同之外，他們所想的，和所熟悉的工作模式與在總部設計團隊截然不同。小編歸納幾點在合作上遇到的困難：
一、文化上差異
不同國家的設計師在解決問題上的模式跟在總部的設計團隊有文化上的差異。舉例來說，與我們合作的印度團隊叫習慣於「跟我們說要做什麼，我們把他做出來」而比較不習慣「理解問題，提出問題的解決方案和探索設計的可能性」。在溝通討論上也叫習慣「接受意見」而非「討論以及一起發想解決方案」，在工作團隊上合作的困難，可能總部設計團隊需要先提出較具體的解決方案。
二、時差
不同國家的時區造成的溝通上拖延不是說「這裡工作時＋對方工作時」就可以解決了，有時候在本地設計同仁可以直接開會，一來一往溝通後半小時後可以有共識，在遠端團隊合作時一來一往可能就一週過去了。
三、團隊合作
在公司設計團隊工作時大家會被氣氛所影響、感染而會有和諧的工作模式。再來是On Board時可以習慣在什麼開發階段時需要做什麼事，開發資源在同個地點的話需要Marketing的資源，工業設計師的討論或是工程團隊的理解都可以馬上了解。而處於遠端的團隊往往大家不認識，也不熟悉開發模式之外對於資源掌握也有限，可以完整理解工程限制以及可能提出的解決方案也會較受侷限。
四、語言及溝通
身為在都是美國人的公司的小編已經心很累了，其他腔調還要再花時間適應的。
解決方式(Solution)
介紹一些幫助遠端合作的工具
一、Slack
Slack不得不說是真的很方便的工具，雖然聊天室以前就有，但基於這個使用在工作上不僅僅是工作上更加協調，分享設計，討論idea，工作氣氛變得更好惹！一些討論上的東西在聊天室上就可以完成，再也不用上千封Email互傳，再來是各種Plug in都有支援。重點是可以傳emoji和自訂emoji!
分享一下Slack上的一個功能：Channels
可以針對不同主題建立聊天室，讓不同產品團隊討論之外，更可以設定午餐Channel，星巴克Channel和廢話Channel!!!
二、各種線上設計分享工具
InVision、Adobe XD、Marvel等等都可以直接在他們的雲端上分享設計以及Prototype，不同地方的人都可以直接在上面 Comment或是針對某些區塊提出建議。值得一提是還有Figma這種讓遠端合作的設計師共同合作設計同個產品，小編很有興趣但還沒使用過，有請使用過的大大分享經驗囉！
當然與除了設計分享工具，使用Zeplin, InVision的Measure等等功能是跟遠端開發者溝通順暢的工具。
三、面對面on board
除了使用現有科技讓溝通更為順暢之外，定期的面對面，除了解產品的走向以及願景，讓大家熟悉彼此最重要的是建立團隊的氣氛和文化。
小編在公司與印度團隊工作時，有時候會遇到遠端團隊對這裡設計流程不慎了解以及溝通上的問題，或是對UX不斷的「迭代」和「學習」的概念較不習慣，於是有幸飛去從來沒去過的國度與遠端團隊見面，並舉辦一週的設計工作坊讓我們更了解彼此，讓遠端團隊也更熟悉我們的設計流程，希望讓彼此工作起來更為順暢。（基於印度捧油的隱私和公司NDA有些東西就不放惹）
前置準備
在舉行工作坊之前，我們建立的幾個要達到的目標：
- 讓大家熟悉這裡的工作流程
- 如何讓對方對於設計流程有參與感(Sense of Engagement)
- 之前遇到了什麼問題？如何在工作坊中加強解決
- 回來之後如何讓他們使用所學
我們考慮過一些比較高壓的Design Critique，或是跑一個完整的五天Google Design Sprint
Google Design Sprint 是個五天讓團隊驗證產品構想、設計以及商業價值可行性的流程。這本工具書詳盡記載五天內每天可以做的流程，推薦大家可以看看！
了解(Understand) → 定義(Define) → 發散(Diverge) → 決定或收縮(Decide) → 製作產品原型(Prototype) → 驗證(Validate)
不過上述流程需要不只是設計師，更需要上層管理、開發者和Maketing的人共同參與才能確保產出的可行性。
針對印度團隊所有人的參與可能度及時間性，以及團隊想要增進的內容加上我們本身其他的工作時間，我們決定以公司內部未來有機會使用的產品當作工作坊內容，以產品設計的迭代週期：
大方向問題(Problem Statement) → 產品發想(brainstorming) → 低保真設計及製作原型(Sketching + Low-Fidelity Prototyping) → 使用者驗證(Usability Testing) → 高保真設計(Hi-Fi Prototyping)
一來是印度團隊設計師對的客戶是我們，與我們合作的機會較於其他領域的同仁來得高，再來是用公司未來產品來當基礎不僅讓他們對於公司目標有參與感，也對我們有機會可以繼續進行最後的產出。
飛飛飛
遊記開始了捧油們！身為設計師必須融入當地的文化，才能基於同理心設計出像樣的工作坊！！！
花了二十多時抵達了Hyderbad這個位於印度南方的城市，大概就是像印度的新竹科學園區，是個快速成長，外商聚集的地方，園區甚至有自己不同的關稅，法律上並不屬於“印度”的領土。
印度方言尤其眾多，除了Hindi和英文之外Hyderbad當地人講Telugu，所以雖然英文為我們工作上共用語言他們基本上都是講當地方言的。
我們先去了Hyderbad當地的皇宮Chowmahalla Palace，一覽當地在過去 Asaf Jahi 王朝所統治下的繁華皇宮。（這是我剛剛估狗的）
美美低，不過天氣很實在熱。
印度菜很好吃，這是南印菜，印度同事強迫要用手吃的，我也入境隨俗了這樣一週，手上那個味道會有點難洗。
印度人基本上許多人都吃素，也不太可能看到賣豬肉，美國的連鎖披薩也是咖哩味十足。
印度咖啡的奢侈品-星巴克，基本上只有外國人去。
TATA在印度規模之大，舉凡汽車電子用品顧問企業無所不包。
不過我在印度愛上的咖啡連鎖品牌是這個 — Hatti Kaapi，有點像一小杯義式濃縮加牛奶，而且一杯不到台幣十塊。
分享個小知識：印度同事和我說印度人結婚會跳三天三夜的舞，意者洽詢。
好了愈打愈像旅遊文章，回歸正傳。
工作坊Day 1
第一天基本上都是了解彼此，除了介紹之外也要請對方Speak Out覺得自己的強項，對公司的願景，還有遇到的困難讓大家在同一陣線上(On the same page)，讓大家彼此熟悉，一起聊聊和找解決方式。
印度團隊在遠端比較傾向於「接受意見」而不是「提出意見」，可能是文化背景上的差異，或是他們過去的工作模式，在面對面的環境中可以較沒有壓力的互相聊天，引導他們講出他們的想法。
再來就是我們習慣去了一些設計Conference後都會彼此分享所學，有趣的產品或是構想等等，這一天也是個好機會讓印度團隊與我們分享他們參加Conference後的想法等等。
最後就是讓大家了解我們現在在做什麼，項目的進度和使用什麼工具，也可以轉成Design Critique的模式讓大家都有參與Design Review。
Takeaway:
他們對於走設計工作坊非常的興奮！有時候他們對於項目的了解不夠深入，或是對於使用者如何使用沒有建立同理心，造成在設計上會遇到我們認為是怎麼樣做的對方沒有在同一頁上。再來不夠熟悉設計規範和了解如何有效率的產出設計規範(Design Spec)。
我們針對第一天所學調整了一下我們工作坊要加強的內容，讓他們了解我們怎麼工作外，也要討論在設計規範的內容和如何劃分設計規範以及工程系統的界線。
工作坊Day 2
第二天即是了解工作坊的目標，和我們要以什麼產品為出發點，產品線以大家都較能理解，以及有些調研資源可以利用的為主。
理解Understanding
我們從了解產品的目標市場開始，以及覆述現有的調研資源，基於有限資源先做出Persona，讓大家理解使用者的使用習慣，所關切的功能以及軟體使用方式。（當然是直接參與調研是很重要的，但是基於時間限制這一步是以理解使用者為首要目的）
發散Diverge
根據我們現有的Persona，我們花了十五分鐘時間發想有可能idea，這階段我們使用Post-It Notes，任何片段式的想法，或是只是個小小的功能都可以寫在Post-It Notes上面。比較重要的是許多人會容易太早階段就跳入想法的可行性，或是太瑣碎的設計細節，需要不斷覆述這階段就是腦洞大開，不要局限於現有資源或科技，才能從整體層面去思考使用者想要解決的問題。
收縮Converge
我們將所有想法都貼在牆上，讓每個人都有時間去敘述他的想法，再來分類想法到不同的區塊(Affinity Diagram)，再來就是要選擇我們想要以及測試的Idea。
重新回到產品的目標和Persona，們設定了一些衡量機制去決定我們想要測試的想法，比較嚴謹的方式像是Weighted Matrix Method去根據不同的考量點的重要度來對不同想法投票，我們這裡大概只定義了開發時間金錢成本、設計可行性以及是否有解決使用者問題去做投票。
Takeaway:
在發想這些時發現有時候大家會執著於瑣碎的設計細節和開發細節，而忽略大方向使用者想解決的問題，於是我們決定在做設計之前大家做一個使用者故事版(Storyboard)來去確保大家會注重於解決使用者的問題。
工作坊Day 3
第三天偏向做低本真設計以及驗證的流程。
先一起發想手繪了Storyboard，確保大家大家了解要解決的主要問題之後，我們就開始各自做低保真的設計原型來讓團隊了解低保真不僅不花時間而且在驗證設計上面可以發揮非常大的功用。有時根據團隊的成員性質可以分工內容（像是有人負責做Content等等），不過基於我們認為讓他們都走過一次流程很重要我們決定讓大家各自產出。
使用的工具沒有規定使用什麼，只要可以互動式驗證主要功能即可，Adobe XD, POP都是製作低保真很快的工具，甚至用手繪使用互動的方式也是表達設計的好方法。
再來就是驗證的階段，由於產品為內部產品，我們並沒有去真正找外面的使用者做調研，不過這階段我們主要是驗證產品的Navigation，和是否使用者可以了解架構等等，互相使用，和公司其他同事使用都可以達到使用性驗證的效果。
這個階段強調快速學習迭代，低保真的設計所需時間不長，設計師也不會主觀地愛上設計而拒絕更改（花愈多時間做同個設計，設計師會更主觀的愛上自己的Idea），在驗證時發現大部分人有使用上的困擾，就必須馬上學習更改再度驗證。
Takeaway:
對於要了解快速迭代的概念必須花時間習慣，我們發現必須在這階段強調“快速學習”，並且定完成時間讓大家真的有低保真的產品原型。
工作坊Day 4 + 5
我把這兩天放在一起因為其實一天就可以完成了，不過我們針對了前幾天的回饋增加了一些獨立的工作坊：
- 互動式原型製作工作坊：什麼時候使用什麼工具（像Principle這種Animation Prototype還是InVision這種頁面式的產品原型）較為合適，如何在什麼階段分享低保真、高保真，和如何闡述自己的設計。
- 增進效率之工作上的Design Spec：如何利用Apple Human Interface Guidelines和 Google Material Design Guidelines，產出產品設計規範的原則，如何區分過於瑣碎或是太模糊的設計規範（過於瑣碎在產品開發流程中，開發者會完全按照你的設計去開發，而有任何一些小變動都會要求設計師更改規範，設計師更需要加強如何讓整個流程更順暢），以及如何使用Atomic Design的想法應用在品設計規範當中。
最後一天著重在較高保真的產品原型製作，之前幾天已經有大致上的方向可以前進，高保真的產品原型製作不會需要動到太多的資訊架構變化，著重比較在設計上的細節以及更真實的互動體驗。
Follow-up
最後是如何運用“迭代”的概念去應用在工作上，我們邀請他們之後使用工作坊學到的概念，考慮設計流程中，根據想要測試的設計去做迭代的產出，讓大家溝通更快，設計優化的也會更快。
心得
不同文化背景的人在工作上習慣的互動方式不慎相同，在不同國家舉辦工作坊時必須要考慮許多因素，一來是他們可能不熟悉UX的工作方式，再來是他們以前的工作模式也跟現在公司不相同，尤其在許多人以前在大型顧問公司，有時候他們注重的是產出的量而沒有仔細思考使用上的層面。
面對面舉辦工作坊不僅可以拉近彼此的距離，也可以更知道他們需要什麼方向的協助和增強而隨時調整節奏和內容，最重要的是讓對方融入我們的設計文化，並且提升互相討論設計的氣氛。
印度同事畫了一張我的素描給我，不知道該擺哪裡，在考慮影印二十張貼在我主管牆上，讀者想跟他合作可以洽詢。
最後以飛機上的景做結尾
謝謝大家收看！
