規(guī)劃及推出超棒用戶體驗的有效方法
產品經理們 + 設計師們
大部分組織架構下烁竭,設計師(們)和產品經理(們)都是親密合作的猎荠。產品經理對產品功能中的元素有很大的發(fā)言權伊磺。他們有權否決設計決策,也有權決定某個產品的特定用戶流程是如何設計的棚亩。他們也完全參與到商業(yè)需求的分析中蓖议,并思考如何塑造產品去滿足上述的需求。他們思考用戶如何與產品交互讥蟆,并分析產品是否滿足目標用戶的需要。他們幫助工程師構建需求的優(yōu)先級列表纺阔。他們是決策者瘸彤,幫助建立產品路線圖和維護/定義產品的愿景。
這是一個責任很重的角色笛钝,不是嗎质况?
簡而言之,他們是超級巨星玻靡,他們工作在高壓環(huán)境下结榄。在任何給定的時刻,總有超多他們難以啃下的難題囤捻。
設計師需要配合達到產品經理的目標臼朗,因為歸根結底,這兩個利益相關者有相同的愿景。
思考流程的不同
說實話视哑,起初绣否,我很難和產品經理的思考流程在同一個頻道上。作為設計師挡毅,我們傾向思考關于體驗蒜撮,關于路徑,以及設計組件有多么一致跪呈,并如何使它們更好的工作在不同的分辨率上等等段磨。
另一方面,我們不太關注當前的業(yè)務需求耗绿、技術的影響欲低、產品策略在未來幾個季度的路線圖以及資源分配等峻呕。
顯然,我們不會本能地去關注這些,這就是為什么在產品世界挠锥,和產品經理協(xié)作是一個基本需要——它有助于描繪一幅更廣闊的圖景。
在與產品經理密切合作了很長一段時間后部蛇,我決定記下那些幫助我設計時更具目標的方法論肺缕。
以下是我采取的一些行動,排名不分先后
1. 排列任務優(yōu)先級
2. 維護一個用戶體驗債務表
3. 建立一個用戶體驗測試方案
4. 在產品內追蹤用戶行為
1. 排列任務優(yōu)先級
我注意到奴紧,一旦提起邏輯不一致或改善樣式等話題經常激怒產品經理特姐。后來我意識到不是因為他們不想修復或者那些不重要,而是沒到合適的時機黍氮。但總有一個合適的時機讓你來提起你最大的痛處唐含。
那我們怎么知道什么時候是合適的時機呢?
回答這個是比我想象的要難一點沫浆。我的做法是捷枯,從更廣泛的角度理解產品狀態(tài)。
我開始注意當前的業(yè)務需求和技術的影響专执。
業(yè)務需求?——?在最早的時候需要做些什么來提供價值淮捆。 因為如果你不獲利,你就不是一個成功的生意本股。實際上攀痊,沒有任何領域是可以為也許不存在的需求做設計的。
技術需求——需要做什么去穩(wěn)定系統(tǒng)而不會破壞現有的功能拄显。還有那些需要優(yōu)化去提供一個更好的體驗的事情苟径。
理解技術限制對設計決策有很大幫助。一些看上去優(yōu)雅的交互可能對系統(tǒng)是巨大的負載躬审,所以必須權衡利弊來維持系統(tǒng)穩(wěn)定棘街。
當功能都被毀了蟆盐,性感交互的意義何在?
考慮到這兩個主要需求蹬碧,除了「我想做的設計變更」的超長清單外舱禽,我開始排優(yōu)先級清單。
產品需要進行重大更改的模塊恩沽,優(yōu)先級通常會下降誊稚,創(chuàng)造價值最大的項目會上升。優(yōu)先級清單幫助我更好地安排工作罗心。
當合適的時機來臨(相信我里伯,它會來的),我會立即提出我已經想好的重設計方案渤闷,這使得和產品經理的合作更富有成效并較少沖突疾瓮。
2. UX 債務表
幾乎所有的設計師應該都從產品經理那里聽過——
「讓我們先拿出MVP(譯者注:最小可行性產品),我們可以晚點再回來優(yōu)化它飒箭±堑纾」
這讓我感到非常沮喪,因為我意識到產品目前的變化是非常微小的弦蹂。這不是我想要的作為一個設計師的理想體驗肩碟。
我擔心如果我們一直用MVP的做法,我們最終會需要加更多的班只為了去修復遺留問題凸椿。這更像是一個MVP悖論削祈。
巧合的是,我注意到工程師們有一個技術待辦事項的賬戶脑漫,他們稱之為技術債務髓抑。這是一個待排期的技術任務清單。他們專門用一輪沖刺(Sprint优幸,敏捷開發(fā)詞匯)完成這些任務吨拍。我認為這是一個偉大的想法,不知道在我工作的項目中是否也可以運用這么一個UX債務表网杆。
我和產品經理討論過后密末,決定列出所有的用戶體驗待改進事項。我制作了一種圖表跛璧,將改變產生的影響和實現的難易程度映射在坐標系上,來作為排列任務的優(yōu)先級的參考新啼。
你可能注意到了坐標系中有四個象限追城,數字代表的是優(yōu)先程度。
第一象限——任務很容易實現并能產生較大的影響燥撞。 這些帶來最大價值的需要首先解決座柱。
第二象限——容易實現但影響不是很大的任務迷帜。 這些需要接著推動的許多小改進能幫助我們帶來優(yōu)秀的體驗。
第三象限——接下來我們開始處理產品中那些難實現的部分的任務色洞。這些更難去實現的任務應該具有最大的影響戏锹,這點很重要。
第四象限——這個象限的任務優(yōu)先級很低火诸,通常不會去解決锦针。要想將這些任務從這個象限常年居于次要的位置移除,可以把它們分割為子任務置蜀,然后優(yōu)先級的判斷流程可以再次被應用到這些子任務上奈搜。處理這個象限的任務是一件很有挑戰(zhàn)性的事情,我仍然試圖找出如何更好地處理這些任務的方法盯荤。
接下來得有個記錄的地方馋吗,得讓它們在視線之內,以免忘記秋秤。我所在的團隊已經很習慣使用JIRA來跟蹤大部分項目進度宏粤。
為了將設計的優(yōu)先級安排更好的曝光,產品經理建議我創(chuàng)建一個「用戶體驗改進」JIRA項目灼卢,這是個明智的舉措绍哎,現在我們每個人都能隨時在看板上看到設計的改進,因為所有完成的原型和文檔都共享在那了芥玉。
不同的團隊使用各種不同的項目管理工具蛇摸。我們的UX團隊用Trello維護UX待處理清單。我也看到某些開發(fā)團隊使用Basecamp灿巧。
3. UX測試方案
我在研究生院時代的設計流程是赶袄,在決定怎么設計之前,做大量的用戶研究和分析抠藕。這意味著有足夠的時間計劃和執(zhí)行這些研究饿肺。但在敏捷的環(huán)境下,并不能總這樣盾似。功能設計與某些假設是基于現有的使用模式和對目標受眾的了解
大部分假設都會通過用戶電話驗證敬辣。在發(fā)布給用戶驗證之前建立一個測試方案是很重要的。為了盡可能發(fā)揮和用戶交流30-40分鐘的價值零院,我傾向于和產品經理精心組織給用戶電話溉跃。
大多數用戶反饋電話的結構類似這樣——
- 測試的目的
- 需要被證明的假設
- 用戶在界面上的操作路徑
- 得到接下來他們在產品中期望什么的大概想法
4. 追蹤產品中的用戶行為
現有用戶的行為是重新設計產品的良好依據打洼。如果現有功能的使用流程因技術限制而需要改變龄糊,又或者現有用戶對功能的可用性存疑逆粹,那根據數據去制定重新設計的方案是個很好的辦法。類似谷歌分析這樣的數據分析工具提供一些途徑去評估用戶流失率炫惩、用戶的操作順序等等僻弹。但在大多數情況下,產品需要更細致的追蹤他嚷。
用戶在進行點擊操作時發(fā)生了什么蹋绽?用戶接下來會去哪個界面?如何衡量一個功能是否成功爸舒?這樣的問題可以通過追蹤操作路徑來得到回答蟋字。
一個設計師,為了更好地表達他們的設計決策扭勉,需要分析和找出需要追蹤什么鹊奖,為什么要追蹤,我們最終想達到什么目的涂炎。
更復雜的事件追蹤和詳細的漏斗分析忠聚,像MixPanel和Keen這樣的工具提供他們的API來讓我們自定義更細粒度的追蹤。如此豐富的用戶數據可以幫助設計師們作出更好的決策并更清楚的傳達給其他利益相關方唱捣。
能幫助設計師分析這些數據的最好一位朋友两蟀,就是產品經理。產品經理可以直接訪問這些數據震缭,他們中的一些也深入參與這些工作赂毯,所以他們對這些數據更有全局觀。
總結
本文不是一篇教導設計師如何規(guī)劃他們與產品經理工作的廣泛指導拣宰,但無疑可以告訴大家如何往正確的方向邁出一步党涕。產品經理幫助我學會思考像素以外的東西,幫助我們排列任務優(yōu)先順序巡社,為我們正在設計的東西提供了一個全局的視角膛堤。
我對你們和產品經理合作的流程同樣感興趣,我很樂意看到你們在下方評論去留言 :)
本文轉載并翻譯至 uxdesign.cc
原文地址 ?https://uxdesign.cc/a-designers-guide-to-working-with-product-managers-bcb164a473df晌该?scid=social70785596#.qd6b343ze
原作者信息
I am Adhithya, a Product Designer at OpenDNS, San Francisco. If you liked this article, hit the recommend button below. ?
You can find me on Twitter. Check my work here, or simply write to me at adhithya.ramakumar@gmail.com