avatar獸群之心 / Soking

Free AI web copilot to create summaries, insights and extended knowledge, download it at here

2313

Abstract

X 設計師必須經常將整體的資訊架構布局在腦袋中來回思考。</p><p id="1cb6">這個時候數據分析是重要的溝通工具。</p><h2 id="53cc">從數據解讀用戶旅程地圖開始</h2><p id="3430">在 2018 年的現在,行動流量已經佔據大多數網站七成以上也不奇怪的時代,還是有許多主管或老闆只盯著「桌機版的網站首頁」要求你規劃出豐富多彩的花式版面,並且每次專案進度會議上會要求再拿出首頁來討論一下。</p><p id="4285">但網站的到達頁可能有九成是產品單頁。</p><p id="b6a5">許多決策者對於用戶是如何進入網站、什麼時候回來、因為什麼動機而轉換、受到什麼挫折而離開,接近一無所知。因為他們大多數的時間在應付外面商業市場的風風雨雨。</p><p id="4571">而最常操作數據的行銷部門可能只關注投放廣告績效以及最終轉換率的財務數字,鮮少關心用戶在網站上逛某些頁面代表什麼行為上的含意。</p><p id="9e31">因此我在擔任 UX 設計師參與網站改版案時,會先將用戶在網站上的行為流程耙梳過一次,例如用數據說明以下用戶行為:</p><ul><li>以首頁來說,大約全站一成的用戶會逛到首頁</li><li>來逛首頁的用戶有三成大概逛不到一分鐘覺得無聊就離開網站</li><li>四成的人會被第一屏的近期更新帶到指定的頁面去</li><li>兩成的人會去點擊首頁的導覽列 MENU,其中大多數的點擊集中在第一個分類</li><li>一成的人會進行站內搜索,他們搜尋的字大概是…</li></ul><p id="bbb8">類似像這類的敘述方式,一邊打開網頁一邊講解網站現況給參與會議的決策者了解。但是決策者大多數沒什麼耐心聽完,所以要看臉色挑重點講。</p><p id="b79d">解讀用戶在網站上的旅程,用意是提供一些客觀的角度,避免主觀見解直接被挑戰,聽聽看利害關係人對於網站上的這些行為旅程有什麼「局部優化」的見解。通常人們會比較重視自己熟悉的頁面,或者令自己痛苦的流程。</p><p id="74ce">舉個例子,我曾經根據 GA 篩選用戶區隔,來分析到底是誰在使用站內搜尋,後來發現絕大多數的站內搜尋來自公司內部。營運人員因為常常在查找公司網站內容,所以覺得站內搜尋的功能很重要,應該要做得又大又明顯,而且希望功能繁多。但搜尋技術的開發是很高門檻的投入,顯然開發投入的優先權要好好評估。</p><h1 id="0aa3">UX改版第三招:Prototype</h1><p id="0890">每個人都認為自己想要的東西很簡單,直到你把菜端到他面前。</p><h2 id="0d58">提早溝通、頻繁溝通,避免一翻兩瞪眼</h2><p id="4117">在複雜專案的改版過程中,因為每個人都有自己對於「局部優化」的期待,因此把設計師的規劃放到「全員大會」上討論,反而是最糟糕的形式。要不就是靜默無聲,要不轉眼就成為批判大會。</p><p id="3bc2">在利害關係人訪談之後,UX 設計師應該要定期跟利害關係人保持聯繫,例如偶爾請對方補充提供一些參考資料等等。</p><p id="f074">將一些爭議性高、不確定性高、風險高的流程製作成局部 Prototype,在緊張刺激的「全員大會」之前,UX 設計師可以提早帶著 Prototype 私底下拜訪過相關的利害關係人,邀請對方給予意見或指點。</p><p id="5661">展示 Prototype 的訪談過程,專注在說明情境以及要解決的問題,最好能帶到當初訪談時該名利害關係人曾經提出過的想法,讓利害關係人覺得這個規劃如果有所成果,自己也能算得上一份功勞,以爭取他的支持。</p><h2 id="572a">向所有利害關係人展示規劃</h2><p id="314b">人們在行動或表達意見時,不會直接誠實表現,而是配合社會期許的價值,加以調整後再表現出來,這是心理學上所謂社會期許的偏誤。</p><p id="f542">Prototype 的製作是為了溝通,避免開發團隊花大把的時間開發之後,又要花費更可觀的時間修改產品。</p><p id="6d7a">因此在對所有利害關係人展示規劃的場合中,如果能明確的應對對方曾經提出的問題,並且用肯定的態度解釋新的規劃中會如何解決問題,通常就能取得利害關係人的支持。</p><p id="b056">當在場的人覺得大多數人是傾向支持目前的規劃時,非理性的質疑聲音也會隨之減少。(除非,現在的規劃根本不符合大家期待,那就是前面的步驟沒有踏實的完成。)</p><p id="12a7">對「需求」的研究與檢驗有多深入,我們提出的規劃就有多穩固,不會隨意因為「莫需有」理由打槍而翻盤。</p><p id="8183">有一句笑話是這樣說的:</p><blockquote id="230b"><p>水上行走跟開發軟體都很簡單,只要狀態是凍結的。</p></blockquote><h1 id="f9a0">結語</h1><p id="52fb">可以發現本篇文章不是在討論 Prototype 怎麼做會更好的技巧性問題,而是在討論工作上面對的專業溝通問題。</p><p id="42c9">雖然用戶體驗設計師這個職稱直覺上好像是站在廣義的用戶立場上,代替用戶提出觀點,但我認為組織內部的支持是你的設計能否通過的重要因素。</p><p id="c3c9">用戶體驗設計師提出對用戶友善的規劃是本職,但運用專業讓組織內的其他人理解你的規劃,是更深入的專業。</

Options

p><p id="62c4">祝各位專案順利。</p><p id="8611">如果覺得這篇文章有用,請幫我多拍幾個手兒,並感謝您的鼓勵。</p> <figure id="648e"> <div> <div> <img class="ratio" src="http://placehold.it/16x9"> <iframe class="" src="https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fbutton.like.co%2Fin%2Fembed%2Fsoking1010%2Fbutton%2F&amp;url=https%3A%2F%2Fbutton.like.co%2Fsoking1010&amp;image=https%3A%2F%2Fstorage.googleapis.com%2Flikecoin-foundation.appspot.com%2Flikecoin_store_user_soking1010_main%3FGoogleAccessId%3Dfirebase-adminsdk-eyzut%2540likecoin-foundation.iam.gserviceaccount.com%26Expires%3D2430432000%26Signature%3DDFDl8P%252B9Jdx0ePhy2HKjsfIUNIcKnGRQYyY%252Bw4zXSIM3cDfCOjRm7k6TQIDoBltW7ZQwRQmBke37eANfs%252FnPaOM15lNhDX5mY5U9dzwwEBTesOJlChnj%252BveojFAoJRgwLo01oNNjpA3Ys5MQzVFcf9a%252FXKBAPcEL%252FMQB70Y0Ki9s6bcu3p%252Bif5tgxwMctN8jvp9IiCig9Q52IerLgJdGjjRZ7YlSHeuEOjJVWbqgqK8QPDGkg1jWVbCGBxBB70LXEfNmoKPVNJU0vb6TMw107HUCfZuWZreEoJmyWinS4if9ZXqsXj%252BF%252FZW9BKDcN%252BEhi24V35z0rk7BzZDZS2M%252BGg%253D%253D&amp;key=a19fcc184b9711e1b4764040d3dc5c07&amp;type=text%2Fhtml&amp;schema=like" allowfullscreen="" frameborder="0" height="212" width="485"> </div> </div> </figure></iframe></div></div></figure><div id="e420"><pre>查看獸群之心的 UX 文章目錄</pre></div><h2 id="fd46">相關文章:</h2><ul><li><a href="https://medium.com/@soking/%E5%85%A5%E9%96%80%E8%B3%87%E8%A8%8A%E6%9E%B6%E6%A7%8B%E4%B8%A6%E5%AD%B8%E7%BF%92ux%E8%A8%AD%E8%A8%88%E5%B8%AB%E7%9A%84%E6%80%9D%E8%80%83%E6%96%B9%E5%BC%8F-%E4%B8%80-%E8%A7%80%E5%AF%9F%E8%88%87%E7%B7%B4%E7%BF%92%E7%9A%84%E6%96%B9%E6%B3%95-ccaf0e6afcb2">入門資訊架構並學習UX設計師的思考方式(一)觀察與練習的方法</a></li><li><a href="https://medium.com/@soking/ux%E5%B7%A5%E4%BD%9C%E5%9D%8A-%E7%B1%8C%E5%82%99%E7%94%A8%E6%88%B6%E8%A8%AA%E8%AB%87%E5%B7%A5%E4%BD%9C%E5%9D%8A%E7%9A%84%E5%BF%83%E5%BE%97%E7%AD%86%E8%A8%98%E8%88%87%E6%9B%B8%E5%96%AE-2a253d8695bd">【UX工作坊】籌備用戶訪談工作坊的心得筆記與書單</a></li><li><a href="https://readmedium.com/ux-how-to-contextual-interview-stakeholder-and-analyze-74c788833e3e">UX設計師用戶訪談利害關係人的五種情境分析法</a></li><li><a href="https://readmedium.com/ux-soking-user-interview-story-8ca8ca9b74e">我的用戶訪談故事與工作效益評估</a></li><li><a href="https://readmedium.com/ux-write-placeholder-bce6f7c76329">後台功能性介面的UX文案筆記</a></li></ul></article></body>

談UX設計師網站改版三招:利害關係人訪談/數據分析/Prototype

本篇文章是工作心得,著重專案流程上遇到的情境問題,而不是具體的討論像「Wireframe 規劃的小技巧」。

網站改版的定義:產品會大幅調整使用流程或體驗,但會繼承原有的使用資料。(俗稱搬站)

以前當 PM 自己營運產品的時候,通常我不太支持產品的大改版,產品改版是最傷筋動骨的事情,通常也伴隨組織內部管理問題要一併調整,壓力與失敗風險都很高。

我認為 UX 設計師在產品改版案當中,最具有價值的事情是:凝聚共識

你可能會覺得奇怪,「凝聚共識」不是應該 PM 的工作嗎? 但PM 要用什麼來凝聚共識?當然是 UX 設計師提供的設計文件囉。

以下我會介紹這三種 UX 工具如何陪我度過網站改版案的驚濤駭浪:

1. 利害關係人訪談
2. 數據分析
3. Prototype

當然,不是說其他 UX 設計工具就用不上,只是我優先討論「凝聚共識」最有幫助的這三個工具。

UX改版第一招:利害關係人訪談

UX 設計師在產品改版過程中壓力很大,因為 PO 講的需求,跟實際在操作的人講的需求,還有老闆講的需求,都會不一樣。每個利害關係人都訪談完之後,就會知道處理密室殺人案的偵探有多頭痛了。

辨識利害關係人

進行利害關係人訪談之前,我們要準備名單,也就是「辨識出利害關係人」。利害關係人的英文是「Stakeholder」,這本來是金融名詞,有股東、債權人、利益相關者、風險承擔人等意思。

因此,我們要先明確定義這次改版任務的目標,並根據目標會影響的人,依據風險的程度去辨識出他們的存在。

比方說專案的 PM 是不是利害關係人?當然是,專案的成敗算在他頭上。 專案出資者是不是利害關係人?當然是,他燒錢承擔這個專案開發的風險。 專案的營運人員是不是利害關係人?他們是,以公司內部成員來說,產品規格的變動可能會大幅影響他們的業績、運作成本。

這邊我留個問題:老闆的老婆算是利害關係人嗎?

辨識利害關係人還有個隱藏攻略,就是要注意A關係人與B關係人之間的賽局競合問題。例如某個規格是A關係人的部門迫切需要的,但會影響B部門的運作績效。 這些事情可能在決策者層級是看不見的問題,但輕忽此問題會造成你的規劃被打槍到死,因為該扛起協調責任的人置身事外。

選擇利害關係人

如果有多個利害關係人,只能選擇一位時,應該考慮他們是否能代表大多數該類型關係人。

選擇利害關係人進行訪談前,最好先做基本的背景調查,例如:

  1. 職業角色:包括該名關係人在組織內的地位、核心的工作職責是什麼?了解這些才能更快理解他的主要訴求、關注點、阻力點是基於什麼觀點出發。
  2. 個人特質:主要包括職業背景、經歷,或者關係人在組織內的人脈關係等,以便瞭解他的思考邏輯方式與管理偏好。
  3. 聯絡管道:為了安排該名關係人適合溝通的時間與環境,最好能基本了解他的時間表與工作場合。 我曾遇過明明說好需要安排1.5小時的空檔,在安靜的咖啡廳作訪談,但受訪者當天才被緊急告知,導致前後都卡了會議,在吵雜倉庫內痛苦的進行倉促的訪談。

完成利害關係人訪談,是為了釐清每個人的想法不同。當 UX 紮實完成這些內容,遇到 PM 或老闆質疑時,可以依據不同利害關係人的立場回答,請 PM 或老闆迅速下決定,減少冗長的跨部門溝通時間。

UX改版第二招:數據分析

在討論網站改版的時候,大多數的人會先關注令他痛苦的事情能被改變,而出資者會比較在意能引起外界迴響的虛榮指標。只有很少數的人會關注整個產品的轉換率、用戶行為流程的細節。

對 UX 設計師來說,網站改版比從無到有容易處理的地方是,至少產品運作一段時間後,有客觀的數據可以檢視。

除此之外 UX 設計師會發現,自己其實是在跟每個利害關係人非理性的一面在溝通,因為每個利害關係人有各自在意的「局部優化」想像。但 UX 設計師必須經常將整體的資訊架構布局在腦袋中來回思考。

這個時候數據分析是重要的溝通工具。

從數據解讀用戶旅程地圖開始

在 2018 年的現在,行動流量已經佔據大多數網站七成以上也不奇怪的時代,還是有許多主管或老闆只盯著「桌機版的網站首頁」要求你規劃出豐富多彩的花式版面,並且每次專案進度會議上會要求再拿出首頁來討論一下。

但網站的到達頁可能有九成是產品單頁。

許多決策者對於用戶是如何進入網站、什麼時候回來、因為什麼動機而轉換、受到什麼挫折而離開,接近一無所知。因為他們大多數的時間在應付外面商業市場的風風雨雨。

而最常操作數據的行銷部門可能只關注投放廣告績效以及最終轉換率的財務數字,鮮少關心用戶在網站上逛某些頁面代表什麼行為上的含意。

因此我在擔任 UX 設計師參與網站改版案時,會先將用戶在網站上的行為流程耙梳過一次,例如用數據說明以下用戶行為:

  • 以首頁來說,大約全站一成的用戶會逛到首頁
  • 來逛首頁的用戶有三成大概逛不到一分鐘覺得無聊就離開網站
  • 四成的人會被第一屏的近期更新帶到指定的頁面去
  • 兩成的人會去點擊首頁的導覽列 MENU,其中大多數的點擊集中在第一個分類
  • 一成的人會進行站內搜索,他們搜尋的字大概是…

類似像這類的敘述方式,一邊打開網頁一邊講解網站現況給參與會議的決策者了解。但是決策者大多數沒什麼耐心聽完,所以要看臉色挑重點講。

解讀用戶在網站上的旅程,用意是提供一些客觀的角度,避免主觀見解直接被挑戰,聽聽看利害關係人對於網站上的這些行為旅程有什麼「局部優化」的見解。通常人們會比較重視自己熟悉的頁面,或者令自己痛苦的流程。

舉個例子,我曾經根據 GA 篩選用戶區隔,來分析到底是誰在使用站內搜尋,後來發現絕大多數的站內搜尋來自公司內部。營運人員因為常常在查找公司網站內容,所以覺得站內搜尋的功能很重要,應該要做得又大又明顯,而且希望功能繁多。但搜尋技術的開發是很高門檻的投入,顯然開發投入的優先權要好好評估。

UX改版第三招:Prototype

每個人都認為自己想要的東西很簡單,直到你把菜端到他面前。

提早溝通、頻繁溝通,避免一翻兩瞪眼

在複雜專案的改版過程中,因為每個人都有自己對於「局部優化」的期待,因此把設計師的規劃放到「全員大會」上討論,反而是最糟糕的形式。要不就是靜默無聲,要不轉眼就成為批判大會。

在利害關係人訪談之後,UX 設計師應該要定期跟利害關係人保持聯繫,例如偶爾請對方補充提供一些參考資料等等。

將一些爭議性高、不確定性高、風險高的流程製作成局部 Prototype,在緊張刺激的「全員大會」之前,UX 設計師可以提早帶著 Prototype 私底下拜訪過相關的利害關係人,邀請對方給予意見或指點。

展示 Prototype 的訪談過程,專注在說明情境以及要解決的問題,最好能帶到當初訪談時該名利害關係人曾經提出過的想法,讓利害關係人覺得這個規劃如果有所成果,自己也能算得上一份功勞,以爭取他的支持。

向所有利害關係人展示規劃

人們在行動或表達意見時,不會直接誠實表現,而是配合社會期許的價值,加以調整後再表現出來,這是心理學上所謂社會期許的偏誤。

Prototype 的製作是為了溝通,避免開發團隊花大把的時間開發之後,又要花費更可觀的時間修改產品。

因此在對所有利害關係人展示規劃的場合中,如果能明確的應對對方曾經提出的問題,並且用肯定的態度解釋新的規劃中會如何解決問題,通常就能取得利害關係人的支持。

當在場的人覺得大多數人是傾向支持目前的規劃時,非理性的質疑聲音也會隨之減少。(除非,現在的規劃根本不符合大家期待,那就是前面的步驟沒有踏實的完成。)

對「需求」的研究與檢驗有多深入,我們提出的規劃就有多穩固,不會隨意因為「莫需有」理由打槍而翻盤。

有一句笑話是這樣說的:

水上行走跟開發軟體都很簡單,只要狀態是凍結的。

結語

可以發現本篇文章不是在討論 Prototype 怎麼做會更好的技巧性問題,而是在討論工作上面對的專業溝通問題。

雖然用戶體驗設計師這個職稱直覺上好像是站在廣義的用戶立場上,代替用戶提出觀點,但我認為組織內部的支持是你的設計能否通過的重要因素。

用戶體驗設計師提出對用戶友善的規劃是本職,但運用專業讓組織內的其他人理解你的規劃,是更深入的專業。

祝各位專案順利。

如果覺得這篇文章有用,請幫我多拍幾個手兒,並感謝您的鼓勵。

查看獸群之心的 UX 文章目錄

相關文章:

UX
Product Design
Prototype
Data Analysis
Stakeholder
Recommended from ReadMedium