Jeg er sikker på at du har hørt om streker eller brukt en app med en. Men noen gang lurt på hvorfor striper er så populære og kraftige? Vel, det er det åpenbare at apper vil ha så mye av oppmerksomheten som mulig, men bortsett fra det, visste du at da den populære læringsappen Duolingo introduserte iOS-widgets for å vise streker, økte brukerengasjementet med 60 %. Seksti prosent er en massiv endring i atferd og demonstrerer hvordan "streak"-mønstre kan brukes til å øke engasjementet og øke bruken. På det mest grunnleggende er en strek antallet påfølgende dager som en bruker fullfører en spesifikk aktivitet. Noen mennesker definerer det også som en "gamified" vane eller en beregning designet for å oppmuntre til konsekvent bruk. Men streker overskrider det å være en metrikk eller en post i en app; det er mer psykologisk enn som så. Menneskelige instinkter er lette å påvirke med de riktige faktorene. Se på disse tre faktorene: fremgang, stolthet og frykt for å gå glipp (ofte kalt FOMO). Hva har alle disse til felles? Anstrengelse. Jo mer innsats du legger ned i noe, jo mer former det identiteten din, og det er slik streker krysser inn i atferdspsykologiens verden. Nå, med stor makt følger stort ansvar, og på grunn av det er det en mørk side ved streker. I denne artikkelen skal vi gå inn på psykologien, UX og designprinsippene bak å bygge et effektivt streksystem. Vi skal se på (1) hvorfor hjernen vår nesten instinktivt reagerer på strekaktivitet, (2) hvordan man utformer streker på måter som virkelig hjelper brukerne, og (3) det tekniske arbeidet som er involvert i å bygge et strekmønster. Psykologien bak streker For å designe og bygge et effektivt streksystem, må vi forstå hvordan det stemmer overens med hvordan hjernen vår er kablet. Som, hva gjør det så effektivt i den grad at vi føler så mye intens dedikasjon til å beskytte strekene våre? Det er tre interessante, veldokumenterte psykologiprinsipper som støtter det som gjør streker så kraftige og vanedannende. Tapsaversjon Dette er sannsynligvis den sterkeste kraften bak streker. Jeg sier dette fordi du de fleste ganger nesten ikke kan unngå dette i livet. Tenk på det på denne måten: Hvis en venn gir deg $100, ville du vært glad. Men hvis du tapte $100 fra lommeboken, ville det skade mye mer. Den følelsesmessige vekten av disse situasjonene er ikke lik. Tap gjør mye mer vondt enn gevinst føles bra. La oss ta det videre og si at jeg gir deg $100 og ber deg spille en gambling. Det er 50 % sjanse for at du vinner ytterligere $100 og 50 % sjanse for at du mister de opprinnelige $100. Ville du tatt det? Jeg ville ikke. De fleste ville ikke. Det er tapsaversjon. Hvis du tenker på det, er det logisk, det er forståelig, det er menneskelig. Konseptet bak tapsaversjon er at vi føler smerten ved å miste noe dobbelt så mye som gleden av å få noe av lik verdi. I psykologiske termer henger tap mer enn gevinster. Du ser sikkert hvordan dette forholder seg til streker. For å bygge en merkbar strek, krever det innsats; etter hvert som en strek vokser, begynner motivasjonen bak den å falme; eller mer nøyaktig, det begynner å bli sekundært. Her er et eksempel: Si at vennen din har en tre-dagers serie som lukker "Move Rings" på Apple Watch. De har nesten ingenting å tape utover å ønske å nå målet sitt og være konsekvente. Samtidig har du en imponerende rekke på 219 dager. Sjansen er stor for at du er fanget av frykten for å miste den. Du tenker mest sannsynlig ikke på prestasjonen på dette tidspunktet; det handler mer om å beskytte din investerte innsats, og det er tapsaversjon. Duolingo forklarer hvordan tapsaversjon bidrar til en brukers motvilje mot å bryte en lang rekke, selv på de lateste dagene. På en måte kan en strek bli til en vane når tapsaversjon setter seg. Fogg-atferdsmodellen (B = MAP) Nå som vi forstår frykten for å miste innsatsen investert i lengre streker, er et annet spørsmål: Hva får oss til å gjøre tingen i utgangspunktet, dag etter dag, selv før rekken blir stor? Det er det Fogg Behavior Model handler om. Det er relativt enkelt. En atferd (B) oppstår bare når tre faktorer - Motivasjon (M), Evne (A) og Spørring (P) - stemmer overens på samme tidspunkt. Således er ligningen B=MAP. Hvis noen av disse faktorene, til og med én, mangler i det øyeblikket, vil ikke oppførselen skje. Så for at et streksystem skal være effektivt og tilbakevendende, må alle tre faktorene være tilstede: Motivasjon Dette er skjørt og ikke noe som er konsekvent tilstede. Det er dager du erpumpet for å lære spansk, og dager du ikke engang føler en tøff viljestyrke til å lære språket. Motivasjon i seg selv til å bygge en vane er upålitelig og en tapende kamp fra dag én. EvneFor å kompensere for begrensningene til motivasjon er evne avgjørende. I denne sammenhengen betyr evne den enkle handlingen, det vil si at innsatsen er så lett at det er urealistisk å si at det ikke er mulig. De fleste apper bruker dette med vilje. Apple Fitness trenger bare at du står i ett minutt på en time for å få en hake mot Stand-målet ditt. Duolingo trenger kun én fullført leksjon. Disse oppgavene krever ikke så mye innsats. Barrieren er så lav at selv på de verste dagene kan du gjøre det. Men den kombinerte innsatsen til en pågående serie er der ideen om å tape rekken starter. Spør Dette er det som fullfører ligningen. Mennesker er naturlig glemsomme, så ja, evner kan gi oss 90 % dit. Men en oppfordring minner oss om å handle. Streker er vedvarende av design, så brukere må hele tiden påminnes om å handle. For å se hvor kraftig en forespørsel kan være, gjorde Duolingo en A/B-test for å se om et lite rødt merke på appens ikon økte konsistent bruk. Det ga en økning på 6 % i daglige aktive brukere. Bare et rødt merke. Modellbegrensninger Når alt dette er sagt, er det en begrensning for Fogg-modellen der kritikere og moderne forskning har lagt merke til at et design som er for mye avhengig av spørsmål, som aggressive varsler, risikerer å skape mental tretthet. Konstante varsler og overtid kan få brukere til å churne. Så pass på det. Zeigarnik-effekten Hvordan føler du deg når du forlater en oppgave med prosjekt halvferdig? Det irriterer mange mennesker fordi uferdige oppgaver opptar mer mental plass enn tingene vi fullfører. Når noe er gjort og borte, har vi en tendens til å glemme det. Når noe blir ugjort, har det en tendens til å tynge tankene våre. Dette er nøyaktig grunnen til at digitale produkter bruker kunstige fremdriftsindikatorer, som Upworks profilfullføringslinje, for å la en bruker vite at profilen deres bare er «60 % fullført». Det dytter brukeren til å fullføre det de startet.
La oss se på et annet eksempel. Du har fem oppgaver i en oppgaveliste-app, og på slutten av dagen sjekker du bare fire av dem som fullførte. Mange av oss vil føle seg ufullførte på grunn av den ene ufullførte oppgaven. Det, akkurat der, er Zeigarnik-effekten. Zeigarnik-effekten ble demonstrert av psykolog Bluma Zeigarnik, som beskrev at vi har en tendens til å holde ufullstendige oppgaver aktive i hukommelsen lenger enn fullførte oppgaver. Et strekmønster slår naturlig inn i dette i UX-design. La oss si at du er på dag 63 av en læringsrekke. På det tidspunktet er du i et pågående mønster av uferdige saker. Hjernen din vil sjelden glemme det ettersom den sitter i bakhodet. På dette tidspunktet blir hjernen din den som sender deg varsler. Når du setter disse psykologiske kreftene sammen, begynner du virkelig å forstå hvorfor streker ikke bare er en vanlig app-funksjon; de er i stand til å omforme menneskelig atferd. Men et eller annet sted langs linjen - jeg kan ikke si nøyaktig når, siden det er forskjellig for alle - når ting et punkt hvor en rekke skifter fra "morsomt" til noe du føler at du ikke har råd til å tape. Du vil ikke at 58 dager med innsats skal gå til spille, gjør du? Det er det som gjør et streksystem effektivt. Hvis det gjøres riktig, hjelper streker brukere med å bygge forbløffende vaner som oppnår et mål. Det kan være å lese daglig eller å gå på treningsstudioet konsekvent. Disse gjentatte handlingene (noen ganger små) forsterker seg over tid og blir tydelige i vårt daglige liv. Men det er to sider av hver mynt. Den tynne linjen mellom vane og tvang Hvis du har fulgt med, kan du allerede se at det er en mørk side ved streksystemer. Vanedannelse handler om konsistens med et gjentatt mål. Tvang er imidlertid konsistensen av å jobbe med et mål som ikke lenger er nødvendig, men som holdes fast av frykt eller press. Det er en syltynn strek. Du pusser tennene hver morgen uten å tenke; den er automatisk og instinktiv, med et klart mål om å ha god pust. Det er en strek som danner en god vane. Et etisk streksystem gir brukerne plass til å puste. Hvis du av en eller annen grunn ikke pusser om morgenen, kan du pusse ved middagstid. Ufullkommenhet er tillatt uten frykt for å miste en lang innsats. Tvang tar den motsatte veien, der en strek gjør deg engstelig, du føler deg skyldig eller til og med utmattet, og noen ganger føles det som om du ikke har oppnådd noe, til tross for alle dinearbeid. Du handler ikke fordi du vil, men fordi du ubevisst er livredd for å se fremgangen tilbakestilles til null. Noen beskrev til og med dette perfekt, "Jeg følte at jeg jukset, men jeg brydde meg rett og slett ikke. Jeg er ingenting uten streaken min". Dette viser de ekstreme holdestrekene kan ha på en person. I den grad brukere begynner å knytte sin egenverdi til en vilkårlig beregning i stedet for det opprinnelige målet eller grunnen til at de startet rekken i utgangspunktet. Streken blir hvem de er, ikke bare hva de gjør. Et godt utformet etisk streksystem skal føles som oppmuntring for brukeren, ikke press eller forpliktelse. Dette er relatert til balansen mellom indre og ytre motivasjon. Ytre motivasjon (eksterne belønninger, unngå straff) kan få brukerne i gang, men indre motivasjon (å gjøre oppgaven for et personlig mål som å lære spansk fordi du virkelig ønsker å kommunisere med en du er glad i) er sterkere for langsiktig engasjement. Et godt system bør gravitere mot indre motivasjon med forsiktig bruk av ytre elementer, dvs. minne brukerne om hvor langt de har kommet, ikke true dem med hva de kan miste. Igjen, det er en fin linje. En enkel test når du designer et streak-system er å faktisk ta litt tid og tenke på om produktene dine tjener penger ved å selge løsninger på angsten som produktet ditt skapte. Hvis ja, er det stor sjanse for at du utnytter brukere. Så det neste spørsmålet blir: Hvis jeg velger å bruke strek, hvordan utformer jeg den på en måte som virkelig hjelper brukerne med å nå målene sine? UX av Good Streak System Design Jeg tror det er her de fleste prosjekter enten spikerer et effektivt streksystem eller roter det fullstendig til. La oss gå gjennom noen UX-prinsipper for en god strekdesign. Hold det uanstrengt Du har sikkert hørt dette før, kanskje fra bøker som Atomic Habits, men det er verdt å nevne at en av de enkleste måtene vaner kan dannes på er å gjøre handlingen liten og enkel. Dette ligner på evnefaktoren vi diskuterte fra Fogg Behavior Model. Den første regelen for ethvert strekdesign bør være å gjøre den nødvendige handlingen så liten som menneskelig mulig samtidig som man oppnår fremgang. Hvis en daglig handling krever viljestyrke for å fullføre, vil den handlingen ikke klare de siste fem dagene. Hvorfor? Du kan ikke være motivert fem dager på rad. Eksempel: Hvis du kjører en meditasjonsapp, trenger du ikke få brukerne til å gå gjennom en 20-minutters økt bare for å opprettholde streaken. Prøv et enkelt minutt, kanskje til og med noe så lite som tretti sekunder, i stedet. Som det sies, små vanndråper lager det mektige havet). Små innsats samler seg til store prestasjoner med tiden. Det burde være målet: Fjern friksjon, spesielt når øyeblikket kan være vanskelig. Når brukere er stresset eller overveldet, la dem vite at det å bare dukke opp, selv for noen få sekunder, teller som innsats. Gi tydelig visuell tilbakemelding Mennesker er visuelle av natur. De fleste ganger trenger vi å se noe for å tro; det er dette behovet for å visualisere ting for å forstå dem bedre og sette ting i perspektiv. Dette er grunnen til at strekmønstre ofte bruker visuelle elementer, som grafer, hakemerker, fremdriftsringer og rutenett, for å visualisere innsats. Se på GitHubs bidragsgraf. Det er en enkel visualisering av konsistens. Likevel puster utviklere det inn som oksygen.
Nøkkelen er ikke å få et streksystem til å føles abstrakt. Det skal føles ekte og fortjent. For eksempel bruker Duolingo og Apples Fitness-aktivitetsringer rene animasjonsdesign når en strek er fullført, og GitHub viser historiske data om en brukers konsistens over tid.
Bruk god timing Jeg nevnte tidligere at mennesker generelt er glemsomme av natur, og at spørsmål kan bidra til å opprettholde fremdriften. Uten spørsmål glemmer de fleste nye brukere å fortsette. Livet kan bli travelt, motivasjonen forsvinner, og ting skjer. Selv langtidsbrukere drar nytte av forespørsler, men de fleste ganger er de allerede låst inne i vanesløyfen. Likevel kan selv den mest engasjerte personen gå glipp av en dag ved et uhell. Streksystemet ditt trenger definitivt påminnelser. De mest brukte påminnelsene er push-varsler. Timing er virkelig viktig når du arbeider med push-varslinger. Type app er også viktig. Å sende et varsel klokken 09.00 som sier "Du har ikke trent i dag" er bare rart for en læringsapp fordi mange har ting å gjøre på dagen før de i det hele tatt tenker på å fullføre en leksjon. Men hvis vi snakker om en treningsapp, så er deter rimelig og kanskje til og med forventet å bli påminnet tidligere på dagen. Push-varsler varierer betydelig etter appkategori. Treningsapper, for eksempel, ser høyere engasjement med tidlig morgenvarsler (7–8 AM), mens produktivitetsapper kan gi bedre resultater tidlig på formiddagen. Nøkkelen er å A/B-teste appens timing basert på brukernes atferd i stedet for å anta at ting er én størrelse som passer alle. Det som fungerer for en meditasjonsapp, fungerer kanskje ikke for en kodingssporer. Andre spørsmålsmetoder er røde prikker på appikonet og til og med app-widgets. Studier varierer, men den gjennomsnittlige personen låser opp enheten mellom 50-150 ganger om dagen (PDF). Hvis en bruker ser en rød prikk på en app eller en widget som indikerer en gjeldende strek hver gang de låser opp telefonen, øker det engasjementet. Bare ikke overdriv; ledeteksten skal tjene som en påminnelse, ikke et mas. Feir milepæler Et streksystem bør prøve å feire milepæler for å gjenopplive følelser, spesielt for brukere som er dypt inne i en serie. Når en bruker treffer dag 7, dag 30, dag 50, dag 100, dag 365, bør du gjøre en stor sak ut av det. Anerkjenn prestasjoner - spesielt for langtidsbrukere.
Som vi så tidligere, fant Duolingo ut dette og implementerte en animert grafikk som feirer milepæler med konfetti. Noen plattformer gir til og med betydelige bonusbelønninger som validerer brukernes innsats. Og dette kan være fordelaktig for apper, slik at brukere har en tendens til å dele milepælene sine offentlig på sosiale medier. En annen fordel er forventningen som kommer før man når milepæler. Det er ikke bare å holde streaken i live i det uendelige; brukerne har noe å se frem til. Bruk nådemekanismer Livet er uforutsigbart. Folk blir distrahert. Ethvert godt streksystem bør forvente ufullkommenhet. En av de største psykologiske truslene mot et streak-system er den harde tilbakestillingen til null etter bare en enkelt glemt dag. Et "etisk" streksystem bør gi brukeren litt slakk. La oss si at du har en 90-dagers sjakklæringsrekke. Du har vært konsekvent i tre gode måneder, og en dag dør telefonen din mens du reiser, og akkurat slik blir 90 0 - alt, all den innsatsen, blir slettet, og fremgangen forsvinner. Brukeren kan bli fullstendig ødelagt. Tanken på å gjenoppbygge den fra bunnen av er så demoraliserende at innsatsen ikke er verdt det. I verste fall kan en bruker forlate appen etter å ha følt seg som en fiasko. Vurder å legge til en "nåde"-mekanisme til streksystemet ditt:
Streak Freeze La brukere med vilje gå glipp av en dag uten straff. Ekstra tid Tillat noen timer (2–3) etter den vanlige fristen før du utløser en tilbakestilling. Forfallsmodeller I stedet for en hard tilbakestilling, reduseres streken med et lite beløp, for eksempel trekkes 10 dager fra rekken per tapt dag.
Bruk en oppmuntrende tone La oss sammenligne to meldinger som vises til brukere når en strek bryter:
"Du mistet rekken på 42 dager. Begynn på nytt." "Du dukket opp i 42 dager i strekk. Det er en utrolig fremgang! Vil du prøve en gang til?"
Begge formidler den samme informasjonen, men den følelsesmessige påvirkningen er forskjellig. Den første meldingen vil mest sannsynlig få en bruker til å føle seg demoralisert og få dem til å slutte. Den andre meldingen feirer det som allerede er oppnådd og oppfordrer brukeren forsiktig til å prøve igjen. Streak Systems Design utfordringer Før vi går inn på de tekniske spesifikasjonene ved å bygge et streksystem, bør du være klar over utfordringene du kan møte. Ting kan bli komplisert, som du kanskje forventer. Håndtering av tidssoner Det er en grunn til at håndtering av tid og dato er blant de vanskeligste konseptene utviklere håndterer. Det er formatering, internasjonalisering og mye mer å vurdere. La meg spørre deg dette: Hva teller som en dag? Vi vet at verden kjører på forskjellige tidssoner, og som om det ikke er nok, har noen regioner sommertid (DST) som skjer to ganger i året. Hvor begynner du i det hele tatt å håndtere disse kantsakene? Hva regnes som "starten" på morgendagen? Noen utviklere prøver å unngå dette ved å bruke én sentral tidssone, som UTC. For noen brukere vil dette gi riktige resultater, men for noen kan det være avslått med en time, to timer eller mer. Denne inkonsekvensen ødelegger brukeropplevelsen. Brukerne bryr seg mindre om hvordan du håndterer tiden bak kulissene; alt de forventer er at hvis de utfører en streak-handling klokken 23:40, bør den registreres på det nøyaktige tidspunktet, i deres kontekst. Du bør definere "en dag" basert på brukerens lokale tidssone, ikke servertiden. Jada, du kan ta det roligrute og tilbakestill streker globalt for alle brukere ved midnatt UTC, men du skaper i stor grad urettferdighet. Noen i California har alltid åtte ekstra timer på å fullføre oppgaven sin enn noen som bor i London. Det er en urettferdig designfeil som straffer enkelte brukere på grunn av deres plassering. Og hva om den personen i London bare er på besøk, fullfører en oppgave og deretter går tilbake til en annen tidssone? En effektiv løsning på alle disse er å be brukere om å angi eksplisitt tidssone under onboarding (fortrinnsvis etter første autentisering). Det er en god idé å inkludere en subtil merknad om at å gi tidssoneinformasjon bare brukes for at appen skal spore fremdriften nøyaktig, i stedet for å bli brukt som personlig identifiserbar data. Og det er nok en god idé å gjøre det til en foranderlig setting. Jeg foreslår at alle unngår direkte håndtering av tidssonelogikk i en app. Bruk utprøvde datobiblioteker, som Moment.js eller pytz (Python), osv. Det er ikke nødvendig å finne opp hjulet på nytt for noe så komplekst som dette. Tapte dager og kantsaker En annen utfordring du bør bekymre deg for er ukontrollerbare edge-tilfeller som brukere som sover for mye, servernedetid, lag, nettverksfeil og så videre. Å bruke ideen om nådemekanismer, som de vi diskuterte tidligere, kan hjelpe. Et nådevindu på to timer kan hjelpe både bruker og utvikler, i den forstand at brukere ikke blir strengt straffet for ukontrollerbare livsomstendigheter. For utviklere er grace-vinduer nyttige i de ukontrollerbare øyeblikkene når serveren går ned midt på natten. Fremfor alt, aldri stol på klienten. Valider alltid på serversiden. Serveren bør være den eneste kilden til sannhet. Forebygging av juks Igjen, jeg kan ikke understreke dette nok: Sørg for å validere alt på serversiden. Brukere er mennesker, og mennesker kan jukse hvis de får muligheten. Det er uunngåelig. Du kan prøve:
Lagre alle handlinger med UTC-tidsstempler. Klienten kan sende sin lokale tid, men serveren kan umiddelbart konvertere den til UTC og validere mot servertiden. På den måten, hvis klientens tidsstempel er mistenkelig langt, kan systemet avvise det som en feil, og brukergrensesnittet kan svare deretter. Bruk hendelsesbasert sporing. Med andre ord, lagre en registrering av hver handling med metadata, inkludert informasjon som brukerens ID, typen handling som er utført, og tidsstempelet og tidssonen. Dette hjelper med validering.
Bygge en streksystemmotor Dette er ikke en kodeopplæring, så jeg vil unngå å dumpe en haug med kode på deg. Jeg vil holde dette praktisk og beskrive hvordan ting generelt driver en streksystemmotor så langt som arkitektur, flyt og pålitelighet. Kjernearkitektur Som jeg har sagt flere ganger, gjør serveren til den eneste kilden til sannhet for strekdata. Arkitekturen kan gå omtrent slik på serveren:
Lagre hver brukers data i en database. Lagre gjeldende streklager (standard som 0) som et heltall. Lagre tidssone-preferansen, det vil si IANA-tidssonestrengen (enten implisitt fra lokalt tidsstempel eller eksplisitt ved å be brukeren velge sin tidssone). For eksempel "America/New_York". Håndter all logikk for å avgjøre om streken fortsetter eller bryter, med en tidssonesjekk som er i forhold til brukerens lokale tidssone.
I mellomtiden, på klientsiden:
Vis gjeldende strek, vanligvis hentet fra serveren. Send handling utført i form av metadata til serveren for å validere om brukeren faktisk fullførte en kvalifiserende streak-handling. Gi visuell tilbakemelding basert på serversvarene.
Så kort sagt, hjernen er på serveren, og klienten er for visningsformål og sender inn hendelser. Dette sparer deg for mange feil og kantsaker, pluss gjør oppdateringer og reparasjoner enklere. Den logiske flyten La oss simulere en gjennomgang av hvordan en minimal effektiv streksystemmotor vil gå når en bruker fullfører en handling:
Brukeren fullfører en kvalifiserende streak-handling. Klienten sender en hendelse til serveren som metadata. Dette kan være "Bruker X fullførte handling Y ved tidsstempel Z". Serveren mottar denne hendelsen og utfører grunnleggende validering. Er dette en ekte bruker? Er de autentisert? Er handlingen gyldig? Er tidssonen konsistent? Hvis dette går gjennom, henter serveren brukerens streakdata fra databasen. Konverter deretter det mottatte handlingens tidsstempel til brukerens lokale tidssone. La serveren sammenligne kalenderdatoene (ikke tidsstempler) i brukerens lokale tidssone: Hvis det er samme dag, er handlingen overflødig og det er ingen endring istrek. Hvis det er neste dag, utvides rekken og øker med 1. Hvis det er et gap på mer enn én dag, bryter rekken. Imidlertid er det her du kan bruke nådemekanikk. Hvis nådemekanismen savnes, tilbakestill streken til 1.
Hvis du velger å lagre historiske data for milepælsprestasjoner, må du oppdatere variabler som «lengste rekke» eller «totalt aktive dager». Serveren oppdaterer deretter databasen og svarer klienten. Noe sånt som dette:
{ "current_streak": 48, "lengste_strek": 50, "total_active_days": 120, "streak_extended": sant, }
Som et ytterligere tiltak bør serveren enten prøve på nytt eller avvise og varsle klienten når noe feiler under prosessen. Bygg for motstandskraft Som nevnt før er brukere som mister en rekke på grunn av feil eller servernedetid forferdelig UX, og brukere forventer ikke å ta fallet for det. Derfor bør streaksystemet ditt ha beskyttelse for disse scenariene. Hvis serveren er nede på grunn av vedlikehold (eller hvilken som helst grunn), vurder å tillate et midlertidig vindu med ekstra timer for å få det fikset slik at handlinger kan sendes for sent og fortsatt teller. Du kan også velge å varsle brukere, spesielt hvis situasjonen er i stand til å påvirke en pågående serie. Merk: Etabler en admin-bakdør der data kan gjenopprettes manuelt. Bugs er uunngåelige, og noen brukere vil ringe appen din eller kontakte for å støtte at rekken deres brøt av en grunn de ikke kunne kontrollere. Du skal kunne gjenopprette strekene manuelt hvis brukeren har rett etter undersøkelser. Konklusjon En ting er fortsatt klart: Streker er virkelig kraftige på grunn av hvordan menneskelig psykologi fungerer på et grunnleggende nivå. Det beste streksystemet der ute er det som brukere ikke tenker bevisst på. Det har blitt en rutine med umiddelbare resultater eller synlig fremgang, som å pusse tenner, som blir en vanlig vane. Og jeg skal bare si det: Ikke alle produkter trenger et streksystem. Bør du virkelig tvinge konsistens bare fordi du vil ha daglige aktive brukere? Svaret kan godt være "nei".
