如何在不傷害忠實用戶的情況下推出新功能
已發表: 2022-03-10“敏捷； 提前釋放； 經常釋放。” 我們知道演習。 但是，經常推出功能在戰略上是否明智？ 尤其是當您正在構建的產品達到一定規模時，您可能不想在每個新的次要版本中冒著應用程序完整性的風險。
你的產品可能發生的最糟糕的事情是忠誠的用戶，多年來一直使用這個小功能的客戶，突然無法以同樣方便的方式使用它。 這種變化可能會賦予用戶更多權力，但體驗會變得不那麼簡單。 沮喪和焦慮迅速而突然地進入社交媒體，客戶支持的壓力每分鐘都在增加，以做出有意義的及時響應。 當然，我們不想推出新功能只是為了意識到它們實際上傷害了忠實用戶。
SmashingMag 的進一步閱讀：鏈接
- 我們如何開始以兩倍的速度發布功能
- 網站啟動清單 – 上線前的 15 項基本檢查
- 以用戶為中心的移動設備網頁設計方法
- 如何啟動任何東西
我們可以通過在推出我們產品的新版本時更具戰略性來防止這種情況發生。 在本文中，我們將研究產品設計師和前端工程師在將功能發布給整個用戶群之前徹底測試和部署功能的策略，以及如何避免用戶體驗問題逐漸蔓延。
在深入研究實際測試策略之前，讓我們退後一步，檢查一下關於如何設計、構建和最終部署新功能的常見誤解。
新功能誤解
每當為現有產品設計新功能時，主要關注點通常是應該如何將其準確地集成到現有界面中。 為了實現一致性，我們設計師經常會研究現有的模式並應用已建立的設計語言來使新功能在 UI 中很好地呈現。 然而，問題的出現並不是因為組件在視覺上不能協同工作，而是因為當它們以意想不到的方式組合時會變得令人困惑或模棱兩可。
也許界面的副本在網站的相關但遙遠的區域中是模棱兩可的，或者同時積極使用兩個功能的結果從技術角度來看是有意義的，但不符合用戶期望或具有重大性能影響並損害用戶體驗.
事實上，在設計中，正是這些眾多的組合很難徹底預測和審查。 在設計過程中解決問題的一種方法是考慮異常值 - 事情更有可能出錯的用例。 如果用戶名很長，用戶個人資料會是什麼樣子？ 當使用十幾個收件箱標籤時，未答復電子郵件的概覽是否仍然顯而易見？ 對於剛剛註冊並且收件箱中只有幾封電子郵件的用戶來說，新的過濾器是否有意義？
設計異常值：用戶界面堆棧
一旦我們確定了異常值，我們如何準確地設計它們？ 一個好的策略是研究用戶界面的不同狀態。 “用戶界面堆棧”是 Scott Hurff 提出的一個想法，用途廣泛且複雜，當我們設計界面時，通常在 Photoshop、Sketch 或 HTML 和 CSS 中製作像素完美的模型是不夠的——我們必須考慮各種邊緣情況和狀態：空白狀態、加載狀態、部分狀態、錯誤狀態和理想狀態。 這些並不像我們想像的那麼簡單。
空白狀態不一定是空的——我們可以使用服務工作者為常客提供更好的離線體驗。 部分狀態不必被破壞——我們可以通過漸進增強來改善破壞圖像和破壞 JavaScript 的體驗。
由於自定義用戶偏好和用戶的瀏覽器選擇，理想狀態可能與我們的“完美結果”模型有很大不同； 例如，由於瀏覽器的配置，某些內容和 Web 字體可能無法顯示。
因此，情況一如既往地複雜、錯綜複雜且不可預測，我們不能將出錯的風險忽略不計，但這並不意味著我們不能有效地將風險降到最低。 通過及早探索異常值和整個用戶界面堆棧，我們可以在早期設計階段防止常見的用戶體驗問題。 不過，在技術方面並沒有變得更容易。
部署中的蝴蝶效應
即使是微小的變化也會導致連鎖反應，在看似完全不相關的領域和情況中引入錯誤。 造成這種情況的主要原因是影響用戶體驗但我們無法控制的大量變量。 我們確實知道我們使用瀏覽器的方式，但這並不意味著我們更多地了解用戶選擇查看我們如此不知疲倦和徹底製作的網站的上下文。
現在，雖然像按鈕上的填充或逐漸增強的文本區域這樣的小改動可能看起來沒什麼大不了的，但我們傾向於低估這些閃亮的小改動或大規模特性的影響。 每次我們做出設計或開發決策時，這種變化都會對我們正在構建的複雜系統產生一些影響，主要是因為我們正在構建的組件永遠不會孤立存在。
現實情況是，我們從來不只是構建一個按鈕，我們也不只是編寫一個新的 JavaScript 函數——按鈕和函數屬於一個組件或庫家族，它們都在特定的環境中運行，並且不可避免地與其他的系統的某些部分通過它們的屬性或範圍或名稱或團隊的不成文約定。
這些“無聲”的、幾乎不引人注意的聯繫是推出功能困難的原因，也是為什麼預測變化的深遠影響往往被證明是一種敏銳的眼力。 這就是為什麼盡可能避免不必要的依賴是個好主意，無論是在 CSS 還是 JavaScript 中——它們不會幫助你進行維護或調試，尤其是當你依賴一個你不完全理解的庫時.
幸運的是，為了更好地了解更改的影響，我們可以使用瀏覽器的開發人員工具等資源。 我們可以測量選擇器的範圍或 JavaScript 函數的範圍，有時在開發過程中不斷返回以保持更改的範圍盡可能本地和最小可能是個好主意。
這很有幫助，但這也只是故事的一部分。 我們有意識地和無意識地做出假設，基於我們自己對界面的體驗和我們自己的習慣——經常忘記假設可能（因此，將會）因用戶而異。 大多數應用程序確實只有一個界面，但這個界面或其配置可以有幾十種狀態——視圖會根據用戶的設置和偏好而變化。
考慮帶有可定制卡片的儀表板（分析軟件），具有“緊湊”、“舒適”和“詳細”視圖（Gmail）的郵件客戶端，為登錄的客戶和客人更改的預訂界面，閱讀體驗對於使用廣告攔截器或激進的防病毒過濾器的人。 蝴蝶效應影響的不僅僅是代碼庫； 所有這些外部因素也很重要，並且針對它們進行測試 - 與單元測試或一般的 QA 不同 - 非常困難，因為我們通常甚至不知道要測試什麼。
特徵驗證和局部最大值
我們可以使用診斷和指標來確定需要進行哪些更改，但是僅通過跟踪數據，您最終可能會停滯在我們傾向於稱之為“局部最大值”的狀態，這是一種設計足夠好的界面狀態，但完全缺乏創新，因為它總是遵循可預測的、合乎邏輯的迭代。 在開展項目並探索數據時，我們傾向於將特徵分為以下四個桶：
- 破碎的特徵。 . 看似損壞或效率低下的功能——顯然，我們需要修復它們；
- 未使用的功能。 . 按預期工作但很少使用的功能 - 通常表明它們應該被刪除或迫切需要創新；
- 意外的使用功能。 . 以與其創造者最初設想的方式截然不同的方式使用的功能——緩慢、持續改進的良好候選；
- 主力功能。 . 被大量使用並且似乎按計劃工作的功能——在這種情況下，我們問自己是否有任何方法可以通過並行探索緩慢的迭代過程和完全不同的創新概念來進一步改進他們的用戶體驗。
前兩個桶對於保持界面的功能和可用性至關重要，而後兩個桶對於保持用戶的參與和高興至關重要。 理想情況下，我們希望同時實現這兩個目標，但時間、預算和團隊限制佔上風。
儘管如此，一旦選擇了新的迭代或新想法，就很有可能立即開始設計或構建新功能。 但在考慮如何將功能融入現有界面之前，首先驗證這個想法是一個很好的策略——通過快速原型和用戶研究。 實現這一目標的常用方法是使用快速迭代過程，例如 Google Ventures 的設計衝刺。 通過在幾天內進行迭代，您可以確定新功能應該如何實現和/或它是否像您最初想像的那樣有用。
通過設計衝刺，我們儘早將想法暴露給可用性研究。 在 Google Ventures 的方法中，您將每天有五個用戶測試一個設計； 然後，您將迭代並通過新設計的另一輪測試。 涉及所有相同用戶的原因是，如果您當天對每個用戶測試不同的設計，您將沒有有效數據來知道哪些元素應該更改。 您需要幾個用戶來驗證一個設計迭代。
我們在衝刺中應用了一個稍微不同的模型。 當我們開始開發新功能時，一旦構建了早期的第一個原型，我們就會將設計師、開發人員和 UX 團隊聚集在同一個房間裡，邀請真實用戶進行測試，然後在緊湊的時間表內進行迭代。 第一天，第一批測試人員（兩到三個人）可能會安排在上午 9:00 進行 30 分鐘的面試，第二組在上午 11:00，下一個在下午 2:00，最後一個一個在下午 4:00 左右。 在用戶訪談之間，我們有“開放時間窗口”，當我們實際迭代設計和原型時，直到某個時候我們有了可行的東西。
這樣做的原因是，早期我們想快速探索完全不同的，有時甚至是相反的方向； 一旦我們收集到不同界面的反饋，我們就可以趨向於“絕對最大”的界面。 通過這種方式，我們可以更快地獲得關於非常多樣化的設計迭代的非常多樣化的反饋。 反饋主要基於三個因素：記錄用戶點擊的熱圖、用戶完成任務所需的時間以及體驗對他們來說有多愉快。 本週晚些時候，我們將繼續與更多用戶保持一致，就像谷歌所做的那樣，在我們進行過程中永久驗證新設計。
到目前為止一切都很好，但有時看似創新的新功能會與現有功能發生衝突，並且將它們放在同一個界面中會使設計混亂。 在這種情況下，我們探討是否可以將其中一個選項視為另一個選項的擴展。 如果可以，那麼我們首先重申其功能和設計。 那時我們必須選擇徹底的重新設計或增量更改。 後者風險較小，並且會為用戶保持熟悉的交互模式，而如果無法以其他方式實現關鍵更改，或者增量更改的收益太淺，則需要前者。
在任何一種情況下，都必須關注產品的整個用戶體驗，而不是產品中單個功能的價值。 一旦您選擇了功能並設計並構建了第一個原型，就可以進行測試了。
八級測試
那麼，我們如何有效地防止錯誤和故障蔓延到實際的現場環境中呢？ 在部署功能之前，我們運行了多少次檢查、審查和測試？ 我們以什麼順序運行這些測試？ 換句話說，推出功能的最終策略是什麼樣的？
推出功能的更好策略之一是由俄羅斯主要電子郵件提供商 Mail.ru 的開發主管 Andrew Sumin 提出的。 該策略並不適用於每個項目，但對於為成千上萬的客戶提供大中型產品的公司來說，這是一種合理而全面的方法。
讓我們詳細了解該策略，並涵蓋功能推出的八個步驟，涵蓋 Mail.ru 的產品開發過程：
- 與開發人員一起測試，
- 在受控環境中與真實用戶進行測試，
- 與公司範圍內的用戶一起測試，
- 與 beta 測試人員一起測試，
- 與手動選擇加入的用戶進行測試，
- 拆分測試和檢查保留，
- 緩慢而逐漸地釋放，
- 衡量後果。
在 Mail.ru 的案例中，最重要的功能是保持完整，無論是什麼組成的消息（顯然）。 這是界面中最常用的部分，讓它不可用或即使幾秒鐘也不能正常工作是絕對不可能的。 那麼，如果我們想擴展 textarea 的功能，可能通過添加一些智能自動完成功能、計數器或側面預覽，該怎麼辦？
1. 與開發人員一起測試
開發時間越長，解決問題的成本就越高。 再次考慮一下所有決策在產品開發中的關聯程度； 產品越精煉，就越需要重新做出決定，從而耗費時間和資源。 因此，從業務角度和設計和開發角度儘早識別和解決問題。
但是，你不能調試一個想法，所以初始測試應該在生產期間，在第一個原型上進行。 Mail.ru 的第一批測試人員是實際編寫代碼的開發人員。 公司鼓勵員工使用該產品進行內部交流（甚至私人交流）； 因此，開發人員可以被視為產品的核心用戶。
第一步很明顯：設計和構建功能，然後在登台服務器上進行本地測試、審查和推出。 這就是 QA 測試的用武之地，使用全面的工具和任務運行器來嘗試使功能和界面崩潰，並可能通過 Gremlins.js 等猴子測試工具實現自動化。
對結果進行監控，然後將其反饋到反饋循環中，以進行特徵的下一次迭代。 在某些時候，開發人員會對構建充滿信心：更改似乎按預期工作，並且已滿足要求。 那是真正的用戶測試開始的時候。
2. 在受控環境中使用真實用戶進行測試
當第一個工作原型完成後，該功能將在採訪中與實際用戶進行測試。 客戶被邀請完成任務，當他們這樣做時，用戶體驗團隊會監控死胡同和問題，並在現場解決這些問題。
但是，不僅新功能正在測試中； 可用性測試的目標是確保新功能不會影響界面的關鍵組件，這就是用戶完成日常任務的原因，例如撰寫消息以及打開、回復和瀏覽收件箱中的電子郵件。 如果新功能和舊功能都被很好地理解，則該過程可以繼續進行。
3. 與全公司用戶一起測試
顯然，來自可用性測試的反饋會促使開發人員引入更改，然後將這些更改反饋給可用性測試人員，反復進行，直到結果似乎對更多的受眾有價值。 然後，下一步是讓該功能在公司內受到關注：發送一封全公司範圍的電子郵件，鼓勵所有同事檢查該功能並在跟踪器中提交報告、錯誤和建議。
通過測試，公司內“遠程”部門的用戶與野外用戶之間沒有特別大的差異。 甚至內部用戶也不知道預期會發生什麼變化，也不知道某個功能究竟做了什麼，或者它應該如何工作或看起來如何。 唯一的主要區別是可以提示同事快速提交反饋或發表評論。 那是引入投票表格的時候。 測試人員不僅可以使用該功能，還可以添加評論並支持或反對它。 投票必須與產品策略和業務需求進行權衡，但如果用戶明顯發現某項功能無用或有用，那麼這是一種收集反饋並測試產品是否按預期工作的簡單而有效的方法。
4. 使用 Beta 測試人員進行測試
如果一項功能通過了公司內部的技術檢查、可用性檢查和審查，那麼下一個合乎邏輯的步驟是將其介紹給部分受眾。 然而，該團隊並沒有將其推廣給隨機的用戶群，而是提交了一項功能供 beta 測試人員進行審查 - 選擇參與測試並提交實驗性功能反饋的用戶。 他們可以對某個功能投反對票或投贊成票，還可以報告錯誤和提交代碼片段。
但是您如何選擇合適的 beta 測試人員呢？ 好吧，如果您想鼓勵測試人員打破界面，您可能會關注具有技術技能的高級忠實用戶——必要時能夠提供有關錯誤的技術細節的用戶，以及足夠了解現有界面的用戶能夠預測其他用戶可能遇到的問題。
但是，您需要標準來確定用戶是否足夠先進，可以成為 beta 測試人員。 對於電子郵件客戶端，可能是使用 Chrome 或 Firefox（即他們知道如何更改默認瀏覽器）、在收件箱中創建了三個以上文件夾並且還安裝了移動應用程序的人。
5. 使用手動選擇加入的用戶進行測試
到目前為止，測試涉及到可管理數量的用戶、配置和測試報告。 然而，用戶、系統和配置的多樣性，包括操作系統、瀏覽器、插件、網絡設置、防病毒軟件和其他本地安裝的應用程序，在規模上可能會稍微令人生畏。
在 Mail.ru 的案例中，下一步是在實時界面中推出該功能，在一個標誌後面，並向這一更大的活躍用戶群發送一封電子郵件，展示新功能並邀請他們在他們的自己在界面中，通常帶有閃亮的“更新”按鈕。 為了衡量該功能對實際用戶的價值，該團隊再次使用投票系統，這里和那裡有一些提示，基本上是詢問用戶是否覺得該功能有用或有用。 請注意，此級別與上一個級別之間的區別在於，手動選擇參與的受眾要多得多——與 beta 測試人員不同，他們中的許多人根本不是技術人員。
所以，時機和協調很重要。 您可能不會隨機選擇一天向活躍用戶發送電子郵件，因為您希望客戶支持團隊和開發人員在錯誤報告流開始出現時可用。這就是電子郵件發送至本週開始時，所有（或大多數）開發人員都可用並且支持團隊已準備好採取行動，通過Skype或Slack與開發人員進行了簡要介紹並積極聯繫。 在一家較小的公司，您甚至可以讓開發人員在支持台坐幾個小時，通過直接與客戶交談來更快地找到問題的核心。
6. 拆分測試和檢查保留
在到目前為止的步驟中，除了可用性測試之外，所有測試人員都自願使用了新功能。 但是，如果您默認啟用該功能，突然間用戶將不得不使用它，這是一種非常不同的組，我們根本沒有測試過。
為確保您不會破壞被動用戶的習慣，您可以對三小部分用戶進行拆分測試並衡量留存率。 畢竟，您要確保新版本至少與前一個版本一樣好用。 確定界面中最重要的活動，不僅要衡量用戶在推出前後花費了多少時間，還要衡量他們返回之前經過了多少時間。 在 Mail.ru 的案例中，保留需要用戶檢查他們的電子郵件並撰寫郵件。 用戶回來的頻率越高，留存率就越高，這是用戶體驗更好的指標。
每個部分的視圖略有不同，這使我們能夠測試如何在以後向所有用戶顯示新功能。 對於第一部分，我們添加了新功能並提供瞭如何使用它的教程。 對於第二部分，我們只添加新功能。 對於第三部分，我們可以保持原樣。 對於所有這些部分，我們可以同時實施更改，選擇合理的時間範圍來運行測試，衡量保留率，然後比較結果。 細分的保留率越高，該設計就越有可能在以後推廣給所有用戶。
7. 緩慢而漸進地釋放
如果某項功能已經走到了這一步，那麼它可能已經適用於大部分受眾。 這是您可以逐步將其推廣給所有用戶的時候——通過投票提示來收集反饋。 如果反饋大多是積極的，您可以繼續推出該功能，它最終將成為界面不可或缺的一部分。 否則，您將評估反饋並返回實驗室進行下一次迭代。
但是，推出該功能還不夠：它必須傳達給用戶。 一種常見的方法是通過電子郵件和社交媒體。 儘管如此，解釋該功能在現實生活場景中的價值的快速演練教程也可能會有所幫助。 此外，不要忘記集成建議框以立即收集反饋。
8. 衡量後果
一旦該功能推出，我們可以監控它的執行情況並嘗試不同的方法來引起人們的注意，以便用戶能夠更有效地執行他們的任務。 您可以跟踪最常見的任務或訪問最多的頁面，然後顯示一個小內嵌註釋，為用戶推荐一種更智能、更快的方式來實現他們的目標，然後衡量用戶是否更喜歡這個新功能或常用方法。
不要忘記將反饋反饋給整個團隊，而不僅僅是開發人員或設計師，這樣他們就會有動力並參與其中，並了解人們如何使用最初只是一個粗略想法的功能。 沒有什麼比看到快樂、高興的人完全按照您的設想或以完全不同的方式使用應用程序更能激勵人了。 它還將滋養團隊後續功能的發展。
審查過程看起來複雜而徹底，但有時只有時間和廣泛的用戶測試網絡才能發現問題。 例如，如果更改會影響傳入消息的概覽，則任何單元測試都無法發現輔助軟件用戶可能遇到的困難。 在郵件界面中，您希望無障礙設備首先讀出什麼：日期、發件人、主題行還是消息本身？ 您重新排列概覽中的列的方式可能會改變用戶選擇訪問信息的方式； 因此，允許他們關閉新功能也很重要。
結論
那麼，推廣策略是什麼樣的呢？ 您可以從探索依賴關係圖開始，以了解您的更改可能影響深遠。 然後，您可以在受控環境中與開發人員和真實用戶一起測試該功能。 然後，您可以要求同事審查該功能，然後再將其發送給一組選定的 beta 測試人員。 最後，您可以將該功能作為選項提供給用戶。 而且，在為所有人啟用該功能之前，您可以進行拆分測試以找出引入該功能的最佳方式，然後衡量關鍵任務的保留率。
顯然，部署不是一個線性過程。 在整個過程中，您可能需要後退兩步才能向前邁出一步——直到最終獲得發布候選。 上面介紹的工作流程可能看起來很慢，而且不是特別敏捷，但是您可以極大地降低用戶突然遇到意外問題並因此體驗不佳的風險。 在某些情況下，這可能非常值得。