Läs om våra uppdateringsscheman här.
System visar engagerande beteenden genom att göra det enkelt för användare att komma åt och använda appar, få användare att känna att de får mer högkvalitativt arbete gjort och få användare att vilja använda appar i systemet.
Att leverera engagerande beteenden är viktigt för verksamheten eftersom det direkt korrelerar till användaranvändning samt övergripande nöjdhet för medarbetare och kunder. Engagerande beteenden hjälper även till att minska supportbegäranden och kan hjälpa till att höja kvaliteten på funktionsbegäranden från användare.
En av utmaningarna med att skapa engagerande beteenden är att det är svårt att mäta med enbart objektiva mått. Istället mäts det av användarnas subjektiva upplevelser. Användare känner att engagerande appar ger verkligt värde. Engagerande appar är tillgängliga, icke-påträngande och enkla att förstå. De kräver minimal introduktion och utbildning. Och de använder tydliga metoder för att proaktivt förhindra användarfel.
En annan utmaning är att engagemangsmålen ofta varierar med de olika typerna av användarinteraktioner i ditt system. Du kan till exempel ha en uppsättning mål för interna användare som hanterar kundcase och en annan för externa användare som skickar information via ett formulär på din webbplats. För att utforma engagerande system måste du noga överväga vilken typ av engagemang du försöker skapa och varför användare vill engagera sig innan du börjar sammanställa funktioner och sidor.
Att samarbeta med designers för användarupplevelser (UX) hjälper dig att fatta mycket mer effektiva beslut när det gäller att leverera engagerande appar. Ur ett arkitektoniskt perspektiv är användaranvändning och -bevarande viktiga komponenter i ett sunt system. Engagerande arkitekturer minskar sannolikheten för Problem med datakvaliteten orsakade av att användare skyndar sig genom processer eller hoppar över steg för att undvika att behöva tillbringa tid i ett system som de inte gillar att använda. För externa system kan en engagerande arkitektur öka intäkterna och behålla kunder när kunder som tycker att dina system är enklare att arbeta med väljer att göra fler affärer med din organisation.
Du kan skapa mer engagerande appar genom att fokusera på att leverera effektiva och hjälpsamma upplevelser.
Strömlinjeformade appar är enkla att navigera, presenterar information och datainmatningsuppgifter tydligt och anpassar sig för att passa olika formulärfaktorer. Strömlinjeformade appar har även upplevelsemönster som användare har vant sig vid i andra vanliga program. Till exempel presenterar de flesta webbläsare "öppna i ny flik" som det översta alternativet när användare högerklickar på en länk. En effektiviserad app som innehåller flikar följer samma mönster.
Påverkan av ineffektiva appupplevelser kan sträcka sig långt utöver en enskild app. Dåliga appupplevelser urholkar användarnas Trust. När fler typer av affärskritiska och kundanpassade appar flyttar till digitala kanaler kan detta kosta företag lojaliteten hos viktiga intressenter.
Du kan effektivisera dina appar bättre genom att vara medveten om hur du hanterar appkomplexitet, formulärdesign och formulärfaktorer.
Att minimera programmets komplexitet innebär att användare endast ser relevanta menyobjekt, flikar och navigeringskontroller. Du måste skapa mappningar mellan användargrupper, användarbehörigheter och rätt appupplevelse. Använd dessa mappningar för att förstå vilken appupplevelse som ska presenteras för en användare och se sedan till att din app har de logiska kontroller som behövs för att leverera den upplevelsen.
Appar som presenterar användare med för mycket komplexitet kan orsaka olika dåliga upplevelser:
- Användare ser ofta onödiga eller irrelevanta flikar, går till tomma skärmar och stöter på inaktiverade eller blockerade länkar.
- Onödiga eller ohjälpsamma instruktioner som "ignorera denna flik om din roll är X..." visas i utbildnings- och aktiveringsmaterial.
- Röriga navigeringsmenyer tvingar användare att lägga extra tid på att hitta de objekt de behöver för att få jobbet gjort.
Dessa dåliga upplevelser leder till låga användningsresultat och nöjdhetsnivåer.
Tänk på följande när du avgör rätt nivå av appkomplexitet:
- Organisera menyer, flikar och andra navigeringskontroller baserat på prioriteten för det arbete användare behöver utföra.
- Undvik att introducera nya beteenden som en användare måste lära sig enbart så att de kan använda din app.
- Ta inte bort åtkomst till funktioner som låter användare anpassa aspekter av sitt användargränssnitt.
- Använd behörighetsuppsättningar för att ge utökade eller minskade navigeringsalternativ.
- Förenkla tilldelningar av Lightning-sidor. Minimera antalet aktiva Lightning sidor per app. Använd dynamiska formulär, behörighetsuppsättningar och villkorlig återgivning för att lägga till objekt på Lightning i din app. Gör detta istället för att underhålla flera Lightning, aktiverade och tilldelade efter profil.
Listan över mönster och antimönster nedan visar hur korrekt (och dålig) hantering av appkomplexitet ser ut i en Salesforce-organisation. Du kan använda dessa för att validera eller förbättra din programdesign.
Mer information om Salesforce-verktyg som kan hjälpa dig hantera komplexitet i program finns i Verktyg relevanta för engagemang.
Strömlinjeformade formulär organiserar information i logiska sekvenser, stöder snabb datainmatning och minimerar obligatoriska steg. De tillåter även hjälpsamma valideringsmeddelanden på klientsidan och eliminerar upprepade formulärinskickningscykler.
Tänk på följande när du utformar formulär:
- Gruppera relaterade fält. Gruppfält relaterade till samma steg i en process eller datainmatningsuppgift. Uteslut fält som inte är direkt relevanta för den aktuella uppgiften.
- Placera datainmatning och validering tidigt. Fält som kräver att användare anger data bör visas tidigt i dina formulär. Det rekommenderas att lyfta fram problem med dataformatering eller data som saknas på fältnivå och så snabbt som möjligt (det vill säga innan en användare försöker navigera till nästa steg eller skicka formuläret). Undvik även att visa fältnivåfel innan användare har haft möjlighet att ange data i fälten.
- Minimera datainmatningsuppgifter. Fyll i eller fyll i så många fält som möjligt automatiskt för att minimera datainmatningsfel och förbättra effektiviteten. Be endast användare att ange data som är viktiga eller viktiga. Uteslut alla datainmatningar som inte är relevanta för den aktuella verksamhetsprocessen. Använd kombinationsrutor istället för friformtextfält där det är möjligt för att tillämpa val av giltiga alternativ och minska variationer av samma svar.
- Minimera inskickningar till servern. Låt inte flerstegsformulär skicka data till servern flera gånger. Se till att alla egna LWC- eller Aura-komponenter använder cachning på klientsidan för att hantera navigering eller pagineringsåtgärder. (Salesforce Lightning Experience och Salesforce-mobilappen använder cachning på klientsidan som standard.) Utforma formulär så att användare endast skickar data till servern en gång. Validera användarinmatningar på klientsidan innan formulär skickas in. Detta minimerar oavsiktliga användarinskickningar, förhindrar dubbletter eller smutsiga transaktioner från att konsumera bandbredd i backend och hjälper dig utforma för bättre datahantering.
- Hantera formulärstatus. Cachning på klientsidan hjälper inte bara till med beteenden som navigering och paginering, det hjälper även till att minimera dataförluster från tillfälliga anslutningsproblem. Effektiv hantering av status innebär även att appar kan orkestrera datainskickning till servern på lämpligt sätt och förhindra dubbletter av transaktioner, samt presentera relevanta och snabba meddelanden för användare baserat på status för åtgärder på serversidan. Strömlinjeformade formulär skickar endast in dataoperationer en gång och kräver inte att användare väntar på att långa operationer på servern ska slutföras.
- Följ tillgänglighetsstandarder. För att maximera målgruppen för dina appar och hjälpa till att säkerställa att de inkluderar alla dina kunder, tillämpa standarder för tillgänglighet i dina formulärdesigner.
Effektiviserade formulär hjälper till att öka dataintegriteten i dina appar och hur hjälpsamma dina appar är för användarna. De kan även minska supportärenden och begäranden, eftersom användare har bättre möjlighet att åtgärda fel och tydligt förstå statusen för sina formulärinskickningar. Effektiva formulär möjliggör snabb och effektiv datainmatning och säkerställer att användare inte behöver vänta på att processer som körs längre för att utföra ytterligare arbete.
Listan över mönster och antimönster nedan visar hur korrekt (och dålig) formulärdesign ser ut i en Salesforce-organisation. Du kan använda dessa för att validera eller förbättra dina formulärdesigner.
Mer information om Salesforce-verktyg som kan hjälpa dig bygga mer effektiva formulär finns i Verktyg relevanta för engagemang. Mer specifik vägledning om att välja rätt formulärverktyg för ditt användningsfall finns i Arkitektens beslutsguide för att bygga formulär med Salesforce.
Engagerande appar anpassas smidigt till olika enheter och interaktionstyper, eller formulärfaktorer. Beroende på enhetstyp blir olika typer av användarinteraktioner enklare (eller svårare) och läsbarheten för formulär och fält ändras. Kom ihåg att formulärfaktor utöver skärmdimensioner även refererar till hur dina användare interagerar med skärmen. Allt fler enheter har nu pekskärmar och vissa användare kan även använda speciella enheter för tillgänglighet. Tänk på dessa faktorer när du utformar formulär.
Att inte ta hänsyn till formulärfaktorvariationer kan leda till flera olika problem, inklusive:
- Dålig datakvalitet
- Oanvändbara appgränssnitt
- Fler felsöknings- eller "beställa på uppdrag"-sessioner för supportagenter
- Dålig användaranvändning, lågt antal aktiva användare och hög andel appavbrott
För att utforma för interoperabilitet mellan formulärfaktorer i dina Salesforce-appar, tänk på följande:
- Identifiera formulärfaktorer som stöds för varje app.
- Identifiera inmatningsmetoder och tillgänglighetsbehoven för dina användare. Se Tillgänglighet för mer information.
- Använd standardfunktionalitet för att ge anpassningsbara upplevelser på alla enheter när så är möjligt.
- Lightning-sidmallar som tillhandahålls av Salesforce har stöd för olika formulärfaktorer som standard. Om du väljer att utveckla egna Lightning med Aura måste utvecklare införliva information om formulärfaktorer i komponentdesignfilen.
- Standardsidkomponenter som tillhandahålls av Salesforce hanterar återgivning över formulärfaktorer som stöds åt dig. Om du skapar egna komponenter med LWC eller Aura måste utvecklare hantera breddmedvetenhet (det finns implementeringsskillnader mellan Aura och LWC) och deklarera stöd för formulärfaktorer i designfilen för sina komponenter.
- Följ riktlinjerna för effektiva formulär på alla enheter.
- Skapa testplaner (och bra tester) för viktiga formulärfaktorer. Det bästa är om du testar för alla enheter och formulärfaktorer för alla dina appar. Att konfigurera rätt enheter (eller enhetssimulatorer) för formulärfaktortester kan dock vara en stor investering. Om du vet att en viss app eller uppsättning appar kommer att ha en betydande uppsättning användare på mobil eller surfplatta, prioritera korrekta tester för dessa appar på mobil och surfplatta.
Listan över mönster och antimönster nedan visar hur korrekt (och dålig) medvetenhet om formulärfaktorer ser ut i en Salesforce-organisation. Du kan använda dessa för att validera din design innan du bygger, eller identifiera sidor som behöver omfaktoriseras.
Mer information om Salesforce-verktyg för effektiv utformning av formulärfaktorer finns i Verktyg relevanta för engagemang.
Följande tabell visar ett urval av mönster att leta efter (eller bygga) i din organisation och antimönster att undvika eller rikta in sig på för att åtgärda.
✨ Upptäck fler mönster för effektiviserade appar i Mönster & Anti-Mattern Explorer.
| Mönster | Anti-Patterns | |
|---|---|---|
| Appkomplexitet | I din organisation:
- Appar har färre än 10 flikar i den admin-tillhandahållna standardkonfigurationen - Inga appar har "Inaktivera slutanvändaranpassning av navigeringsobjekt i denna app" inställd på sant |
I din organisation:
- Appar har rutinmässigt mer än 10 flikar i den admin-tillhandahållna standardkonfigurationen - Många appar har "Inaktivera personanpassning av navigeringsobjekt i denna app" inställd på sant eller behörighet att anpassa navigeringsobjekt är inaktiverat i hela organisationen |
| Formulär | I dina appar:
- Fält följer logiska grupperingar - Datainmatningsfält visas tillsammans, i grupper om fem eller färre - Datainmatningsfel är tydliga och visas på fältnivå, innan användare navigerar bort eller skickar data - Sidokontroller möjliggör förflyttning mellan steg - Datainskickning sker en gång - Etiketter för åtgärder och navigering är tydliga - Snabb och visuell feedback ges för att bekräfta användaråtgärder som knappklick - Navigeringsknappar (till exempel "gå", "nästa" och "tillbaka") placeras enhetligt i hela användargränssnittet |
I dina appar:
- Datainmatningsfält grupperas inte logiskt, vilket kräver en omfattande mängd sammanhangsväxling av användare som fyller i formulär - Datainmatningsfel innehåller kryptisk information som endast kan tolkas av någon som förstår systemets interna funktion - Datainmatningsfel visas endast när ett formulärs skicka-knapp klickas - Steg och grupperingar är inte tydligt definierade, vilket gör navigering svårt - Datainskickning sker flera gånger under datainmatningsprocessen - Etiketter för åtgärder och navigering är förvirrande för användare som inte är bekanta med underliggande systemfunktionalitet - Visuellt erkännande av användaråtgärder tillhandahålls inte - Navigeringsknappar visas på godtyckliga platser i hela användargränssnittet |
| I din formulärlogik:
- Fält är förifyllda eller automatiskt ifyllda så mycket som möjligt - Användare behöver inte vänta på att långvariga åtgärder på serversidan ska slutföras - Egna komponenter använder cacheable=true för serverbaserade åtgärder som inte involverar dataoperationer
- Dataoperationer utförs en gång - I LWC @ trådkort hanterar alla åtgärder som inte involverar dataoperationer |
I din formulärlogik:
- Fält som kan vara förifyllda eller automatiskt ifyllda kräver manuell inmatning - Användare måste sluta arbeta under inskickningsprocessen för att vänta på åtgärder på serversidan att slutföras - Egna komponenter inställda cacheable=false |
|
| Formfaktor | I din organisation:
- Lightning sidmallar som tillhandahålls av Salesforce används för alla eller de flesta sidor - Egna Lightning-sidmallar använder design:supportedFormFactors och design:supportedFormFactor i Aura-komponentdesignfiler
- Egna LWC- eller Aura-komponenter tillgängliga i Appbyggaren deklarerar formulärfaktorer som stöds i sina respektive designfiler och implementerar breddmedvetna stylingmönster |
I din organisation:
- Classic är fortfarande aktiv - Egna Lightning-sidmallar använder inte design:supportedFormFactors och design:supportedFormFactor enhetligt i Aura-komponentdesignfiler.
- Egna LWC- eller Aura-komponenter som är tillgängliga i Appbyggaren deklarerar inte konsekvent formulärfaktorer som stöds i sina respektive designfiler - I egna LWC- eller Aura-komponenter implementeras inte breddmedveten styling av Salesforce-tillhandahållna gränssnitt - I egna LWC- eller Aura-komponenter drivs stil för olika formulärfaktorer endast av hårdkodade px- eller %-värden i CSS |
| På skrivbord:
- Datainmatningsfält och navigeringskontroller passar på skärmen och kan interageras med som avsett - Post- och appsidor visas korrekt, baserat på tilldelningsregler för sidaktivering |
På skrivbord:
- Datainmatningsfält och navigeringskontroller visas inte på sina avsedda platser på skärmen - Interaktioner med datainmatningsfält och navigeringskontroller matchar inte obligatoriska beteenden - Avsaknad av tilldelningsregler för sidaktivering innebär att alla användare ser samma post- och appsidor |
|
| På mobil och surfplatta:
- Datainmatningar och navigeringskontroller visas korrekt - Användare kan enkelt mata in data - Mobilnavigeringsmenyer, optimerade för mindre formulärfaktorer, visas - Komprimerade layouter visas på postnivå |
På mobil och surfplatta:
- Datainmatningar och navigeringskontroller återges inte konsekvent eller korrekt - Användare kan inte mata in data enkelt - Mobilnavigeringsmenyer skiljer sig inte från skrivbordsnavigering - Komprimerade layouter är inte konfigurerade på postnivå |
Användbara program låter användare känna sig mer kraftfulla och effektiva, med färre distraktioner eller avbrott.
Användbara program hjälper till att upprätthålla dataintegritet genom att minska manuella fel och ge feedback till användare när och där de behöver det. De hjälper användare förstå vilka åtgärder de behöver fokusera på nu och nästa gång, och ger relevant information för att hjälpa användare lösa sina egna problem snabbare. De ger en tydlig länk mellan en användares åtgärder och meningsfull påverkan eller prestationer.
Du kan bygga mer hjälpsamma program med tre nyckelvanor: notiser och meddelanden, vägledning i appen och erkännande och belöningar.
Notiser och meddelanden hjälper användare att hålla sig informerade.
Ett väl utformat notis- och meddelandesystem kan öka engagemanget och produktiviteten genom att ge användare den information de behöver för att fatta viktiga beslut i rätt tid. Ett dåligt utformat notis- och meddelandesystem – ett som presenterar meddelanden som varken är relevanta eller aktuella – kommer att få motsatt effekt. Interna användare kommer snabbt att inaktivera eller ignorera notiser, vilket gör att de missar legitima meddelanden som kan påverka viktiga verksamhetsprocesser. Kunder eller andra externa användare som tröttnar på meningslösa notiser kan besluta att sluta använda dina system helt och hållet.
Tänk på följande när du bestämmer hur appar ska hantera att skicka notiser och meddelanden till användare:
- Använd notiser och meddelanden som en sista utväg vid fel. Utforma felhanteringen i ditt system med backendbearbetning som kan korrigera vissa typer av fel utan mänsklig inblandning. Skicka endast meddelanden till användare om kritiska fel som hindrar dem från att utföra uppgifter. På samma sätt kan du endast skicka felmeddelanden till företagsanvändare om det finns några korrigerande åtgärder som de kan (och behöver) vidta själva. Ytterligare felmeddelanden eller detaljer kan göras tillgängliga via rapporter och/eller skickas till teknisk supportpersonal med asynkrona metoder för ytterligare uppföljning.
- Välj meddelandetyper baserat på relevans, brådska och aktualitet. Olika typer av meddelanden har olika nivåer av blockerande eller avbrytande beteende. Meddelanden är en "blockerande" typ av meddelanden, eftersom de kräver att användare bekräftar dem innan de kan fortsätta sitt arbete. Precis som med felmeddelanden ska meddelanden användas sparsamt. Toastnotiser är icke-blockerande, kan ha olika persistensbeteenden och har stöd för olika typer av meddelandeanvändning. De minst påträngande meddelandena är notiser i appen eller e-postmeddelanden. Dessa används bäst för att leverera information som användare kan hantera när och som de vill.
- Överväg vad som behöver hända härnäst. Vissa notiser är informativa (till exempel framgångsmeddelanden), men andra kan kräva att användare utför någon typ av åtgärd. När du utformar notiser, se till att inte bara tänka på notisen i sig, men all ytterligare information som en användare kan behöva vidta åtgärder. Inkludera tydliga instruktioner eller länkar till var användare kan hitta ytterligare information eller utföra uppföljningssteg i alla användbara notiser.
- Fokus på läsbarhet. Se till att du tydligt kommunicerar varje notis syfte och nästa steg en användare behöver vidta som svar. Meddelanden ska vara begripliga för företagsanvändare som inte är bekanta med de underliggande systemens inre. När du skapar meddelanden, följ tillgänglighetsstandarder och se till att de är lokaliserade för att stödja användare i de regioner där de kan visas.
Inkludera mönster för när notiser eller olika typer av fel ska användas i dina designstandarder för att hjälpa till att säkerställa att appbyggare följer enhetliga metoder.
Listan över mönster och antimönster nedan visar hur korrekta (och dåliga) notiser och meddelanden ser ut i en Salesforce-organisation. Du kan använda dessa för att validera din design innan du bygger, eller identifiera användningar som behöver omfaktoriseras.
Mer information om Salesforces verktyg för notiser och meddelanden finns i Verktyg relevanta för engagemang.
Vägledning i appen kan vara ett kraftfullt sätt att avmystifiera komplexa arbetsflöden (men du bör se till att du har optimerat dem först) eller hjälpa till att introducera ny personal. Det kan vara ett bra sätt att introducera processändringar, lyfta fram nya funktioner eller distribuera utbildning på ett automatiserat och skalbart sätt. Om det inte implementeras noggrant kan vägledning i appen dock överanvändas. Frekventa popup-fönster eller varningar kan skapa en enorm mängd brus och avbrott för användare, vilket leder till förlorad produktivitet. Vägledning i appen kan också underutnyttjas, vilket resulterar i mer tungrodda processer för release och ändringshantering (särskilt för enkla funktioner). I slutändan leder både överanvändning och underanvändning av vägledning i appen till ett antal problem som utgör risker för verksamheten, inklusive:
- Lägre dataintegritet
- Ökade användarfel
- Högre frustrationsnivåer och lägre användarnöjdhet
- Lägre användarproduktivitet
Kom ihåg att du kanske vill använda vägledning i appen på olika sätt i olika scenarion, eftersom en användares inställning avgör hur mycket vägledning som är "för mycket" jämfört med "inte tillräckligt". Användare som introduceras till ett nytt system för första gången kommer troligen att behöva mer frekventa meddelanden än användare som bara lär sig om en ny funktion i ett system de redan är bekanta med.
Här är några nycklar för att skapa effektiv vägledning i appen:
- Utveckla designstandarder. Det är viktigt att komma ihåg att överexponering för vägledning i appen kan göra att användare rutinmässigt börjar avvisa eller ignorera meddelanden. Vid denna tidpunkt blir vägledning i app ett irritationsmoment, snarare än en resurs. Definiera designstandarder för att tydliggöra när du ska använda uppmaningar, genomgångar, hjälptext på fältnivå, valideringsmeddelanden, vägar, skärmflöden och så vidare.
- Skapa ett prioriteringssystem för vägledningsimplementeringar. Inte alla användningsfall för vägledning i app ska implementeras. Tänk istället på följande frågor att prioritera. Var kan du helt enkelt använda bättre fältnamn, tydligare etiketter på knappar, bättre formulärdesign och processoptimering för att skapa mer intuitiva arbetsflöden? Var kan du lägga till mer hjälpsam text eller länkar till en väg? Vilken påverkan på affärskostnader kommer vägledning i app att ha? Hur ofta vill du leverera meddelanden till dina användare? Se även till att eventuella implementeringar inkluderas i din vägkarta så att alla intressenter har synlighet.
- Mappa användare till aktiv (och föreslagen) vägledning i appen. Att mappa användare till vägledning i app hjälper dig identifiera och förhindra "överbelastning av hjälpsamhet" på grund av att för mycket vägledning i app visas för en användare. Ofta är detta resultatet av simulerad utveckling, eftersom team tänker för snävt på sitt specifika användningsfall. Att ha en helhetsbild av vad användare kommer att exponeras för är särskilt viktigt för stora organisationer. Att inkludera vägledningsimplementeringar på din vägkarta kan också hjälpa.
- Samla in och använd feedback för att förbättra. Gå igenom data om användningen av vägledning i app och använd dem för att bedöma effektiviteten hos distribueringar av vägledning i app. Se till att tillhandahålla sätt för användare att även ge öppen feedback för att hjälpa byggare av vägledning.
Listan över mönster och antimönster nedan visar hur korrekt (och dålig) vägledning i appen ser ut i en Salesforce-organisation. Du kan använda dessa för att validera designer innan du bygger, och identifiera implementeringar som behöver omfaktoriseras.
Mer information om Salesforces verktyg för vägledning i appen finns i Verktyg relevanta för engagemang.
Att bygga in erkännanden och belöningar i en app hjälper de personer som använder appen att känna sig mer kopplade till påverkan av sitt arbete och bättre förstå värdet av deras bidrag, produktivitet och resultat. Det är också ett kraftfullt sätt att låsa upp lojalitet och engagemang.
Att inte designa för erkännande eller belöna appupplevelser kan bidra till en rad olika problem, inklusive:
- Användare som kämpar för att förstå sina framsteg eller hastighet
- Förvirring om framsteg till mål eller oavslutat arbete
- Mer oproduktiva användare, som inte ser en koppling mellan sina uppgifter och den "större bilden"
- Hanteringstid bortkastad på manuell målrapportering på låg nivå
Att belöna appupplevelser kan vara svårt att utforma och leverera, eftersom de beror på företagskultur, policyer och standarder samt enskilda användares sammanhang och preferenser. Funktioner som kan hjälpa skrivbordsanvändare att känna glädje eller uppskattning kan bli en irritation för en användare på mobil eller en användare som försöker arbeta från ett bullrigt, hektiskt hemmakontor. Personer som använder en app för att arbeta med information som är privat eller mycket känslig kanske inte uppskattar kommunikation om milstolpar i form av konfettifirande eller märken. Ett distribuerat säljteam kan däremot se en sådan spelifiering som en lämpligt givande appupplevelse. I slutändan avgörs de implementeringsmönster du väljer bäst genom att arbeta med designers för användarupplevelser (UX) i ett team.
När det gäller arkitektur är det viktigt att identifiera hur och var appar kan implementera funktioner som hjälper användare att känna igen sig och belönas. Det är också viktigt att förstå hur och var dessa funktioner kan göra appar mindre återanvändbara eller ta bort från att leverera verkligt verksamhetsvärde.
Här är några frågor att tänka på vid utvärdering av erkännanden och belöningar i Salesforce-appar:
- Hur och var kan användare se sina egna framsteg, samt övergripande teamstatistik? Rapporter är viktiga, men de innehåller ofta sammanfattningsdata som kan missa sammanhanget i det dagliga arbetet. Du kan använda ett verktyg som Lightning för att bädda in diagram eller instrumentpaneler på postskärmar i en apps sammanhang, vilket hjälper användare förstå deras påverkan eller framsteg medan de utför sina dagliga uppgifter.
- Hur ska användare kännas igen? Detta kan variera beroende på team eller individuella inställningar. I vissa fall kanske arbetsledare vill se meddelanden om användarförlopp så att de kan delas med en större grupp. Erkännande kan även vara en extra fördel för att hjälpa till med medarbetares moral. I andra fall kanske användare föredrar att vara de enda som meddelas om hur det går för en viss uppgift eller ett visst projekt.
Listan över mönster och antimönster nedan visar hur korrekt (och dåligt) erkännande och belöningar ser ut i en Salesforce-organisation. Du kan använda dessa för att validera designer innan du bygger, och identifiera implementeringar som behöver omfaktoriseras.
Mer information om Salesforces verktyg för erkännande och belöningar finns i Verktyg relevanta för engagemang.
Följande tabell visar ett urval av mönster att leta efter (eller bygga) i din organisation och antimönster att undvika eller rikta in sig på för att åtgärda.
✨ Upptäck fler mönster för hjälpsamma appar i Mönster & Anti-Mattern Explorer.
| Mönster | Anti-Patterns | |
|---|---|---|
| Notiser och meddelanden | Dina designstandarder inkluderar:
- Godkända användningsfall för notiser, toasts och notiser - Designmönster för toastvarianter och notiser - Designmönster för felmeddelanden |
Om designstandarder har definierats alls hanterar de inte fel och notiser |
| I din organisation:
- Notiser är det dominerande meddelandeformatet - Toast meddelanden använder varianter - Toast meddelanden med läget inställt på klibbig finns inte
- Notiser används sällan, om alls - Generativa svar identifierar alltid datakällor som används - Botar identifierar sig tydligt innan den första interaktionen med användare - Ansvarsfriskrivning för risker associerade med generativ AI visas för användare innan första interaktion - AI ansvarsfriskrivningar är på ett tydligt och begripligt språk för användare |
I din organisation:
- E-postmeddelanden är det dominerande meddelandeformatet - Det finns ingen konsekvent inställning till meddelandetyper - Toast meddelanden använder inte konsekvent varianter - Rosta meddelanden med läget inställt på klibbig finns
- Meddelanden används ad hoc - Generativa svar identifierar inte datakällor som används - Botar identifierar sig inte tydligt innan den första interaktionen med användare - Inga ansvarsfriskrivningar för generativa AI-risker visas för användare - AI ansvarsfriskrivningar är inte på ett tydligt och begripligt språk för användare |
|
| I dina appar:
- Inga genererande svar skickas direkt till slutanvändare utan punkter av mänsklig inblandning |
I dina appar:
- Generativa svar skickas direkt till slutanvändare utan punkter av mänsklig inblandning |
|
| Se även: Felhantering | ||
| Vägledning i app | Dina designstandarder och dokumentation inkluderar:
- Godkända användningsfall för vägledning i app - Design mönster för uppmaningar och genomgångar - En tydlig matris av användare, appar och aktiv vägledning i appen |
Om det finns konstruktionsstandarder och dokumentation:
- Inte hantera vägledning i app - Inkludera inte en tydlig matris som visar användare, appar, aktiv vägledning i app |
| I din organisation:
- Inställningen "Fördröjning mellan vägledning i app" använder standardvärdet eller ett eget värde som är längre än standardperioden (24 timmar) som tillhandahålls av Salesforce - Inga appar har mer än en aktiv genomgång - Inga genomgångar har en "Tider att visa" inställning som är högre än 10 - Inga uppmaningar är aktiverade för "någon sida, någon app" eller "Denna sida, någon app" |
I din organisation:
- Inställningen för "Fördröjning mellan vägledning i app" är inställd på en period som är kortare än standardperioden (24 timmar) som tillhandahålls av Salesforce - Appar har mer än en aktiv genomgång - Många genomgångar har en "Tider att visa" inställning som är högre än 10 (och vissa har det högsta värdet på 30) - Uppmaningar aktiveras ad hoc, många med inställningen "Alla sidor, alla appar" eller "Denna sida, alla appar" |
|
| Erkännande och belöningar | I din organisation:
- Appar använder inbäddade analyser för att visa användare relevanta målförlopp och produktivitetsstatistik - Vägfirande aktiveras endast med användarens samtycke - Notiser och meddelanden inkluderar användarigenkänning och återspeglar användarpreferenser i utformningen av vem som meddelas och vad som utlöser notiser |
I din organisation:
- Analytics relaterade till målförlopp och produktivitetsstatistik är endast tillgängliga i rapporter eller chefsinstrumentpaneler - Vägfirande aktiveras utan att kontrollera för användarens samtycke - Notiser och meddelanden inkluderar inte någon form av användarigenkänning eller återspeglar inte användarnas preferenser och känns bullriga eller gimmicky |
| Verktyg | Beskrivning | Strömlinjeformad | Hjälpsam |
|---|---|---|---|
| Aktivera din Lightning App-sida | Hantera sidans tillgänglighet, namn, synlighet och positionering | X | |
| Instrumentpaneler för användning | Granska inloggningshistorik, funktionsanvändning och produktivitet | X | X |
| Varning | Bestående varningar över sessioner och visa dem utan användarinitiering | X | |
| Cachning av Apex metodresultat på klientsidan | Utvärdera prestanda med cachade data på klientsidan | X | |
| Dynamiska formulär | Visa endast obligatoriska fält och sidsektioner för användare | X | |
| Engagemangsinsikter | Övervaka senaste användaraktivitet och vidta åtgärder efter behov | X | X |
| Vägledning i app | Använd uppmaningar och genomgångar för utbildning och introduktioner | X | |
| Inlärningssökvägar | Personanpassa användarupplevelser | X | |
| Lightning Appbyggare | Skapa egna mobil- och Lightning utan kod | X | |
| Lightning Data Service | Cacha och dela data mellan komponenter | X | |
| Lightning Design Systemvaliderare för VS Code | Validera kod mot SLDS riktlinjer | X | X |
| Lightning sidmallar | Bygg Lightning Sidor för olika formulärfaktorer | X | |
| Sökfilter | Filtrera värden för sökning, huvud-detalj och hierarkiska relationer | X | |
| Hantera flera valutor | Använd flera valutor i transaktioner | X | |
| Meddelanden | Skicka SMS, Facebook Messenger eller WhatsApp-meddelanden | X | |
| Mobile Publisher | Skapa mobilversioner av Lightning och Experience Cloud-webbplatser | X | |
| Mobilfärdiga komponenter | Bygg komponenter som fungerar bra över mobila upplevelser | X | |
| Flerspråkiga webbplatser | Skapa olika språkversioner av din webbplats | X | X |
| Notisbyggaren | Skapa egna notiser för att presentera information | X | |
| Väg | Guida användare genom verksamhetsprocesser och fira framgång | X | X |
| Plattformscache | Förbättra prestanda och pålitlighet vid cachning av data | X | |
| Förhandsgranska mobilappsidor i Lightning-appbyggaren | Förhandsgranska post- och appsidor på en mobil enhet | X | |
| Uppmaning | Varna användare om systemrelaterade problem och uppdateringar | X | |
| Erkännandemärken | Uppmärksamma och fira användares prestationer | X | |
| Igenkänning med WDC | Stöd kompetens och tacka | X | |
| Posttyper | Personanpassa verksamhetsprocesser, kombinationsrutevärden och sidlayouter | X | X |
| Översikt av anseende | Erkänn deltagande och Knowledge sharing | X | |
| Begränsningsregler | Hindra användare från att komma åt poster som kan innehålla onödiga data | X | |
| Standardsidkomponenter | Förstå standardkomponenterna i Salesforce Lightning | X | |
| Översättningar | Hantera översättningar för globala användare | X | X |
| Valideringsregler | Kontrollera att data uppfyller specificerade standarder innan du sparar | X |
| Resurs | Beskrivning | Strömlinjeformad | Hjälpsam |
|---|---|---|---|
| Arkitektens guide till byggnadsformulär | Utvärdera överväganden för formulärdesign och välj det bästa verktyget | X | |
| Konfigurera din komponent för olika formulärfaktorer | Konfigurera komponenter att återge i stationära datorer och telefoner | X | |
| Anpassa hjälpinnehåll | Skräddarsy hjälpinnehåll för din unika implementering | X | |
| Standardfältvärden | Definiera standardvärden, dynamiska eller statiska fältvärden | X | |
| Utformningsriktlinjer | Skapa användargränssnitt som överensstämmer med rekommenderade metoder | X | X |
| Designstandardmall | Skapa designstandarder för din organisation | X | X |
| Utforma provningskompetens ( Trailhead) | Planera metoder för att validera och testa en design | X | X |
| Riktlinjer för feedback i app | Gå igenom riktlinjer för att samla in feedback från ditt system | X | X |
| Lightning Design-systemets statiska bibliotek för Android | Bygg inbyggda Android-appar med samma utseende och känsla som Lightning | X | |
| Lightning Design System iOS statiskt bibliotek | Bygg inbyggda iOS-appar med samma utseende och känsla som Lightning | X | |
| Meddelanderiktlinjer | Kommunicera relevant information och skapa stunder av glädje | X | |
| Meddelandetyper | Förstå de olika meddelandetyperna baserat på användarinteraktion | X | |
| Navigeringsriktlinjer | Hjälp användare flytta mellan sidor och hitta sig själva i en app | X | |
| Test för webbtillgänglighet ( Trailhead) | Använd automatiserade och manuella tester för att säkerställa tillgänglighet | X | X |
| Riktlinjer för användarengagemang | Gå igenom riktlinjer för introduktion, användning, hjälp och utbildning | X | X |
Hjälp oss hålla Salesforce Well-Architected relevant för dig. Gå igenom vår undersökning för att ge feedback om detta innehåll och berätta vad du vill se härnäst.