Estou seguro de que escoitaches falar de raias ou usaches unha aplicación cunha. Pero algunha vez te preguntas por que as raias son tan populares e poderosas? Ben, é obvio que as aplicacións queren a maior atención posible, pero ademais, sabías que cando a popular aplicación de aprendizaxe Duolingo introduciu widgets de iOS para mostrar raias, o compromiso do usuario aumentou un 60 %. O sesenta por cento é un cambio masivo no comportamento e demostra como se poden usar os patróns de "racha" para aumentar o compromiso e impulsar o uso. Na súa forma máis básica, unha raia é o número de días consecutivos que un usuario completa unha actividade específica. Algunhas persoas tamén o definen como un hábito "gamificado" ou unha métrica deseñada para fomentar o uso consistente. Pero as raias transcenden máis aló de ser unha métrica ou un rexistro nunha aplicación; é máis psicolóxico que iso. Os instintos humanos son fáciles de influír cos factores correctos. Fíxate nestes tres factores: progreso, orgullo e medo a perderte (comúnmente chamado FOMO). Que teñen en común todos estes? Esforzo. Canto máis esforzo pon en algo, máis configura a súa identidade, e así é como as raias cruzan no mundo da psicoloxía do comportamento. Agora, cun gran poder vén unha gran responsabilidade e, por iso, hai un lado escuro nas raias. Neste artigo, analizaremos os principios de psicoloxía, UX e deseño detrás da construción dun sistema de raias eficaz. Veremos (1) por que o noso cerebro responde case instintivamente á actividade das raias, (2) como deseñar as raias de xeito que realmente axude aos usuarios e (3) o traballo técnico que implica a construción dun patrón de raias. A psicoloxía detrás das raias Para deseñar e construír un sistema de raias eficaz, necesitamos comprender como se aliña coa forma en que os nosos cerebros están conectados. Como, que o fai tan eficaz na medida en que sentimos tanta dedicación intensa para protexer as nosas raias? Hai tres principios de psicoloxía interesantes e ben documentados que apoian o que fai que as raias sexan tan poderosas e adictivas. Aversión á perda Esta é probablemente a forza máis forte detrás das raias. Dígoo porque a maioría das veces, case non podes evitar isto na vida. Pense niso deste xeito: se un amigo che dá 100 dólares, estarías feliz. Pero se perdes 100 dólares da túa carteira, iso doería moito máis. O peso emocional desas situacións non é igual. A perda doe moito máis que a ganancia se sente ben. Levámolo máis aló e digamos que che dou 100 $ e pídoche que xogues unha aposta. Hai un 50 % de posibilidades de gañar outros 100 $ e un 50 % de que perdas os 100 $ orixinais. Leváriao? Non o faría. A maioría da xente non o faría. Esa é aversión á perda. Se o pensas ben, é lóxico, é comprensible, é humano. O concepto detrás da aversión á perda é que sentimos a dor de perder algo o dobre que o pracer de gañar algo de igual valor. En termos psicolóxicos, as perdas perduran máis que as ganancias. Probablemente vexa como isto se relaciona coas raias. Para construír unha raia notable, require esforzo; a medida que crece unha raia, a motivación que hai detrás comeza a esmorecer; ou máis exactamente, comeza a ser secundario. Aquí tes un exemplo: digamos que o teu amigo ten unha serie de tres días pechando os seus "Move Rings" no seu Apple Watch. Case nada teñen que perder máis aló de querer acadar o seu obxectivo e ser coherentes. Ao mesmo tempo, tes unha impresionante racha de 219 días. O máis probable é que esteas atrapado polo medo a perdelo. O máis probable é que non estea pensando no logro neste momento; trátase máis de protexer o teu esforzo investido, e iso é a aversión á perda. Duolingo explica como a aversión á perda contribúe á reticencia do usuario a romper unha longa racha, mesmo nos seus días máis preguiceiros. En certo modo, unha racha pode converterse nun hábito cando se instala a aversión á perda. O modelo de comportamento de Fogg (B = MAP) Agora que entendemos o medo a perder o esforzo investido en rachas máis longas, outra pregunta é: que nos fai facer a cousa en primeiro lugar, día tras día, mesmo antes de que a racha se faga grande? Diso trata o modelo de comportamento de Fogg. É relativamente sinxelo. Un comportamento (B) só ocorre cando tres factores - Motivación (M), Habilidade (A) e Prompt (P) - se aliñan ao mesmo tempo. Así, a ecuación B=MAP. Se algún destes factores, mesmo un, falta nese momento, o comportamento non ocorrerá. Polo tanto, para que un sistema de raias sexa eficiente e recorrente, os tres factores deben estar presentes: Motivación Isto é fráxil e non é algo que estea constantemente presente. Hai días nos que estásentusiasmado por aprender español, e días que nin sequera sentes un ápice de forza de vontade para aprender o idioma. A motivación por si mesma para construír un hábito non é fiable e é unha batalla perdida desde o primeiro día. CapacidadePara compensar as limitacións da motivación, a habilidade é fundamental. Neste contexto, a habilidade significa a facilidade de acción, é dicir, o esforzo é tan sinxelo que non é realista dicir que non é posible. A maioría das aplicacións usan isto intencionadamente. Apple Fitness só precisa que te pares un minuto nunha hora para conseguir o teu obxectivo de Stand. Duolingo só necesita unha lección completada. Estas tarefas non requiren tanto esforzo. A barreira é tan baixa que incluso nos teus peores días, podes facelo. Pero o esforzo combinado dunha racha en curso é onde comeza a idea de perder esa racha. PromptIsto é o que completa a ecuación. Os humanos somos esquecedores por natureza, así que si, a habilidade pode levarnos ata o 90%. Pero un aviso lémbranos actuar. As raias son persistentes polo deseño, polo que hai que lembrar constantemente aos usuarios que actúen. Para ver o poderoso que pode ser un aviso, Duolingo fixo unha proba A/B para ver se unha pequena insignia vermella na icona da aplicación aumentou o uso consistente. Produciu un aumento do 6% nos usuarios activos diarios. Só un distintivo vermello. Limitacións do modelo Dito todo isto, hai unha limitación ao modelo Fogg pola que os críticos e a investigación moderna notaron que un deseño que depende demasiado de avisos, como notificacións agresivas, corre o risco de crear fatiga mental. As notificacións constantes e as horas extras poderían provocar que os usuarios se movan. Entón, coidado con iso. Efecto Zeigarnik Como te sentes cando deixas unha tarefa de proxecto a medio facer? Iso irrita a moita xente porque as tarefas inacabadas ocupan máis espazo mental que as que completamos. Cando algo se fai e desaparece, tendemos a esquecelo. Cando se deixa algo sen facer, tende a pesar na nosa mente. É precisamente por iso que os produtos dixitais usan indicadores de progreso artificiais, como a barra de finalización do perfil de Upwork, para que un usuario saiba que o seu perfil só está "completado ao 60 %". Incita ao usuario a rematar o que comezou.
Vexamos outro exemplo. Tes cinco tarefas nunha aplicación de lista de tarefas e, ao final do día, só marcas catro delas como completadas. Moitos de nós sentirémonos incumpridos por mor desa única tarefa inacabada. Ese, aí mesmo, está o efecto Zeigarnik. O efecto Zeigarnik foi demostrado pola psicóloga Bluma Zeigarnik, quen describiu que tendemos a manter as tarefas incompletas activas na nosa memoria máis tempo que as tarefas completadas. Un patrón de raia naturalmente aproveita isto no deseño UX. Digamos que estás no día 63 dunha racha de aprendizaxe. Nese momento, estás nun patrón continuo de asuntos pendentes. O teu cerebro raramente se esquece diso xa que está situado no fondo da túa mente. Neste punto, o teu cerebro convértese en quen che envía notificacións. Cando xuntas estas forzas psicolóxicas, comezas a comprender verdadeiramente por que as raias non son só unha función normal da aplicación; son capaces de remodelar o comportamento humano. Pero nalgún lugar -non podo dicir exactamente cando, xa que é diferente para todos-, as cousas chegan a un punto no que unha racha pasa de "diversión" a algo que sentes que non podes permitirte o luxo de perder. Non queres que se desperdicien 58 días de esforzo, non? Iso é o que fai efectivo un sistema de raias. Se se fan ben, as raias axudan aos usuarios a crear hábitos sorprendentes que consigan un obxectivo. Podería ser ler a diario ou ir ao ximnasio de forma consistente. Estas accións repetidas (ás veces pequenas) compútanse co paso do tempo e fanse evidentes na nosa vida diaria. Pero cada moeda ten dúas caras. A delgada liña entre o hábito e a compulsión Se seguiches, xa podes dicir que hai un lado escuro para os sistemas de raias. A formación de hábitos consiste na coherencia cun obxectivo repetido. A compulsión, con todo, é a coherencia de traballar nun obxectivo que xa non é necesario pero que se mantén por medo ou presión. É unha liña fina como unha navalla. Lavas os dentes todas as mañás sen pensalo; é automático e instintivo, cun obxectivo claro de ter bo alento. Esa é unha raia que forma un bo hábito. Un sistema de raias éticas dá aos usuarios espazo para respirar. Se, por algún motivo, non te cepillas pola mañá, podes cepillarte ao mediodía. Permítese a imperfección sen medo a perder un longo esforzo. A compulsión toma o camiño oposto, polo que unha racha fai que te angustias, te sintas culpable ou mesmo esgotado e, ás veces, parece que non conseguiches nada, a pesar de todo o teutraballo. Non actúas porque queiras, senón porque estás inconscientemente aterrorizado de ver o teu progreso restablecer a cero. Alguén incluso describiu isto perfectamente: "Sentín que estaba a facer trampa, pero simplemente non me importaba. Non son nada sen a miña racha". Isto mostra as raias extremas que poden ter un individuo. Na medida en que os usuarios comezan a vincular a súa autoestima a unha métrica arbitraria en lugar do obxectivo orixinal ou a razón pola que comezaron a racha en primeiro lugar. A raia convértese en quen son, non só no que fan. Un sistema de raias éticas ben deseñado debería parecer un alento para o usuario, non unha presión ou unha obriga. Isto refírese ao equilibrio da motivación intrínseca e extrínseca. A motivación extrínseca (recompensas externas, evitar castigos) pode que os usuarios se inicien, pero a motivación intrínseca (facer a tarefa para un obxectivo persoal como aprender español porque realmente queres comunicarte cun ser querido) é máis forte para o compromiso a longo prazo. Un bo sistema debe gravitar cara á motivación intrínseca cun uso coidadoso dos elementos extrínsecos, é dicir, lembrar aos usuarios ata onde chegaron, non ameazalos co que poderían perder. De novo, é unha liña fina. Unha proba sinxela ao deseñar un sistema de raias é levar un tempo e pensar se os teus produtos gañan diñeiro vendendo solucións á ansiedade que creou o teu produto. Se si, hai unha gran probabilidade de que esteas explotando usuarios. Entón, a seguinte pregunta é: Se escollo usar a raia, como o deseño de forma que realmente axude aos usuarios a alcanzar os seus obxectivos? A UX de Good Streak System Design Creo que aquí é onde a maioría dos proxectos logran un sistema de raias eficaz ou o desordenan por completo. Imos pasar por algúns principios de UX dun bo deseño de raias. Mantéñase sen esforzo Probablemente xa escoitaches isto antes, quizais en libros como Atomic Habits, pero paga a pena mencionar que unha das formas máis sinxelas de formar hábitos é facendo que a acción sexa pequena e sinxela. Isto é semellante ao factor de habilidade que comentamos no modelo de comportamento de Fogg. A primeira regra de calquera deseño de raia debe ser facer que a acción necesaria sexa o máis pequena posible, aínda que se consegue o progreso. Se unha acción diaria require forza de vontade para completar, esa acción non pasará de cinco días. Por que? Non podes estar motivado cinco días seguidos. Caso en cuestión: se executas unha aplicación de meditación, non necesitas que os usuarios pasen por unha sesión de 20 minutos só para manter a racha. Proba un só minuto, quizais mesmo algo tan pequeno como trinta segundos, no seu lugar. Como di o refrán, pequenas pingas de auga fan o poderoso océano). Os pequenos esforzos compílanse en grandes logros co tempo. Ese debería ser o obxectivo: eliminar a fricción, especialmente cando o momento pode ser difícil. Cando os usuarios estean estresados ou abrumados, infórmeles de que simplemente aparecer, mesmo por uns segundos, conta como esforzo. Proporcionar comentarios visuais claros Os humanos son visuais por natureza. Na maioría das veces, necesitamos ver algo que crer; existe esta necesidade de visualizar as cousas para entendelas mellor e poñelas en perspectiva. É por iso que os patróns de raias adoitan usar elementos visuais, como gráficos, marcas de verificación, aneis de progreso e cuadrículas, para visualizar o esforzo. Mira o gráfico de contribucións de GitHub. É unha simple visualización da coherencia. Con todo, os desenvolvedores inhalan como osíxeno.
A clave é non facer que un sistema de raias se sinta abstracto. Debería sentirse real e gañado. Por exemplo, os aneis de actividade de Duolingo e Apple Fitness usan deseños de animación limpos ao finalizar unha serie e GitHub mostra datos históricos da consistencia dun usuario ao longo do tempo.
Use o bo tempo Mencionei anteriormente que os humanos son xeralmente esquecidos por natureza e que as indicacións poden axudar a manter o impulso. Sen avisos, a maioría dos novos usuarios esquécense de seguir. A vida pode estar ocupada, a motivación desaparece e as cousas pasan. Mesmo os usuarios de longa data se benefician das indicacións, aínda que a maioría das veces xa están bloqueados dentro do ciclo de hábitos. Non obstante, ata a persoa máis comprometida pode perder accidentalmente un día. O teu sistema de raias definitivamente necesita recordatorios. Os recordatorios de avisos máis utilizados son as notificacións push. O tempo é realmente importante cando se traballa con notificacións push. O tipo de aplicación tamén importa. Enviar unha notificación ás 9 a.m. dicindo "Non practicaches hoxe" é raro para unha aplicación de aprendizaxe porque moitos teñen cousas que facer un día antes de pensar en completar unha lección. Non obstante, se falamos dunha aplicación de fitness, isoé razoable e quizais ata se espera que se lembre máis cedo no día. As notificacións push varían significativamente segundo a categoría da aplicación. As aplicacións de fitness, por exemplo, ven un maior compromiso coas notificacións da mañá (7-8 da mañá), mentres que as aplicacións de produtividade poden ter un mellor rendemento a primeira hora do mediodía. A clave é probar A/B o tempo da túa aplicación en función do comportamento dos teus usuarios en lugar de asumir que as cousas son únicas para todos. O que funciona para unha aplicación de meditación pode non funcionar para un rastreador de codificación. Outros métodos de aviso son os puntos vermellos na icona da aplicación e mesmo os widgets da aplicación. Os estudos varían, pero a persoa media desbloquea o seu dispositivo entre 50 e 150 veces ao día (PDF). Se un usuario ve un punto vermello nunha aplicación ou nun widget que indica unha raia actual cada vez que desbloquea o seu teléfono, aumenta o compromiso. Simplemente non esaxeres; o aviso debe servir como recordatorio, non como un chisco. Celebrar fitos Un sistema de rachas debería tentar celebrar fitos para reavivar as emocións, especialmente para os usuarios que se atopan nunha racha. Cando un usuario chega ao día 7, ao día 30, ao día 50, ao día 100 e ao día 365, deberías facerlle un gran problema. Recoñece os logros, especialmente para os usuarios de longa data.
Como vimos anteriormente, Duolingo descubriu isto e implementou un gráfico animado que celebra os fitos con confeti. Algunhas plataformas incluso ofrecen bonos substanciais que validan os esforzos dos usuarios. E isto pode ser beneficioso para as aplicacións, de xeito que os usuarios tenden a compartir os seus fitos publicamente nas redes sociais. Outro beneficio é a anticipación que vén antes de acadar fitos. Non se trata só de manter a racha viva sen fin; os usuarios teñen algo que esperar. Use mecanismos de graza A vida é imprevisible. A xente distrae. Calquera bo sistema de raias debe esperar imperfección. Unha das maiores ameazas psicolóxicas para un sistema de rachas é o restablecemento completo a cero despois de só un só día perdido. Un sistema de raias "ético" debería proporcionar ao usuario algo de soltura. Digamos que tes unha racha de aprendizaxe de xadrez de 90 días. Estiveches consistente durante tres bos meses, e un día, o teu teléfono morre mentres viaxas, e así, o 90 pasa a ser 0: todo, todo ese esforzo, bórcase e o progreso desaparece. O usuario pode estar completamente devastado. A idea de reconstruílo desde cero é tan desmoralizadora que o esforzo non paga a pena. No peor dos casos, un usuario pode abandonar a aplicación despois de sentirse como un fracaso. Considere engadir un mecanismo de "graza" ao seu sistema de raias:
Streak FreezePermite aos usuarios perder un día intencionalmente sen penalizacións. Tempo extraPermita unhas horas (2-3) despois do prazo habitual antes de activar un reinicio. Modelos de decadenciaEn lugar dun restablecemento completo, a racha diminúe unha pequena cantidade, por exemplo, 10 días dedúcense da racha por día perdido.
Use un ton alentador Comparemos dúas mensaxes mostradas aos usuarios cando se rompe unha raia:
"Perdeches a túa racha de 42 días. Comeza de novo". "Apareceches durante 42 días seguidos. É un progreso incrible! Queres tentalo outra vez?"
Ambos transmiten a mesma información, pero o impacto emocional é diferente. A primeira mensaxe probablemente faría que un usuario se sinta desmoralizado e faría que abandonase. A segunda mensaxe celebra o que xa se conseguiu e anima suavemente ao usuario a tentalo de novo. Retos de deseño de sistemas Streak Antes de entrar nos detalles técnicos da construción dun sistema de raias, debes ser consciente dos retos que podes enfrontar. As cousas poden complicarse, como podería esperar. Manexo de fusos horarios Hai un motivo polo que o manexo da hora e da data está entre os conceptos máis difíciles cos que tratan os desenvolvedores. Hai formato, internacionalización e moito máis que ter en conta. Permíteme preguntarche isto: que conta como un día? Sabemos que o mundo funciona en diferentes zonas horarias e, por se isto non fose suficiente, algunhas rexións teñen o horario de verán (DST) que ocorre dúas veces ao ano. Por onde comezas a manexar estes casos extremos? Que conta como o "comezo" do mañá? Algúns desenvolvedores intentan evitar isto usando un fuso horario central, como UTC. Para algúns usuarios, isto daría resultados correctos, pero para algúns podería estar desactivado nunha hora, dúas horas ou máis. Esta inconsistencia arruina a experiencia do usuario. Aos usuarios lles importa menos como manexas o tempo entre bastidores; o único que esperan é que se realizan unha acción de racha ás 23:40 horas, debería rexistrarse a esa hora exacta, no seu contexto. Debería definir "un día" en función da zona horaria local do usuario, non da hora do servidor. Por suposto, podes tomar o máis fácilenruta e restablece as raias a nivel mundial para todos os usuarios á medianoite UTC, pero estás a crear moito inxusto. Alguén en California sempre ten oito horas extra para completar a súa tarefa que alguén que vive en Londres. Ese é un fallo de deseño inxusto que castiga a certos usuarios pola súa localización. E se esa persoa en Londres só está de visita, completa unha tarefa e volve a outra zona horaria? Unha solución eficaz para todo isto é pedir aos usuarios que establezan explícitamente a súa zona horaria durante a incorporación (preferentemente despois da primeira autenticación). É unha boa idea incluír unha nota sutil de que proporcionar información da zona horaria só se usa para que a aplicación faga un seguimento preciso do progreso, en lugar de utilizarse como datos de identificación persoal. E outra boa idea é facer que esa configuración cambie. Suxiro que alguén evite manexar directamente a lóxica do fuso horario nunha aplicación. Use bibliotecas de datas probadas e verdadeiras, como Moment.js ou pytz (Python), etc. Non é necesario reinventar a roda para algo tan complexo como isto. Días perdidos e casos Edge Outro desafío do que debes preocuparte son os casos extremos incontrolables, como os usuarios que durmirán demasiado, o tempo de inactividade do servidor, o atraso, os fallos de rede, etc. Usar a idea de mecanismos de graza, como os que comentamos anteriormente, pode axudar. Unha xanela de graza de dúas horas pode axudar tanto ao usuario como ao desenvolvedor, no sentido de que os usuarios non son castigados con rigor por circunstancias vitais incontrolables. Para os desenvolvedores, as fiestras de graza son útiles neses momentos incontrolables nos que o servidor cae no medio da noite. Sobre todo, nunca confíes no cliente. Valide sempre no lado do servidor. O servidor debe ser a única fonte de verdade. Prevención de trampas De novo, non podo subliñar isto o suficiente: asegúrese de validar todo o lado do servidor. Os usuarios son humanos, e os humanos poden facer trampas se se lles dá a oportunidade. É inevitable. Podes probar:
Almacenando todas as accións con marcas de tempo UTC. O cliente pode enviar a súa hora local, pero o servidor pode convertela inmediatamente a UTC e validala en función da hora do servidor. Deste xeito, se a marca de tempo do cliente está sospeitosamente lonxe, o sistema pode rexeitala como un erro e a IU pode responder en consecuencia. Usando o seguimento baseado en eventos. Noutras palabras, almacena un rexistro de cada acción con metadatos, incluíndo información como o ID do usuario, o tipo de acción realizada e a marca de tempo e a zona horaria. Isto axuda coa validación.
Construíndo un motor de sistema Streak Este non é un tutorial de código, polo que evitarei botarche un montón de código. Vou manter isto práctico e describirei como as cousas funcionan xeralmente nun motor do sistema de raias en canto á arquitectura, o fluxo e a fiabilidade. Arquitectura básica Como dixen varias veces, fai do servidor a única fonte de verdade para os datos de raia. A arquitectura pode ir algo así no servidor:
Almacena os datos de cada usuario nunha base de datos. Almacena o almacén de raias actual (por omisión 0) como un número enteiro. Almacene a preferencia de fuso horario, é dicir, a cadea de fuso horario de IANA (xa sexa implícitamente a partir da marca de tempo local ou explícitamente solicitando ao usuario que seleccione o seu fuso horario). Por exemplo, "America/New_York". Manexa toda a lóxica para determinar se a raia continúa ou rompe, cunha comprobación da zona horaria relativa á zona horaria local do usuario.
Mentres tanto, no lado do cliente:
Mostra a raia actual, que normalmente se obtén do servidor. Envía accións realizadas en forma de metadatos ao servidor para validar se o usuario realizou unha acción de serie de cualificación. Proporcione feedback visual baseado nas respostas do servidor.
Así, en resumo, o cerebro está no servidor e o cliente está para mostrar e enviar eventos. Isto aforrache moitos fallos e casos extremos, ademais de facilitar as actualizacións e as correccións. O fluxo lóxico Imos simular un paso a paso de como funcionaría un motor de sistema de raias mínimo eficiente cando un usuario completa unha acción:
O usuario completa unha acción de racha de cualificación. O cliente envía un evento ao servidor como metadatos. Isto podería ser "O usuario X realizou a acción Y na marca de tempo Z". O servidor recibe este evento e realiza a validación básica. Este é un usuario real? Están autenticados? É válida a acción? É coherente a zona horaria? Se isto pasa, o servidor recupera os datos de raia do usuario da base de datos. A continuación, converte a marca de tempo da acción recibida na zona horaria local do usuario. Deixa que o servidor compare as datas do calendario (non as marcas de tempo) na zona horaria local do usuario: Se é o mesmo día, entón a acción é redundante e non hai ningún cambio noraia. Se é o día seguinte, a raia esténdese e increméntase en 1. Se hai un desfase de máis dun día, a racha rompe. Non obstante, aquí é onde podes aplicar a mecánica de graza. Se se perde o mecanismo de gracia, restablece a raia a 1.
Se decides gardar os datos históricos dos logros dos fitos, actualiza variables como "raia máis longa" ou "días activos totais". A continuación, o servidor actualiza a base de datos e responde ao cliente. Algo así:
{ "raia_actual": 48, "raia_máis longa": 50, "total_activo_días": 120, "streak_extended": verdadeiro, }
Como medida adicional, o servidor debería tentalo de novo ou rexeitalo e notificarlle ao cliente cando algo falla durante o proceso. Construíndo para a Resiliencia Como se mencionou anteriormente, os usuarios que perden unha racha debido a erros ou ao tempo de inactividade do servidor é unha experiencia de usuario terrible, e os usuarios non esperan sufrir a caída. Así, o seu sistema de raias debería ter garantías para eses escenarios. Se o servidor está inactivo por motivos de mantemento (ou por calquera motivo), considera permitir unha xanela temporal de horas adicionais para arranxalo para que as accións poidan enviarse tarde e aínda contan. Tamén pode optar por notificar aos usuarios, especialmente se a situación pode afectar a unha racha en curso. Nota: Establece unha porta traseira de administración onde os datos se poidan restaurar manualmente. Os erros son inevitables, e algúns usuarios chamarían á túa aplicación ou contactarían para apoiar que a súa racha se rompeu por un motivo que non podían controlar. Deberías poder restaurar manualmente as raias se, despois da investigación, o usuario ten razón. Conclusión Unha cousa queda clara: as raias son realmente poderosas debido a como funciona a psicoloxía humana nun nivel fundamental. O mellor sistema de raias que existe é aquel no que os usuarios non pensan conscientemente. Converteuse nunha rutina de resultados inmediatos ou de progreso visible, como cepillarse os dentes, que se converte nun hábito habitual. E só o digo: non todos os produtos necesitan un sistema de raias. Deberías realmente forzar a coherencia só porque queres usuarios activos diarios? A resposta pode ser moi ben "non".
