Estic segur que heu sentit parlar de ratlles o heu fet servir una aplicació amb una. Però us heu preguntat mai per què les ratlles són tan populars i potents? Bé, hi ha l'obvi que les aplicacions volen tanta atenció com sigui possible, però a part d'això, sabíeu que quan la popular aplicació d'aprenentatge Duolingo va introduir ginys iOS per mostrar ratlles, el compromís dels usuaris va augmentar un 60%. El seixanta per cent és un canvi massiu en el comportament i demostra com es poden utilitzar els patrons de "ratxa" per augmentar la implicació i impulsar l'ús. En el seu aspecte més bàsic, una ratxa és el nombre de dies consecutius que un usuari completa una activitat específica. Algunes persones també el defineixen com un hàbit "gamificat" o una mètrica dissenyada per fomentar un ús coherent. Però les ratlles transcendeixen més enllà de ser una mètrica o un registre en una aplicació; és més psicològic que això. Els instints humans són fàcils d'influir amb els factors adequats. Mireu aquests tres factors: el progrés, l'orgull i la por de perdre's (comunament anomenat FOMO). Què tenen en comú tots aquests? Esforç. Com més esforç us poseu en alguna cosa, més modela la vostra identitat, i així és com les ratlles es creuen al món de la psicologia del comportament. Ara, amb un gran poder comporta una gran responsabilitat, i per això, hi ha un costat fosc a les ratlles. En aquest article, entrarem en els principis de psicologia, UX i disseny que hi ha darrere de la creació d'un sistema de ratxa eficaç. Veurem (1) per què el nostre cervell respon gairebé instintivament a l'activitat de les ratlles, (2) com dissenyar les ratlles d'una manera que ajudin realment els usuaris i (3) el treball tècnic que implica la creació d'un patró de ratlles. La psicologia darrere de les ratlles Per dissenyar i construir un sistema de ratlles eficaç, hem d'entendre com s'alinea amb com estan connectats els nostres cervells. Com, què fa que sigui tan eficaç en la mesura que sentim tanta dedicació intensa per protegir les nostres ratlles? Hi ha tres principis de psicologia interessants i ben documentats que donen suport al que fa que les ratlles siguin tan potents i addictives. Aversió a la pèrdua Aquesta és probablement la força més forta darrere de les ratlles. Ho dic perquè la majoria de vegades, gairebé no pots evitar això a la vida. Penseu-ho d'aquesta manera: si un amic us dóna 100 dòlars, estaríeu content. Però si perdés 100 dòlars de la teva cartera, et perjudicaria molt més. El pes emocional d'aquestes situacions no és igual. La pèrdua fa molt més mal que el guany se sent bé. Anem més enllà i diguem que et dono 100 dòlars i et demano que juguis una aposta. Hi ha un 50% de possibilitats de guanyar 100 dòlars més i un 50% de possibilitats de perdre els 100 dòlars originals. T'ho prendries? Jo no ho faria. La majoria de la gent no ho faria. Això és aversió a la pèrdua. Si hi penses bé, és lògic, és comprensible, és humà. El concepte darrere de l'aversió a la pèrdua és que sentim el dolor de perdre alguna cosa el doble que el plaer d'aconseguir alguna cosa d'igual valor. En termes psicològics, la pèrdua perdura més que els guanys. Probablement veieu com això es relaciona amb les ratlles. Per crear una ratxa notable, requereix esforç; a mesura que creix una ratxa, la motivació que hi ha darrere comença a esvair-se; o més exactament, comença a ser secundari. Aquí teniu un exemple: digueu que el vostre amic té una ratxa de tres dies tancant els seus "Move Rings" al seu Apple Watch. Gairebé no tenen res a perdre més enllà de voler aconseguir el seu objectiu i ser coherents. Al mateix temps, teniu una ratxa impressionant de 219 dies. El més probable és que estiguis atrapat per la por de perdre'l. El més probable és que no estiguis pensant en l'assoliment en aquest moment; es tracta més de protegir el vostre esforç invertit, i això és aversió a la pèrdua. Duolingo explica com l'aversió a la pèrdua contribueix a la reticència de l'usuari a trencar una llarga ratxa, fins i tot en els seus dies més mandrosos. D'alguna manera, una ratxa es pot convertir en un hàbit quan s'instal·la l'aversió a la pèrdua. El model de comportament de Fogg (B = MAP) Ara que entenem la por de perdre l'esforç invertit en ratxas més llargues, una altra pregunta és: què ens fa fer la cosa en primer lloc, dia rere dia, fins i tot abans que la ratxa es faci gran? D'això tracta el model de comportament de Fogg. És relativament senzill. Un comportament (B) només es produeix quan tres factors: la motivació (M), la capacitat (A) i l'impuls (P) s'alineen al mateix moment. Així, l'equació B=MAP. Si falta algun d'aquests factors, fins i tot un, en aquell moment, el comportament no es produirà. Per tant, perquè un sistema de ratlles sigui eficient i recurrent, els tres factors han d'estar presents: Motivació Això és fràgil i no és una cosa que estigui present constantment. Hi ha dies que etsamb ganes d'aprendre espanyol, i dies que ni tan sols sents un àpic de força de voluntat per aprendre l'idioma. La motivació per si mateixa per construir un hàbit no és fiable i una batalla perduda des del primer dia. Capacitat Per compensar les limitacions de la motivació, la capacitat és fonamental. En aquest context, la capacitat significa la facilitat d'acció, és a dir, l'esforç és tan fàcil que no és realista dir que no és possible. La majoria de les aplicacions l'utilitzen intencionadament. Apple Fitness només necessita que us atureu un minut en una hora per guanyar-vos un cop per assolir el vostre objectiu de Stand. Duolingo només necessita una lliçó completada. Aquestes tasques no requereixen tant d'esforç. La barrera és tan baixa que fins i tot en els teus pitjors dies, pots fer-ho. Però l'esforç combinat d'una ratxa en curs és on comença la idea de perdre aquesta ratxa. PromptAixò és el que completa l'equació. Els humans som naturalment oblidats, així que sí, la capacitat ens pot portar fins al 90%. Però una indicació ens recorda que hem d'actuar. Les ratlles són persistents per disseny, de manera que cal recordar constantment als usuaris que actuïn. Per veure com de poderós pot ser un missatge, Duolingo va fer una prova A/B per veure si una petita insígnia vermella a la icona de l'aplicació augmentava l'ús constant. Va produir un augment del 6% dels usuaris actius diaris. Només una insígnia vermella. Limitacions del model Dit tot això, hi ha una limitació al model Fogg per la qual els crítics i la investigació moderna han notat que un disseny que es basa massa en indicacions, com les notificacions agressives, corre el risc de crear fatiga mental. Les notificacions constants i les hores extraordinàries poden provocar que els usuaris es redueixin. Per tant, compte amb això. L'efecte Zeigarnik Com et sents quan deixes una tasca de projecte a mig fer? Això irrita moltes persones perquè les tasques no acabades ocupen més espai mental que les coses que completem. Quan alguna cosa es fa i desapareix, tendim a oblidar-la. Quan alguna cosa es deixa sense fer, tendeix a pesar en la nostra ment. És exactament per això que els productes digitals utilitzen indicadors de progrés artificials, com ara la barra de finalització del perfil d'Upwork, per fer saber a un usuari que el seu perfil només està "complet al 60%". Incita l'usuari a acabar el que va començar.
Vegem un altre exemple. Teniu cinc tasques en una aplicació de llista de tasques pendents i, al final del dia, només en comproveu quatre com s'han completat. Molts de nosaltres ens sentirem incomplerts a causa d'aquesta única tasca inacabada. Això, allà mateix, és l'efecte Zeigarnik. L'efecte Zeigarnik va ser demostrat per la psicòloga Bluma Zeigarnik, que va descriure que tendim a mantenir les tasques incompletes actives a la nostra memòria més temps que les tasques completades. Un patró de ratlles s'aplica de manera natural a això en el disseny d'UX. Suposem que esteu al dia 63 d'una ratxa d'aprenentatge. En aquest moment, esteu en un patró continu de negocis pendents. El teu cervell poques vegades s'oblidarà d'això, ja que es troba al fons de la teva ment. En aquest moment, el teu cervell es converteix en el que t'envia notificacions. Quan ajunteu aquestes forces psicològiques, comenceu a entendre realment per què les ratlles no són només una característica habitual de l'aplicació; són capaços de remodelar el comportament humà. Però en algun lloc al llarg de la línia, no puc dir exactament quan, ja que és diferent per a tothom, les coses arriben a un punt en què una ratxa passa de "divertida" a alguna cosa que creieu que no us podeu permetre el luxe de perdre. No vols que es perdin 58 dies d'esforç, oi? Això és el que fa que un sistema de ratlles sigui efectiu. Si es fan bé, les ratlles ajuden els usuaris a crear hàbits sorprenents que assoleixen un objectiu. Podria ser llegir diàriament o anar al gimnàs de manera constant. Aquestes accions repetides (de vegades petites) s'agreguen amb el temps i es fan evidents en la nostra vida quotidiana. Però cada moneda té dues cares. La línia fina entre l'hàbit i la compulsió Si heu estat seguint, ja podeu dir que hi ha un costat fosc als sistemes de ratxa. La formació d'hàbits consisteix en la coherència amb un objectiu repetit. La compulsió, però, és la coherència de treballar en un objectiu que ja no és necessari però que es manté per por o pressió. És una línia fina com una navalla. Et rentes les dents cada matí sense pensar-ho; és automàtic i instintiu, amb un clar objectiu de tenir una bona respiració. Aquesta és una ratxa que forma un bon hàbit. Un sistema de ratlles ètiques ofereix als usuaris espai per respirar. Si, per algun motiu, no us raspalleu al matí, podeu raspallar-vos al migdia. La imperfecció es permet sense por de perdre un llarg esforç. La compulsió pren el camí contrari, per la qual una ratxa et fa ansiós, et sents culpable o fins i tot esgotat i, de vegades, sembla que no has aconseguit res, malgrat tot el teutreball. No actues perquè vulguis, sinó perquè inconscientment estàs aterrit de veure que el teu progrés es torna a zero. Fins i tot algú ho va descriure perfectament: "Vaig sentir que estava fent trampes, però simplement no m'importava. No sóc res sense la meva ratxa". Això mostra les ratxes de retenció extrema que poden tenir en un individu. En la mesura que els usuaris comencen a vincular la seva autoestima a una mètrica arbitrària en lloc de l'objectiu o el motiu original per què van començar la ratxa en primer lloc. La ratxa es converteix en qui són, no només en el que fan. Un sistema de ratxa ètica ben dissenyat hauria de semblar un ànim per a l'usuari, no una pressió o una obligació. Això es relaciona amb l'equilibri de la motivació intrínseca i extrínseca. La motivació extrínseca (recompenses externes, evitar el càstig) pot fer que els usuaris comencin, però la motivació intrínseca (fer la tasca per a un objectiu personal com aprendre espanyol perquè realment voleu comunicar-vos amb un ésser estimat) és més forta per a un compromís a llarg termini. Un bon sistema hauria de gravitar cap a la motivació intrínseca amb un ús acurat dels elements extrínsecs, és a dir, recordar als usuaris fins on han arribat, no amenaçant-los amb el que podrien perdre. De nou, és una línia fina. Una prova senzilla a l'hora de dissenyar un sistema de ratxa és prendre una estona i pensar si els vostres productes guanyen diners venent solucions a l'ansietat que va crear el vostre producte. En cas afirmatiu, hi ha una gran probabilitat que estigueu explotant usuaris. Per tant, la següent pregunta és: Si opto per fer servir streak, com el dissenyo d'una manera que ajudi realment els usuaris a assolir els seus objectius? La UX de Good Streak System Design Crec que aquí és on la majoria dels projectes aconsegueixen un sistema de ratlles eficaç o ho desordenan completament. Passem per alguns principis d'UX d'un bon disseny de ratxa. Mantingueu-ho sense esforç Segurament ho heu sentit abans, potser de llibres com Atomic Habits, però val la pena esmentar que una de les maneres més fàcils de formar hàbits és fent que l'acció sigui petita i fàcil. Això és similar al factor de capacitat que hem comentat del model de comportament de Fogg. La primera regla de qualsevol disseny de ratxa hauria de ser fer que l'acció requerida sigui tan petita com sigui humanament possible tot aconseguint progrés. Si una acció diària requereix força de voluntat per completar-se, aquesta acció no passarà de cinc dies. Per què? No pots estar motivat cinc dies seguits. Cas concret: si executeu una aplicació de meditació, no cal que els usuaris passin per una sessió de 20 minuts només per mantenir la ratxa. Proveu un sol minut, potser fins i tot alguna cosa tan petit com trenta segons, en canvi. Com diu el refrany, petites gotes d'aigua fan el poderós oceà). Els petits esforços es combinen en grans assoliments amb el temps. Aquest hauria de ser l'objectiu: eliminar la fricció, sobretot quan el moment pot ser difícil. Quan els usuaris estiguin estressats o aclaparats, feu-los saber que només presentar-se, fins i tot durant uns segons, compta com un esforç. Proporcioneu comentaris visuals clars Els humans som visuals per naturalesa. La majoria de vegades, necessitem veure alguna cosa per creure; hi ha aquesta necessitat de visualitzar les coses per entendre-les millor i posar les coses en perspectiva. És per això que els patrons de ratlles sovint utilitzen elements visuals, com ara gràfics, marques de verificació, anells de progrés i quadrícules, per visualitzar l'esforç. Mireu el gràfic de contribucions de GitHub. És una simple visualització de la coherència. No obstant això, els desenvolupadors la respiren com l'oxigen.
La clau és no fer que un sistema de ratlles se senti abstracte. Hauria de sentir-se real i merescut. Per exemple, els anells d'activitat de Duolingo i Apple Fitness utilitzen dissenys d'animació nets en acabar una ratxa, i GitHub mostra dades històriques de la consistència d'un usuari al llarg del temps.
Utilitzeu el bon moment He esmentat abans que els humans són generalment oblidats per naturalesa i que les indicacions poden ajudar a mantenir l'impuls. Sense indicacions, la majoria dels usuaris nous obliden continuar. La vida pot estar ocupada, la motivació desapareix i les coses passen. Fins i tot els usuaris de molt de temps es beneficien de les indicacions, tot i que la majoria de vegades, ja estan bloquejats dins del bucle d'hàbits. No obstant això, fins i tot la persona més compromesa pot perdre accidentalment un dia. Definitivament, el vostre sistema de ratlles necessita recordatoris. Els recordatoris d'avís més utilitzats són les notificacions push. El temps realment importa quan es treballa amb notificacions push. El tipus d'aplicació també importa. Enviar una notificació a les 9 del matí dient "Avui no has practicat" és estrany per a una aplicació d'aprenentatge perquè molts tenen coses a fer el dia abans de pensar fins i tot a completar una lliçó. Si estem parlant d'una aplicació de fitness, però, aixòés raonable i potser fins i tot s'espera que se'ls recordi més d'hora. Les notificacions push varien significativament segons la categoria d'aplicació. Les aplicacions de fitness, per exemple, veuen un compromís més alt amb les notificacions del matí (de 7 a 8 del matí), mentre que les aplicacions de productivitat poden funcionar millor a primera hora del migdia. La clau és provar A/B el temps de la vostra aplicació en funció del comportament dels vostres usuaris en lloc de suposar que les coses són d'una mida única. El que funciona per a una aplicació de meditació pot no funcionar per a un rastrejador de codificació. Altres mètodes d'avís són els punts vermells a la icona de l'aplicació i fins i tot els ginys de l'aplicació. Els estudis varien, però la persona mitjana desbloqueja el seu dispositiu entre 50 i 150 vegades al dia (PDF). Si un usuari veu un punt vermell en una aplicació o un giny que indica una ratxa actual cada vegada que desbloqueja el seu telèfon, augmenta el compromís. Simplement no t'excedeixis; l'avís hauria de servir com a recordatori, no com a molestia. Celebra les fites Un sistema de ratxa hauria d'intentar celebrar fites per reactivar les emocions, especialment per als usuaris que es troben en una ratxa. Quan un usuari arriba al dia 7, al dia 30, al dia 50, al dia 100, al dia 365, hauríeu de fer-ne un gran profit. Reconeix els èxits, especialment per als usuaris de llarga durada.
Com hem vist anteriorment, Duolingo ho va esbrinar i va implementar un gràfic animat que celebra fites amb confeti. Algunes plataformes fins i tot ofereixen recompenses de bonificació substancials que validen els esforços dels usuaris. I això pot ser beneficiós per a les aplicacions, de manera que els usuaris tendeixen a compartir les seves fites públicament a les xarxes socials. Un altre benefici és l'anticipació que arriba abans d'assolir fites. No es tracta només de mantenir viva la ratxa sense parar; els usuaris tenen alguna cosa a esperar. Utilitzeu mecanismes de gràcia La vida és imprevisible. La gent es distreu. Qualsevol bon sistema de ratlles hauria d'esperar imperfecció. Una de les amenaces psicològiques més grans per a un sistema de ratxa és el restabliment complet a zero després d'un sol dia perdut. Un sistema de ratlles "ètica" hauria de proporcionar a l'usuari una mica de fluix. Suposem que tens una ratxa d'aprenentatge d'escacs de 90 dies. Heu estat constant durant tres bons mesos i un dia, el vostre telèfon s'apaga mentre viatja, i així, el 90 es converteix en 0: tot, tot aquest esforç, s'esborra i el progrés s'esvaeix. L'usuari podria estar completament devastat. La idea de reconstruir-lo des de zero és tan desmoralitzant que l'esforç no val la pena. En el pitjor, un usuari podria abandonar l'aplicació després de sentir-se com un fracàs. Penseu en afegir un mecanisme de "gràcia" al vostre sistema de ratlles:
Streak FreezePermet als usuaris perdre intencionadament un dia sense penalitzacions. Temps addicional Permet unes hores (2-3) després de la data límit habitual abans d'activar un restabliment. Models de decadència En lloc d'un restabliment dur, la ratxa disminueix en una petita quantitat, per exemple, es dedueixen 10 dies de la ratxa per dia perdut.
Utilitzeu un to encoratjador Comparem dos missatges que es mostren als usuaris quan es trenca una ratxa:
"Has perdut la teva ratxa de 42 dies. Torna a començar". "Vas presentar-te durant 42 dies seguits. És un progrés increïble! Vols tornar-ho a provar?"
Tots dos transmeten la mateixa informació, però l'impacte emocional és diferent. El primer missatge probablement faria que un usuari se senti desmoralitzat i que abandonés. El segon missatge celebra el que ja s'ha aconseguit i anima suaument l'usuari a tornar-ho a provar. Reptes de disseny de sistemes Streak Abans d'entrar en les especificitats tècniques de la creació d'un sistema de ratlles, hauríeu de ser conscients dels reptes que podríeu trobar. Les coses es poden complicar, com és d'esperar. Maneig de zones horàries Hi ha una raó per la qual manejar l'hora i la data es troba entre els conceptes més difícils amb què tracten els desenvolupadors. Hi ha format, internacionalització i molt més a tenir en compte. Permeteu-me preguntar-vos això: què compta com un dia? Sabem que el món funciona en diferents zones horàries i, per si això no fos prou, algunes regions tenen l'horari d'estiu (DST) que passa dues vegades a l'any. Per on comenceu a gestionar aquests casos extrems? Què compta com a "inici" de demà? Alguns desenvolupadors intenten evitar-ho fent servir una zona horària central, com ara UTC. Per a alguns usuaris, això donaria resultats correctes, però per a alguns, podria estar desactivat en una hora, dues hores o més. Aquesta inconsistència arruïna l'experiència de l'usuari. Als usuaris els importa menys com gestioneu el temps entre bastidors; l'únic que esperen és que si realitzen una acció de ratxa a les 23:40, s'hauria de registrar a aquesta hora exacta, en el seu context. Hauríeu de definir "un dia" en funció de la zona horària local de l'usuari, no de l'hora del servidor. Per descomptat, us podeu prendre amb calmaencamineu i reinicieu les ratlles globalment per a tots els usuaris a la mitjanit UTC, però esteu creant molt injustícia. Algú a Califòrnia sempre té vuit hores més per completar la seva tasca que algú que viu a Londres. Aquest és un defecte de disseny injust que castiga determinats usuaris per la seva ubicació. I què passa si aquesta persona de Londres només està de visita, completa una tasca i torna a una altra zona horària? Una solució eficaç a tot això és demanar als usuaris que estableixin explícitament la seva zona horària durant la incorporació (preferiblement després de la primera autenticació). És una bona idea incloure una nota subtil que indica que proporcionar informació sobre la zona horària només s'utilitza per a l'aplicació per fer un seguiment del progrés amb precisió, en lloc d'utilitzar-se com a dades d'identificació personal. I és una altra bona idea fer-ho un entorn canviant. Suggereixo que qualsevol persona eviti gestionar directament la lògica de la zona horària en una aplicació. Utilitzeu biblioteques de dates provades i certes, com Moment.js o pytz (Python), etc. No cal reinventar la roda per a una cosa tan complexa com aquesta. Dies perduts i casos Edge Un altre repte del qual us hauríeu de preocupar són els casos extrems incontrolables, com ara els usuaris que s'adormen, el temps d'inactivitat del servidor, el retard, els errors de xarxa, etc. Utilitzar la idea de mecanismes de gràcia, com els que hem comentat anteriorment, pot ajudar. Una finestra de gràcia de dues hores pot ajudar tant a l'usuari com al desenvolupador, en el sentit que els usuaris no són rígidament castigats per circumstàncies de vida incontrolables. Per als desenvolupadors, les finestres de gràcia són útils en aquells moments incontrolables en què el servidor cau enmig de la nit. Sobretot, no confieu mai en el client. Valideu sempre al costat del servidor. El servidor hauria de ser l'única font de veritat. Prevenció de trampes Una vegada més, no ho puc subratllar prou: assegureu-vos de validar-ho tot al costat del servidor. Els usuaris són humans i els humans podrien enganyar si se'ls dóna l'oportunitat. És inevitable. Pots provar:
Emmagatzemar totes les accions amb marca d'hora UTC. El client pot enviar la seva hora local, però el servidor pot convertir-la immediatament a UTC i validar-la en funció de l'hora del servidor. D'aquesta manera, si la marca de temps del client és sospitosament llunyana, el sistema pot rebutjar-la com a error i la interfície d'usuari pot respondre en conseqüència. Utilitzant el seguiment basat en esdeveniments. En altres paraules, emmagatzema un registre de cada acció amb metadades que incloguin informació com l'identificador de l'usuari, el tipus d'acció realitzada i la marca de temps i la zona horària. Això ajuda amb la validació.
Construcció d'un motor del sistema Streak Aquest no és un tutorial de codi, així que evitaré llençar-vos un munt de codi. Mantindré això pràctic i descriuré com les coses funcionen generalment amb un motor de sistema de ratxa pel que fa a l'arquitectura, el flux i la fiabilitat. Arquitectura bàsica Com he dit diverses vegades, feu del servidor l'única font de veritat per a les dades de ratxa. L'arquitectura pot anar com això al servidor:
Emmagatzema les dades de cada usuari en una base de dades. Emmagatzema el magatzem de ratlles actual (per defecte com a 0) com un nombre enter. Emmagatzemeu la preferència de la zona horària, és a dir, la cadena de la zona horària de l'IANA (ja sigui implícitament des de la marca de temps local o de manera explícita demanant a l'usuari que seleccioni la seva zona horària). Per exemple, "Amèrica/Nova_York". Gestioneu tota la lògica per determinar si la ratxa continua o es trenca, amb una comprovació de la zona horària relativa a la zona horària local de l'usuari.
Mentrestant, pel costat del client:
Mostra la ratxa actual, que normalment s'obté del servidor. Envieu l'acció realitzada en forma de metadades al servidor per validar si l'usuari ha completat realment una acció de ratxa qualificadora. Proporcioneu comentaris visuals basats en les respostes del servidor.
Així, en resum, el cervell està al servidor i el client té finalitats de visualització i enviament d'esdeveniments. Això us estalvia molts errors i casos extrems, a més de facilitar les actualitzacions i les solucions. El flux lògic Simulem una explicació de com aniria un motor de sistema de ratxa mínim eficient quan un usuari completa una acció:
L'usuari completa una acció de ratxa de qualificació. El client envia un esdeveniment al servidor com a metadades. Això podria ser "L'usuari X va completar l'acció Y a la marca de temps Z". El servidor rep aquest esdeveniment i fa la validació bàsica. És un usuari real? Estan autenticats? És vàlida l'acció? La zona horària és coherent? Si això passa, el servidor recupera les dades de ratxa de l'usuari de la base de dades. A continuació, convertiu la marca de temps de l'acció rebuda a la zona horària local de l'usuari. Deixeu que el servidor compare les dates del calendari (no les marques de temps) a la zona horària local de l'usuari: Si és el mateix dia, llavors l'acció és redundant i no hi ha cap canvi en elratlla. Si és l'endemà, la ratxa s'allarga i augmenta en 1. Si hi ha un buit de més d'un dia, la ratxa es trenca. Tanmateix, aquí és on podeu aplicar la mecànica de gràcia. Si es perd el mecanisme de gràcia, restableix la ratxa a 1.
Si trieu desar les dades històriques dels assoliments de les fites, actualitzeu variables com ara "ratxa més llarga" o "total de dies actius". Aleshores, el servidor actualitza la base de dades i respon al client. Alguna cosa com això:
{ "current_streak": 48, "ratxa_més llarga": 50, "total_active_days": 120, "streak_extended": cert, }
Com a mesura addicional, el servidor hauria de tornar a intentar-ho o rebutjar i notificar al client quan alguna cosa falla durant el procés. Construint per a la resiliència Com s'ha esmentat abans, els usuaris que perden una ratxa a causa d'errors o temps d'inactivitat del servidor són una experiència d'usuari terrible, i els usuaris no esperen patir-ho. Per tant, el vostre sistema de ratxa hauria de tenir salvaguardes per a aquests escenaris. Si el servidor està inactiu per manteniment (o qualsevol motiu), considereu permetre una finestra temporal d'hores addicionals per arreglar-lo perquè les accions es puguin enviar tard i encara comptar. També podeu optar per notificar als usuaris, especialment si la situació pot afectar una ratxa en curs. Nota: establiu una porta posterior d'administració on les dades es puguin restaurar manualment. Els errors són inevitables, i alguns usuaris trucarien a la vostra aplicació o es posarien en contacte per donar suport que la seva ratxa s'ha trencat per un motiu que no podien controlar. Hauríeu de poder restaurar manualment les ratlles si, després de la investigació, l'usuari té raó. Conclusió Una cosa queda clara: les ratlles són realment poderoses a causa de com funciona la psicologia humana a un nivell fonamental. El millor sistema de ratxa que hi ha és el que els usuaris no pensen conscientment. S'ha convertit en una rutina de resultats immediats o de progrés visible, com raspallar-se les dents, que esdevé un hàbit habitual. I només ho diré: no tots els productes necessiten un sistema de ratlles. Realment hauríeu de forçar la coherència només perquè voleu usuaris actius diaris? La resposta pot ser molt bé "no".
