使用者體驗中溝通的技巧

文／王俊煜

對許多在大型企業中工作的使用者體驗設計師來說，經常感到鬱悶的一件事情就是，自己拿著辛辛苦苦熬夜做出來的設計稿去給產品專案組中其他職責的同事一起過目，結果莫名其妙挨了一通不靠譜的板磚——小學學過畫畫的產品經理小a說，藍色不好看。客戶支援部門的交際花小b說，右邊空白挺多，要不放個聊天室視窗讓使用者能在這聊天吧？名牌大學計算機專業博士畢業的小c問，這個註冊按鈕為什麼放在右邊不放在左邊，這麼放有什麼科學根據？專司前端開發的實習生小d這會兒也忍不住發了個言，這個半透明的圓角陰影咱們做不了呀，你得換個效果……

到這裡你已經有撞牆的衝動。最後會議不歡而散，每個人都憤憤不平地走出會議室，你不明白為什麼這幫傢伙會提這麼多不靠譜的問題，而你的同事們當然也想不通，這個頑固的傢伙怎麼就這麼聽不進別人的意見呢？

無論你是上面情境中的設計師，還是參與的其他人員，你一定都希望這樣的情況少發生。設計溝通如何能夠更順暢？設計師如何更容易地把自己的想法推銷給專案組中的其他同事？設計師之外的其他團隊成員，又如何更有效地表達自己關於使用者體驗的看法和意見？

溝通是設計師的本職工作

溝通和團隊協作是一名使用者體驗設計師最基本的能力，也是他的本職工作。雖然許多企業的組織架構中設立了專門的使用者體驗職位或部門，但事實上使用者體驗並不是某個人或某個部門的事情。產品團隊中的每乙個人，都會影響到產品最終呈現給使用者的體驗。所以，縱然設計師有天才的想法和設計，如果不能把這些想法和設計傳遞給團隊的其他成員並獲得認同，那麼其價值都大打折扣。

「使用者體驗」的另乙個特點是：團隊每個成員都可以輕而易舉地對這個話題發表自己的見解，因為每個人都是使用者，都可以很容易從自己的使用經驗出發，推斷出「使用者會……」。因此，相比起開發人員等其他崗位的團隊成員來說，設計師可能需要更多地「忍受」同事的「說三道四」。如何既能在討論的過程中引導別的同事不斷貢獻有建設性的意見，又能贏得其他團隊成員在使用者體驗這個領域上的尊重，並在這個自己的「一畝三分地」裡面保持一定的決定權，也需要設計師在不斷的溝通協作中逐漸實現。

明確了這一點，或許工作中的困擾也能少一點。許多設計師常抱怨：「同事完全沒有設計的sense」，「設計環境不好，老闆不理解我的看法」等，這反而說明了這位設計師的工作沒有做好。反過來說，如果大家都有sense、如果公司上下都已經有很好的設計環境，你做為設計師能發揮的作用也會小很多。

對於設計師以外的其他團隊成員，若在合作的時候能更清楚對方的專長、職責和定位，也能讓雙方的協作進行得更加順暢。許多人至今還狹義地認為使用者體驗就是負責畫畫圖示的、在產品成型以後做做介面修飾的美工。若仍抱有這樣的認識，就很難期望在合作過程中讓設計師對整個團隊貢獻最大化的價值。

確保共識始終存在

設計歸根結底是為了解決問題。不管整個產品設計的流程被分為了幾個階段，不同的階段實際上都是為了解決不同層面、不同規模的問題。產品團隊中的其他同事未必熟悉設計的流程，也未必清楚目前要解決的到底是什麼問題。因此，設計師在和不同職責的同事開展討論之前，都需要確保對方明白整個設計流程是如何規劃的、現在進行到哪個部分、今天要討論的是什麼問題、下一步是什麼等。先確保了大家都站在同一條船上，才能保證大家力氣使到一塊。

另外，在從乙個階段進行到下乙個階段的時候也要確保大家在上個階段中達成了共識，再往前推進。否則如到了視覺設計的階段突然發現大家對非常底層的產品定位問題都還沒有共識，一切都推倒重來的話損失將非常慘重。

為保證溝通的有的放矢，設計師在流程的不同階段也應注意用不同的呈現形式來向同事展示自己的工作。例如，在早期呈現內容規劃時，簡單粗糙的線框圖就要比高保真設計稿更易引發高效的討論和獲取有價值的反饋；而到了後期進行視覺設計確立的階段，則需要採用高保真的原型來盡可能地模擬真實的產品形態。初入行的設計師可能會覺得始終用較高保真度的設計稿會顯得自己的工作做得比較細緻，實則不然——其他同事在審閱設計方案時的注意力可能會被許多如按鈕陰影、用色等視覺細節所轉移，而你本來只是想給大家看乙個互動設計的方案。

如果合作的同事並沒有太多和使用者體驗部門打交道的經驗，那務必要花一些時間來對正在使用的呈現形式或方法做一些解釋說明。我自己有一次用線框圖和負責開發的同事講解產品的互動流程，當時我以為對方理解線框圖的含義，就沒有另外做解釋。結果，開完會以後心急的開發人員就七手八腳地按照線框圖上呈現的視覺樣式，把產品的介面給直接做出來了。

用正確的方式證明自己是對的

在溝通的過程中，其他部門的同事往往會對設計提出很多意見。如何更有效地開展討論呢？

首先，由於其他同事並不是專業設計人員，其言語表達可能並不能準確地反映他們的真實想法，設計師首先要試圖找出其背後的真實含義。

再者，要引導大家盡量運用事實來作為討論的論據。聽見像「我覺得……」這樣的句子，就往往意味著這是乙個主觀判斷——a「覺得」按鈕放在右邊好，b 「覺得」按鈕放在左邊好，這些都是價值判斷；如果沒有一些事實作為判斷的依據，討論很難繼續下去。「事實」可以有很多種表現形式，例如，可以是業界公認的的介面設計基本原則，可以是以往類似情境下我們做出的決定和最後的效果好壞，可以是產品介面設計規範中的相關規定，可以是之前做的可用性測試中使用者的反饋，甚至在必要的時候可以設計乙個a/b測試的方案，用測試的資料來證明設計是否達到了預期的目的等。沒有事實論據輔助的決策，也就是大家坐在一起拍腦袋而已。

有一種批評意見認為在設計中過多地強調了如資料這樣的理性「證據」，會扼殺設計師們的用創造性方式解決問題的能力。直覺和感性認識當然可以用來提出新的解決方案，但這個解決方案是否最後行得通，尤其是在商業環境中，還是需要有一定的理性根據作為支撐的。胡適先生曾提出，治學一定要「大膽假設，小心求證」，做使用者體驗設計也如此。

最後，要提醒討論的參與者分清楚自己和使用者之間的界限。雖然團隊成員也是產品的使用者，甚至可能恰好是產品的目標使用者群，但團隊成員們和產品相處的時間要比一般使用者多得多，對產品的認知早就和一般使用者相去甚遠了。在這種情況下，自己模擬使用者的角度做出的判斷，往往和真實使用者的想法是有差距的。所以，如果你聽見有人說「使用者會……」，就一定多長個心眼，問問這是真的使用者行為，還是發言者想像的使用者。

做為設計師，可以帶領產品團隊隔一段時間進行一次使用者測試，請同事們前往觀摩，往往能看到許多其他團隊成員感到吃驚和開眼界的情景。此外，做為設計師，首先應該抱著虛心的態度聽取別的同事的意見——他們確實不是專業的設計人員，但他們反而能從乙個不一樣的角度看待同樣的事情，發現一些設計師自己發現不了的問題。

每次會議討論的最終決定和這個決定的理由務必詳盡記錄下來，這樣將來可以避免對同乙個問題反覆的討論。有時候外部環境發生了一些變化，有時候是產品團隊人員的變更，難免會有人在將來提出同樣的問題，這時候如果能找到上次討論同個問題時的結論和理由，就可以很快地看看當時考慮的理由現在是否還成立，有沒有新的理由可以支援或反對這個觀點，這樣一來協作效率就可以提高很多了。

思維方式和知識鴻溝的互補

使用者體驗設計師們往往對細節和他人的感受有著敏銳的注意力，而且善於用每當新產品啟動，或老的產品準備進行改進或者開發新功能的時候，我們總是會邀請來自包括工程部門、產品部門、運營部門和使用者體驗部門等各個不同部門的同事坐在一起，召開頭腦風暴會議，希望能從大家思想的碰撞中獲得一些創新的想法。這樣的會議開得多了以後，就能發現乙個有趣的現象：設計師們總是傾向於從「使用者有可能需要什麼」的角度出發考慮問題，而開發人員們總是傾向於從「我們的技術有可能實現什麼」的角度出發考慮問題。

而成功的使用者體驗，往往是在使用者需求、技術能力和商業利益這三者之間達到的平衡，這也是為什麼我們的頭腦風暴會議一定要有各個部門成員的共同參與。為了進一步讓不同的思維方式混合，我們一般還會在初步的頭腦風暴過後請大家挑選幾個聽起來比較靠譜的主意，再混搭不同部門的同事分成多個小組，進一步發展完善這些想法。設計師和開發人員在這個過程中可以互相學習對方的思考過程，形成互補，甚至迸發出新的火花。

當然知識結構的差異也會給溝通造成障礙。例如，如果設計師不清楚目前產品背後的擁有的技術能做什麼事情，做出來的設計要麼就會太過於超前於技術的發展以至於完全無法實現，要麼就是沒有充分發揮出技術的潛在可能性。對於web產品的設計師來說，不了解web介面的實現原理，也有可能做出一些在photoshop裡面畫起來很容易但在web上實現非常複雜，而且並不能帶來許多好處的設計。

對於非設計領域的同事來說，對使用者體驗領域的知識有一定了解，既可以令你更容易與設計團隊的同事展開溝通，又可以培養自己對產品領域、對使用者感受的敏銳注意力，也算錦上添花、一舉兩得。

使用者體驗中溝通的技巧

溝通的技巧

溝通的技巧

使用者體驗中的使用者從何而來

相關推薦