在此閱讀我們的更新排程。

系統可透過讓使用者輕鬆存取和使用應用程式,讓使用者感到自己完成了更高品質的工作,並讓使用者想要在系統中使用應用程式,來示範吸引人的行為。

提供吸引人的行為對業務很重要,因為它直接與使用者採用以及整體工作人員和客戶滿意度相關聯。參與行為也有助於減少支援要求,並有助於提高使用者的功能要求品質。

建立吸引行為的其中一個挑戰是難以單獨透過目標度量來測量。而是由使用者的主觀體驗所衡量;使用者認為參與應用程式提供真正的價值。參與應用程式可供 存取、非滲透且易於瞭解。他們需要最少數量的上線和訓練。他們會使用明確的方法來主動防止使用者發生錯誤。

另一個挑戰是參與目標通常會隨著您系統中不同類型的使用者互動而有所不同。例如,您可以針對管理個案的內部使用者有一組目標,針對透過網站表單提交資訊的外部使用者有一組目標。若要設計吸引人的系統,您必須仔細考量您嘗試建立的參與類型,以及使用者想要參與的原因,再開始組合功能和頁面。

與使用者體驗 (UX) 設計師合作,可協助您在提供吸引人的應用程式時做出更有效的決策。從結構角度來看,使用者採用與保留是健康系統的重要元件。參與結構可降低使用者快速完成程序或略過步驟,以避免在不喜歡使用的系統中花費時間所導致的資料品質問題的可能性。針對對外開放的系統,引人注目的結構可以增加收入和客戶保留,因為發現系統更容易使用的客戶會選擇與您的組織進行更多業務往來。

您可以透過專注於提供簡化且實用的體驗,來建立更具吸引力的應用程式。

簡化的應用程式易於瀏覽、清楚呈現資訊和資料輸入工作,並調整以符合各種尺寸規格。簡化的應用程式也具有使用者已在其他常用應用程式中習慣的體驗模式。例如,大多數的網頁瀏覽器會在使用者以滑鼠右鍵按一下連結時,將「在新索引標籤中開啟」顯示為首選項。包含索引標籤的簡化應用程式會遵循相同的模式。

應用程式體驗效率不佳的影響可能遠遠超出個別應用程式。應用程式體驗不佳會破壞使用者的 Trust。隨著更多類型的業務關鍵應用程式和面向客戶的應用程式移至數位管道,這可能會讓公司失去關鍵利害關係人的忠誠度。

您可以更有意圖地處理應用程式複雜性、尺寸設計和尺寸規格,藉此更簡化您的應用程式。

將應用程式複雜性降到最低表示使用者只會看見相關功能表項目、索引標籤和瀏覽控制項。您必須在使用者群組、使用者權限和正確的應用程式體驗之間建立對應。使用這些對應以瞭解要向指定使用者呈現的應用程式體驗,然後確保您的應用程式具有提供該體驗所需的邏輯控制項。

呈現使用者過於複雜的應用程式會造成各種不良體驗:

• 使用者經常會看見不必要或不相關的索引標籤、瀏覽至空白畫面,以及遇到停用或封鎖的連結。
• 如「如果您的角色為 X,請忽略此索引標籤」等不必要或不實用的指示會顯示在訓練和啟用資料中。
• 混亂的瀏覽功能表會迫使使用者花費額外的時間尋找完成工作所需的項目。

這些不良體驗會導致低的採用率和滿意度。

決定正確的應用程式複雜度層級時,請考量下列事項:

• 根據使用者需要執行的工作優先順序,組織功能表、索引標籤和其他瀏覽控制項。
• 避免導入使用者必須僅學習才能使用您應用程式的新行為。
• 請勿移除可讓使用者自訂其使用者介面層面的功能存取權。
• 使用權限集提供展開或減少的瀏覽選項。
• 簡化 Lightning 頁面啟用 指派。最小化每個應用程式啟用中的 Lightning 頁數。使用動態表單、權限集和條件化呈現,將項目新增至應用程式中的 Lightning 頁面。請進行此操作,而非維護多個 Lightning 頁面 (由設定檔啟用和指派)。

下方的 模式與反模式清單顯示 Salesforce 組織中應用程式複雜性管理的適當 (和不良) 外觀。您可以使用這些項目來驗證或改善應用程式設計。

若要深入瞭解可協助您管理應用程式複雜性的 Salesforce 工具,請參閱與參與相關的 工具。

簡化表單可將資訊組織為邏輯序列、支援快速資料輸入,並將必要步驟最小化。它們也允許使用 有用的用戶端資料驗證訊息,並避免重複的表單提交週期。

設計表單時,請考量下列事項:

• 將相關欄位分組在一起。與流程或資料項目工作中相同步驟相關的群組欄位。去除與現有工作不直接相關的欄位。
• 提早進行資料輸入和驗證。需要使用者輸入資料的欄位應提前顯示在表單上。最佳作法是盡快在欄位層級呈現資料格式化或遺漏資料的問題 (亦即在使用者嘗試瀏覽至下一個步驟或提交表單之前)。此外,請避免在使用者有機會將資料輸入欄位之前顯示欄位級錯誤。
• 最小化資料輸入工作。盡可能預先填入或自動填寫盡可能多的欄位,以儘量減少資料輸入錯誤並提升效率。僅要求使用者輸入重要或重要資料。去除與現有業務流程無關的任何資料輸入。盡可能使用選項清單,而非任意格式的文字欄位,以強制選取有效選項並減少相同回答的變化。
• 將提交至伺服器最小化。請勿讓多步驟表單多次將資料提交至伺服器。確保所有自訂 LWC 或 Aura 元件都使用用戶端快取來處理瀏覽或分頁動作。(Salesforce Lightning Experience 和 Salesforce 行動應用程式預設使用用戶端快取。)設計表單,讓使用者僅將資料提交至伺服器一次。提交表單前,在用戶端驗證使用者輸入。這可儘量減少非預期的使用者提交、防止重複或雜亂的交易在後端耗用頻寬,並協助您針對更好的 資料處理進行設計。
• 管理表單狀態。用戶端快取不僅有助於如瀏覽和分頁等行為,還有助於儘量減少連線問題造成的資料遺失。有效管理狀態也意味著應用程式可以適當協調資料提交至伺服器,並防止重複交易,並根據伺服器端動作的狀態向使用者顯示相關且及時的訊息。簡化表單只會提交資料作業一次,且不需要使用者等待在伺服器上長時間執行作業完成。
• 遵循無障礙標準。若要將應用程式的受眾最大化,並協助確保其能包含所有客戶,請在表單設計中強制執行無障礙功能標準。

簡化表單有助於提高應用程式中的資料完整性,以及應用程式對使用者有何幫助。他們也可以減少支援票證和要求,因為使用者能夠更完善地解決錯誤,並清楚瞭解其表單提交的狀態。此外,簡化表單可讓使用者快速且有效地輸入資料,並確保使用者無須等待執行較長的程序完成以執行進一步工作。

下方的 模式與反模式清單顯示 Salesforce 組織中正確 (和不良) 的表單設計外觀。您可以使用這些項目來驗證或改善表單設計。

若要深入瞭解可協助您建立更簡化的表單的 Salesforce 工具,請參閱參與相關的 工具。如需為使用個案選擇正確表單工具的更具體指引,請參閱使用 Salesforce 建立表單的 結構設計師決策指南。

參與應用程式適應不同的裝置和互動類型或尺寸規格。根據裝置類型,不同類型的使用者互動會更容易 (或更難),表單和欄位的可讀性也會改變。請記住,除了畫面尺寸之外,尺寸規格也會參照使用者與畫面互動的方式。裝置數量越來越多,現在有觸控螢幕,而某些使用者也可能使用特殊裝置來進行無障礙操作。設計表單時,請務必考量下列因素。

無法考慮尺寸規格變化會導致各種問題,包括:

• 資料品質不佳
• 無法使用的應用程式介面
• 支援工作人員的更多疑難排解或「代表訂購」工作階段
• 使用者採用不佳、作用中使用者數量少,且應用程式「捨棄」率高

若要針對 Salesforce 應用程式中尺寸規格之間的互通性設計,請考量下列事項:

• 識別每個應用程式支援的尺寸規格。
• 識別輸入方法和使用者的無障礙需求。請參閱「無障礙」,以取得詳細資訊。
• 盡可能使用 標準功能,在裝置之間提供自適應體驗。
  • 依預設,Salesforce 提供的 Lightning 頁面範本支援不同的尺寸規格。如果您選擇使用 Aura 開發自訂 Lightning 頁面範本,則開發人員必須將尺寸規格資訊納入元件設計檔案。
  • Salesforce 提供的 標準頁面元件會為您處理跨支援尺寸規格的呈現。如果您使用 LWC 或 Aura 建立自訂元件,開發人員將需要處理寬度認知 (Aura 和 LWC 之間有實作差異),並宣告其元件的設計檔案中支援尺寸規格。
• 遵循指引以在所有裝置上使用簡化表單。
• 針對關鍵尺寸規格建立測試計畫 (以及良好的測試)。理想情況下,您會針對所有應用程式測試所有裝置和尺寸規格。然而,針對尺寸規格測試設定正確的裝置 (或裝置模擬器) 可能是一項重大投資。如果您知道某個應用程式或一組應用程式將在行動裝置或平板電腦上擁有大量使用者,請在行動裝置和平板電腦尺寸規格上為這些應用程式排定準確測試的優先順序。

下方的 模式與反模式清單顯示 Salesforce 組織中正確 (與不良) 尺寸的認知。您可以在建立之前使用這些頁面來驗證您的設計,或識別需要重新設計的頁面。

若要深入瞭解有效尺寸規格設計的 Salesforce 工具,請參閱參與相關的 工具。

下表顯示要在組織中尋找 (或建立) 的模式選項,以及要避免或鎖定修復的反模式。

✨ 在「模式與反模式探索器」中探索更多簡化應用程式的模式。

實用的應用程式可讓使用者感到更有能力且更有效,並減少分心或中斷。

實用的應用程式可協助維護 資料完整性,方法是減輕手動錯誤的發生,並在使用者需要時提供回饋意見。它們可協助使用者瞭解他們現在和下次需要專注的動作,並提供相關資訊以協助使用者更快解決自己的問題。它們可提供使用者動作與有意義影響或成就之間的明確連結。

您可以使用三個關鍵習慣建立更實用的應用程式:通知與訊息、應用程式內導覽,以及認可與獎勵。

通知與訊息可協助使用者掌握狀況。

設計良好的通知和傳訊系統可提供使用者及時做出重要決策所需的資訊,藉此提升參與度和生產力。設計不良的通知和傳訊系統 (呈現無關且不及時的訊息) 會產生相反的效果。內部使用者會快速停用或忽略通知,導致他們忽略可能影響重要業務流程的合法訊息。客戶或其他外部使用者很厭倦無意義的通知,可能會決定一併停止使用您的系統。

決定應用程式如何處理傳送通知和訊息給使用者時,請考量下列事項:

• 針對錯誤,請使用通知和訊息作為最後手段。使用後端處理設計系統中的 錯誤處理,此處理可在沒有人力介入的情況下修正特定類型的錯誤。僅傳送關於無法完成工作之重大錯誤的訊息給使用者。同樣地,當業務使用者可以 (且需要) 自行採取一些糾正動作時,只會傳送錯誤訊息。其他錯誤訊息或詳細資料可透過報告提供,並/或使用非同步方法傳送給技術支援人員以進一步追蹤。
• 根據相關性、緊急性和時機性選擇訊息類型。不同類型的訊息具有不同的封鎖或中斷行為層級。通知是訊息的「封鎖」類型,因為它們需要使用者在能夠繼續工作之前予以確認。與錯誤訊息一樣,應謹慎使用通知。快顯通知是非封鎖的,可有不同的持續性行為,並支援不同類型的訊息使用個案。最不明顯的訊息是應用程式內通知或電子郵件。這些最適合用於提供使用者可在其選擇時處理的資訊。
• 考量接下來需要發生的狀況。雖然某些通知具有資訊性 (例如成功訊息),但其他通知可能需要使用者採取某種類型的動作。設計通知時,請務必考量通知本身,以及使用者可能需要採取動作的任何其他資訊。包含使用者可在所有可操作通知中找到其他資訊或完成後續追蹤步驟的明確指示或連結。
• 專注於可讀性。請確保您清楚地傳達每個通知的目的,以及使用者在回應中需要採取的後續步驟。對於不熟悉基本系統內部運作的業務使用者來說,訊息應該可以理解。建立訊息時,請遵循 無障礙標準,並確保訊息已本地化,以支援可能顯示訊息所在區域中的使用者。

在您的 設計標準中包含何時使用通知或不同類型錯誤的模式,以協助確保應用程式產生器遵循一致的作法。

下方的 模式與反模式清單顯示 Salesforce 組織中正確 (與不良) 的通知與傳訊外觀。您可以在建立之前使用這些功能來驗證您的設計,或識別需要重新設計的用途。

若要深入瞭解通知和傳訊的 Salesforce 工具,請參閱參與相關的 工具。

應用程式內導覽可以是消除複雜工作流程神秘性的強大方法 (雖然您應該先確定您已將其最佳化),或協助引導新工作人員。這是以自動化且可調整的方式導入流程變更、醒目提示新功能或散佈訓練的絕佳方法。不過,如果未仔細實作,則應用程式內導覽可能會過度使用。頻繁的快顯視窗或警示可能會為使用者造成大量的雜訊和中斷,進而導致生產力損失。應用程式內導覽也可能會過度使用,導致版本與變更管理流程變得較繁琐 (特別是簡單功能)。最終,應用程式內導覽的過度使用與過低使用都會導致對業務造成許多風險的問題,包括:

• 資料完整性降低
• 使用者錯誤增加
• 使用者挫折度較高且使用者滿意度較低
• 使用者生產力降低

請記住,您可能想要在不同情況下以不同的方式使用應用程式內導覽,因為使用者的心態將會決定指引的程度為「過多」與「不足」。首次導入新系統的使用者,可能需要傳訊的頻率比僅僅要在熟悉系統中瞭解新功能的使用者更高。

以下是建立有效應用程式內導覽的一些關鍵:

• 開發設計標準。請務必記住,過度接觸應用程式內導覽會造成使用者開始定期關閉或忽略訊息。此時應用程式內導覽會變成麻煩,而非資源。定義 設計標準以清楚說明使用提示、逐步解說、欄位級說明文字、驗證訊息、路徑、畫面流程等的時機。
• 建立指引實作的優先順序系統。並非應實作應用程式內導覽的每個使用個案。請考量下列要排定優先順序的問題。您在哪裡可以使用更好的欄位名稱、按鈕上更明確的標籤、更好的格式設計和流程最佳化來建立更直覺的工作流程?在哪裡可以將更實用的文字或連結新增至路徑?應用程式內導覽會有什麼業務成本影響?您想向使用者傳送訊息的頻率為何?此外,請確保任何實作都包含在您的藍圖上,讓所有利害關係人都能看見。
• 將使用者對應至啟用中 (和建議的) 應用程式內導覽。將使用者對應至應用程式內導覽可協助您識別並防止因為使用者顯示的應用程式內導覽過多而導致「實用性過多」。這通常是由於小組對其特定使用個案的考量過於窄窄,因此會產生隔離開發。針對大型組織,對使用者將會接觸的內容維護整體檢視特別重要。在您的藍圖上包含指引實作也有幫助。
• 收集並使用回饋意見以改善。檢閱應用程式內導覽用量的資料,並使用該資料判斷應用程式內導覽部署的效率。請務必為使用者提供方式來同時提供開放式回饋意見,以協助指引產生器。

下方的 模式與反模式清單顯示 Salesforce 組織中適當 (與不良) 的應用程式內導覽外觀。您可以在建立之前使用這些項目來驗證設計,並識別需要重新設計的實作。

若要深入瞭解 Salesforce 工具以用於應用程式內導覽,請參閱與參與相關的 工具。

將認可與獎勵建立在應用程式中,可協助使用該應用程式的個人更熟悉其工作的影響,並進一步瞭解其貢獻、生產力與績效的價值。這也是發揮忠誠度與參與的強大方法。

不針對認可或獎勵應用程式體驗而設計,會造成各種問題,包括:

• 難以瞭解進度或速度的使用者
• 對目標進度或未完成工作的困惑
• 更不具生產力的使用者,無法看見其工作與「全貌」之間的連結
• 浪費在手動、低層級目標報告上的管理時間

獎勵應用程式體驗可能難以設計和提供,因為這些體驗取決於公司文化、原則和標準,以及個別使用者的內容和偏好設定。可幫助桌上型電腦使用者感受到滿意或欣賞的時刻的功能,可能會對行動裝置上的使用者或嘗試從雜亂且忙碌的住家辦公室工作的使用者造成刺激。使用應用程式處理私人或高敏感性資訊的人員可能不喜歡透過碎紙慶祝或徽章的方式進行里程碑的溝通。相反地,散佈式銷售小組可能會將此類遊戲化視為適當的應用程式體驗。最終,您選擇的實作模式最適合透過在小組中與使用者體驗 (UX) 設計師合作來決定。

當涉及結構時,識別應用程式如何以及何處可實作功能,以協助使用者感到受到認可和獎勵很重要。瞭解這些功能如何以及在何處讓應用程式變得較不可重複使用或無法提供真實業務價值也是關鍵。

以下是在 Salesforce 應用程式中評估認可與獎勵時必須考量的一些問題:

• **使用者可以如何以及何處查看自己的進度以及整體小組的統計資料?**報告很重要,但通常會包含可能遺漏日常工作內容的摘要資料。您可以使用如 Lightning 應用程式產生器等工具,在應用程式內容內的記錄畫面上內嵌圖表或顯示面板,協助使用者瞭解其日常工作中的影響或進度。
• **如何辨識使用者?**這可能會因小組或個人偏好設定而有所不同。在某些情況下,上司可能想要查看有關使用者進度的訊息,以便與較大的群組共用這些訊息。認可也可以是協助員工士氣的額外益處。在其他情況下,使用者可能只希望是唯一收到特定工作或專案進度通知的人員。

下方的 模式與反模式清單顯示 Salesforce 組織中正確 (與不良) 的認可與獎勵外觀。您可以在建立之前使用這些項目來驗證設計,並識別需要重新設計的實作。

若要深入瞭解認可和獎勵的 Salesforce 工具,請參閱與參與相關的 工具。

下表顯示要在組織中尋找 (或建立) 的模式選項,以及要避免或鎖定修復的反模式。

✨ 在「模式與反模式探索器」中探索更多有用的應用程式模式。

協助我們讓 Salesforce Well-Architected 與您相關;進行我們的調查以提供此內容的回饋意見,並告訴我們您接下來想要查看的內容。