起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識“測試自己的設計”真的弊大于利嗎？
在 UX 設計領域有一句老話，可用性測試不該由設計師自己來執行。雖然聽上去是沒錯的，但真的是這樣嗎？實際上，作為團隊中唯一的UX專家，UX 設計師一直在測試自己的設計，如果他們不去測，那么根本沒人能測試。所以我們有個疑問，“測試自己的設計”，真的是弊大于利的嗎？
很多人曾就這一話題發表過文章，包括 PaulSherman 自 2009 年起在 UXmatters 上做的很棒的專欄。但是，作為一個全面體驗過這個問題的人，我想給出一個不同的視角。我測試了自己的設計，并讓其他人分別測試了我的以及別人的設計，從中體驗到了每種情況的利弊。在這篇專欄中，我們將討論高效測試自己的設計的可能性，并給那些需要做可用性測試的 UX 設計師提一些小小的建議。
為什么你不能自行測試自己的設計
當測試結果沒有找出明確的問題和解決方案時，你就會不由自主的放大那些能支持你想法的結果，而擱置那些不能支持你設計決策的結果。
首先，我們來看看認為最好不要自行測試的人，他們的幾個觀點：
你無法對自己的設計保持客觀
對自行測試最大的爭論是，設計師往往在自己的設計上付出了太多心血，所以很難保持客觀。即使你努力保持公正并意識到自己潛在的偏見，也很難保證完全沒有偏見，這些將影響你的肢體語言，以及你對測試參與者要問的問題和不問的問題。偏見會影響你對測試結果的分析和詮釋。尤其是當測試結果沒有找出明確的問題和解決方案時，你就會不由自主的放大那些能支持你想法的結果，而擱置那些不能支持你設計決策的結果。
你太過于熟悉自己的設計
作為 UX 設計師，你比任何人都要了解自己的設計。你了解設計中所有的需求、決策、技術限制以及利弊權衡。所以，和普通的測試參與者第一次使用產品相比，你對產品的看法是非常不同的。你自身的知識也讓你很難從用戶的視角去看產品。
你可能迫于壓力不想找出太多問題
可用性測試是它是有助于賦予設計以思想的一個迭代的、習得的活動。它是自然發生且期望發現可用性問題的，并且這些問題不應片面地歸咎于設計師。
關于可用性測試最健康的態度是，它是有助于賦予設計以思想的一個迭代的、習得的活動。它是自然發生且期望發現可用性問題的，并且這些問題不應片面地歸咎于設計師。
不幸的是，并不是所有的公司對測試都持有這種健康的態度。當一個公司將可用性測試看作是對設計和其設計者的評估時，任何小的問題都將片面的歸咎于設計師。在這樣一個不健康的氛圍下，測試自己設計的設計師會有強烈的意愿不要發現太多的問題。當第一次可用性測試安排在設計流程后期時，問題尤其明顯，因為在后面的階段發現了主要問題將導致主項目的延期。
其他人會察覺到這其中存在利益沖突
即使一個公司對可用性測試持有健康的態度并且設計師也盡了很大努力保持公正，其他人也仍會察覺到其中利益的沖突。他們可能用這個顧慮作為原因來反駁他們不認同的成果和提議。
同時設計和測試可能讓你忙不過來
將設計和測試的工作分給兩個人去做會更有效率，會讓你更快完成可用性測試，并縮短整體的開發周期。
雖然雇傭一個可以同時完成設計和自行測試的“通才”好像會給公司節省經費，但對一個人來說，這可是大量的工作。設計師通常忙于設計和制作原型以至于沒有時間去計劃測試、招募測試參與人員、進行測試會議和分析數據。將設計和測試分給兩個人可以讓他們能同時進行這些工作。這會更有效率，會讓你更快完成可用性測試，并縮短整體的開發周期。
提供誠實的反饋時對參與者來說可能會很尷尬
直接對設計者提出批評和負面的反饋往往會讓參與者很尷尬。反而，他們會努力表現得禮貌并降低批評的力度。無論何時我測試別人的設計，我都會強調：“我沒有參與設計，我只是被要求收集測試者的反饋。所以如果你們狠狠的批評，也并不算是冒犯我，也不會傷了我的心?！眳⑴c者這時往往會開心的笑并覺得更自在，也更可能給出他們真是的觀點。但是，當我自己是設計師，測試我自己的設計師，我很難發自內心的那樣說。
為什么要測試自己的設計
作為設計師，沒有人比你更懂這個設計。你清楚所有設計流程中的決議、疑問、異議和利弊權衡。
盡管有很多有力的原因支持不要自行測試，但自行測試仍有很多益處。我們來一起看一下。
你比任何人都更了解你的設計
作為設計師，沒有人比你更懂你的設計。如果你搞定了投資人和用戶調研，你就是最熟悉業務和用戶需求的人。你清楚所有設計流程中的決議、疑問、異議和利弊權衡。所以你是計劃可用性測試最合理的人選，你可以確保測試專注于解決最重要的問題。
你比任何人都更了解你的設計原型
作為原型的制作者，你知道哪些鏈接、按鈕、交互組件是可用的，哪些是無效的。你知道怎樣是行不通的，測試過程中有異常的情況發生之前，你最清楚怎樣讓參與者回到正軌。如果一個原型組件是無效的，你可以向參與者描述它怎樣正常運行。如果你需要修復原型中的一個問題，你或許能夠在試驗間隙完成。
通過測試你可以獲取第一手資料
有了對實驗結果更深入的了解，你就能更好決策出哪些設計模塊是需要改變的。
理解設計結果對 UX 設計師來說是無比重要的。那么還有比親自去開展和觀測測試更好的方式嗎？沒錯，設計師可以簡單的觀測測試，然而，想讓測試效果更好，就需要付出更多的注意力和互動在參與者身上，而不是簡單的被動的觀察。另外，這讓你可以實時詢問問題。有了對實驗結果更深入的了解，你就能更好決策出哪些設計模塊是需要改變的。
你可能是最能勝任測試工作的人
有些人可以同時熟練的完成用戶調查和設計工作并熱衷于兩者。當你已經做過用戶調查并完成了設計，你可能很難再將可用性測試交付給其他人去做。最在乎設計的是你自己，所以你是最了解情況也是最有動力去做測試的人。
自行測試你的設計好過什么測試也不做
即使你認為讓其他人來測試你的設計更理想，但這并不總是可行的。當一個公司沒有可用性測試方面的專家，通常會讓另一個沒有參與這個項目的設計師來代替執行測試，但對于進度比較趕的團隊，就連這個他們都難以做到。所以，當沒有可用的其他人選來做測試時，讓 UX 設計師自行測試自己的設計肯定要比完全跳過可用性測試更可取。
關于可用性測試的小建議
提醒你的客戶和項目團隊，可用性測試是一個不斷習得的過程，它的目的就是找出問題和解決設計上的疑問。
不管你認為設計師不要自行測試為好，還是設計師可以自行測試他們的設計，這里都有一些方法讓這些情況發揮最大作用。
當你測試自己的設計時
當你需要測試自己的設計時，下面幾個小建議可以幫你躲避之前提到的問題：
- 提醒你的客戶和項目團隊，可用性測試是一個不斷習得的過程，它的目的就是找出問題和解決設計上的疑問。提倡這種健康的關于測試的態度，避免將測試作為一個設計師的技能評估。
- 進行至少兩輪可用性測試，并在設計的早期階段就開始進行。這會使你能夠在開發周期中較早發現并修復問題，而越早做出設計上的改變，時間和經濟成本越小。當你有時間去修復發現的問題是，這些問題看起來不會是那么災難性的，然后，再次測試。
- 針對解決方案的多個版本比較測試。這會讓測試的焦點從評估一個設計或是設計師的能力重新回到哪些版本有效或無效的比較。比較測試將測試的調子變得更像一個不斷習得的過程。
- 當你開始項目的可用性測試階段，努力給自己一種置身于可用性測試中的心態——和原來的自己劃分清楚，你已經不再扮演設計師的角色了，反而，你要將自己想象成一個中立的可用性測試專家，努力和那些設計保持距離。
- 努力讓自己進入一種中立模式，簡單地詢問問題并記錄參與者提供的信息。不要去辯護自己的設計或解釋為什么自己確信要那樣做。想象你是一個演員，接手了一個可用性測試員的角色，而不是你平時的設計師的角色。
- 努力做一個不含偏見任務和問題的討論指南。因為這很容易會不經意間包含進去一些帶有偏見的問題，所以讓一個有測試經驗的人檢查一下你的討論指南，這樣他們可以指出那些存在潛在偏見的和具有一定引導性的問題。
- 告訴參與者你在測試一個早期設計，目的是發現和解決問題。讓他們消除顧慮，知道你要的是他們真實的反饋，不論好壞，并且怎樣都不會傷害到你的感情。當然，你絕不應該不誠實的聲明或暗示這個設計方案不是你的，但是，你不需要主動說明你就是設計者。
- 如果你不確定自己是否能不帶偏見，那就嚴格按照討論指南，堅持只問指南上有的問題。
- 專注于客觀地記錄你聽到和觀察到。嘗試著在測試期間得出結論和感悟是你作為設計師的偏見在誤導你。（別在測試時著急得出結論）
- 當你報告測試結果時，直率的承認設計的問題和失敗?？陀^地討論自己設計中問題和成功的能力會提升你在其他人心中的可靠程度。將發現可用性問題當作是能改進設計的一次有價值的學習體驗。
當你不準備測試自己的設計時
在任何研究活動——整個設計過程以及可用性測試期間，與用戶研究者保持緊密的工作聯系。
如果其他人將要測試你的設計，下面幾個小建議會讓這種情況達到最佳效果：
讓將要執行測試的人在項目的一開始就參與進來，以確保這個人可以充分理解業務需求、用戶方面的問題以及設計的演化。避免將一個對項目一無所知的人帶進來做測試。
在任何研究活動——整個設計過程以及可用性測試期間，與用戶研究者保持緊密的工作聯系。盡管用戶研究者主要負責用戶研究和可用性測試而你主要負責設計，但保證這些不是分隔開的活動。
當可用性專家準備測試時，給他一個清單，上面包括重要的測試項目、你對設計的疑問和客戶或其他項目組成員對設計的關注點和疑問。
觀察每個測試會議并進行記錄來保持專注。
在討論結果和得出潛在解決方案的過程中與測試人員合作進行。
當你的團隊沒有專門的用戶研究人員而只是由UX相關的人員組成時，設計師可以互相測試彼此的設計。然而，你仍然需要幫他們了解項目的細節，觀察測試并在解讀測試結果的過程中與他們保持緊密的工作聯系。
理想的情況
理想的情況是有一個用戶研究人員和一個設計師在項目中共同在用戶調研、設計和可用性測試等環節緊密合作。
在我看來，理想的情況是有一個用戶研究人員和一個設計師在項目中共同在用戶調研、設計和可用性測試等環節緊密合作。當然，這并不是經常能實現的。所以，如果你必須自行測試自己的設計，按照這篇專欄中提到的建議，你可以將潛在可能發生問題降到最少。
原文作者：Jim Ross
原文地址：http://www.uxmatters.com/mt/archives/2016/11/testing-your-own-designs.php
翻譯：UIBANG 欒凱
譯文地址：微信公眾號【UIBANG】
本文由 @UIBANG 授權發布于人人都是產品經理，未經作者許可，禁止轉載。
測試用例
它是自然發生且期望發現可用性問題的，并且這些問題不應片面地歸咎于設計師