在代碼中不需要為用戶添加“選項”

有時,我們為了讓應用程序中能更方便的滿足用戶需要時,會在程序中添加一些可選的功能特性,如果用戶的情況需要特定的功能,我們可以在程序中啟用這些特性。我們的意圖是好的,但是這些行為實際上會導致更多的問題,因為我們邀請用戶通過在用戶體驗中添加額外的步驟來猜測他們的選擇。

開源最著名的方面之一是允許開發人員通過添加一個可能不適合所有人的可選特性來滿足用戶的需求,但是允許一小部分用戶以特定的方式參與項目。雖然這似乎是一個很好的想法,以滿足個人的需要,有幾個缺點,使某件事的選擇。

它增加開發人員的工作

創建額外的選項意味著前端和後端團隊都需要做更多的工作。這些特性為每個設置添加了額外的代碼、測試和文檔,並且各種狀態會更改UI。在開發過程的每個步驟中添加選項都會對您造成傷害。

它給用戶帶來了選擇的負擔

當我們通過包含選項來解決問題時,我們迫使用戶考慮這個功能,並考慮它的用途和缺點,從而給他們帶來了控制如何使用應用程序的負擔。用戶猶豫不決,必須決定是否應該啟用此功能。畢竟,如果一個選項顯著增強了用戶體驗,那麼它不是已經被自動集成了嗎?

它使未來的功能更難實現

另外還有其他選擇的長期影響。僅僅一個額外的選項就可以導致兩個路徑中的一個,這可能會影響應用程序的其他部分。因此,每當我們添加一個選項時,應用程序的狀態數就會翻倍。這是指數式增長,加起來很快,使得錯誤診斷更加困難。多個選項可能會導致創建我們不知道的狀態,所以用戶很難理解應用程序應該如何運行,因為他們不知道錯誤是否由選項引起。如果是一個選項導致了錯誤,問題出在哪個選項上?

我們如何避免添加選項

那麼,您如何知道一個特性是否應該是可選的呢?在GitLab,我們發佈了第一個迭代,並根據用戶反饋繼續發佈。我們預期的一些特性可能永遠不會推出,因為用戶不會請求它們。迭代允許我們減少開發範圍,避免包含不受歡迎或不可用的特性。

當用戶需要新東西時,嘗試創建一個大多數人都能接受的解決方案。依靠您的開發和運營團隊提供反饋,並要求他們與最終用戶建立聯繫。與用戶進行用戶體驗研究還有助於識別痛點和需求。

團隊不斷受到開發能力的限制,嚮應用程序添加選項可能會佔用以前的時間和精力。我們建議在沒有選項的情況下發布您的應用程序,並等待人們是否提出請求或為其提出功能建議。最後,我們的角色是解決用戶的問題,而我們的目標是識別挑戰的根本原因,並以一種不需要選擇的方式修復它。


分享到:


相關文章: