De l’onboarding a l’on-living

Moltes experiències digitals continuen entenent l’onboarding com una mena de peatge inicial: abans d’utilitzar el producte, l’usuari ha de passar per pantalles de benvinguda, recorreguts guiats, tooltips acumulats, checklists de primers passos i explicacions sobre funcionalitats que encara no sap si necessitarà.

La intenció acostuma a ser bona. Volem ajudar, reduir la incertesa i mostrar el valor del producte com més aviat millor. Però sovint ho fem en el pitjor moment possible: quan l’usuari encara no té context, no ha formulat una necessitat concreta i, en molts casos, només vol començar.

El resultat és una paradoxa habitual en el disseny de producte: intentem ensenyar massa aviat i acabem generant més fricció que aprenentatge. L’usuari rep informació, però encara no sap com interpretar-la. Veu funcionalitats, però no n’entén la rellevància. Completa un recorregut, però oblida bona part del que se li ha explicat tan bon punt entra en l’experiència real.

Potser el problema no és que els usuaris no vulguin aprendre. Potser el problema és que els demanem que aprenguin abans de viure el producte.

Per això, l’onboarding necessita una mirada més àmplia. No com una porta d’entrada feixuga, concentrada en els primers minuts, sinó com una capa d’aprenentatge contínua, contextual i progressiva. Una experiència que acompanya l’usuari mentre avança, que ensenya quan existeix una intenció real i que ajuda a descobrir valor sense convertir cada interacció en una classe magistral.

Dissenyar un bon onboarding ja no consisteix només a explicar com funciona un producte. Consisteix a crear una experiència que sàpiga ensenyar en el moment adequat.

Per què l’onboarding tradicional es queda curt

L’onboarding tradicional acostuma a partir d’una idea raonable: si expliquem bé el producte al principi, l’usuari n’entendrà abans el valor i s’hi mourà amb més seguretat. El problema apareix quan aquesta explicació inicial intenta resoldre massa coses alhora.

Moltes experiències fallen per tres motius molt simples: ensenyen massa aviat, ensenyen massa de cop i ensenyen fora del moment d’ús.

Ensenyen massa aviat perquè presenten funcionalitats, opcions o conceptes quan l’usuari encara no ha tingut ocasió de necessitar-los. En aquest punt, la informació pot ser correcta, però no sempre és útil. L’usuari encara no té una pregunta concreta, no ha comès cap error, no ha explorat prou i no sap quina part de tot el que se li està explicant serà rellevant per a ell.

També ensenyen massa de cop. Un recorregut inicial amb cinc, set o deu passos pot semblar ordenat des del punt de vista de l’equip de producte, però per a l’usuari pot convertir-se en una càrrega. Cada tooltip afegeix una petita explicació, cada pantalla introdueix una promesa, cada checklist proposa una acció. Per separat, tot sembla raonable. Juntament, pot generar la sensació d’estar estudiant el producte abans de poder-lo utilitzar.

I, sobretot, ensenyen fora del moment d’ús. Explicar una funcionalitat avançada abans que l’usuari arribi a necessitar-la és com donar instruccions sobre una eina que encara no té entre mans. Pot llegir-les, fins i tot entendre-les, però difícilment les recordarà quan arribi el moment real d’aplicar-les.

Per això molts usuaris completen un onboarding i, tot i així, tornen a sentir-se perduts minuts després. No necessàriament perquè l’onboarding estigués mal redactat, sinó perquè estava mal situat. L’aprenentatge necessita context. Necessita una acció, una intenció, un dubte o una decisió concreta.

A més, molts recorreguts inicials no responen tant a una necessitat de l’usuari com a una ansietat interna de l’equip: volem mostrar tot el que hem construït, explicar cada avantatge, destacar cada funcionalitat i assegurar-nos que ningú no es perdi res important. Però ensenyar més no sempre vol dir ajudar millor.

L’alternativa no és eliminar l’ajuda. Seria un error pensar que una interfície s’ha d’explicar sola en tots els casos. L’alternativa és distribuir millor l’aprenentatge: menys concentració al principi i més acompanyament durant l’ús. Menys explicació anticipada i més orientació contextual. Menys recorregut obligatori i més ajuda en el moment en què realment pot canviar l’experiència de l’usuari.

De l’onboarding a l’on-living

Si l’onboarding tradicional concentra l’aprenentatge en els primers minuts, l’on-living proposa una lògica diferent: ensenyar mentre l’usuari viu el producte.

No es tracta de substituir una paraula per una altra ni d’inventar una etiqueta més per parlar d’experiència d’usuari. La diferència és en l’enfocament. L’onboarding mira sobretot l’inici de la relació: com el producte rep una persona, com li explica el més bàsic i com l’ajuda a fer els primers passos. L’on-living, en canvi, entén que l’aprenentatge no s’acaba quan l’usuari completa una pantalla de benvinguda.

Un producte s’aprèn a poc a poc. S’aprèn en descobrir una funcionalitat nova. S’aprèn en cometre un error i entendre com corregir-lo. S’aprèn en tornar-hi després de diverses setmanes sense utilitzar-lo. S’aprèn quan canvia una necessitat, quan apareix una funcionalitat nova, quan l’usuari passa d’un ús bàsic a un de més avançat o quan el producte mateix evoluciona.

Des d’aquesta mirada, la interfície deixa de ser només un espai on executar tasques i es converteix també en un entorn que acompanya. No amb tutorials constants, sinó amb senyals, pistes i explicacions que apareixen quan poden ajudar de debò. L’aprenentatge no s’imposa des de fora del flux, sinó que s’integra dins de l’acció.

Això canvia la manera de dissenyar. Ja no n’hi ha prou de preguntar-se què ha de saber l’usuari en començar. També cal preguntar-se què necessita entendre en cada moment del seu recorregut: què ha de descobrir ara, què pot esperar, què convé reforçar després d’una acció, quina ajuda necessita quan alguna cosa falla i quina informació només serà útil quan hagi guanyat més confiança.

L’on-living no vol dir omplir el producte de missatges, tooltips o ajudes permanents. De fet, pot voler dir justament el contrari: reduir l’explicació inicial i dissenyar millor els moments en què l’orientació té sentit. Una bona experiència no ho ensenya tot tota l’estona. Ensenya el necessari, en el moment adequat i amb el nivell just de profunditat.

Per això, passar de l’onboarding a l’on-living implica entendre l’aprenentatge com una capa contínua de l’experiència. Una capa que acompanya l’usuari durant tota la vida del producte, que s’adapta al seu nivell de maduresa i que li permet avançar sense sentir que cada pas depèn d’haver llegit abans un manual invisible.

No es tracta de fer més tutorials. Es tracta de dissenyar productes que ensenyen progressivament mentre s’utilitzen.

Pistes situacionals

Una de les maneres més efectives de passar de l’onboarding a l’on-living és dissenyar pistes situacionals. És a dir, petites ajudes que apareixen vinculades a una acció, un dubte o un moment concret dins de l’experiència.

No parlem necessàriament de grans missatges ni d’explicacions extenses. De vegades, una bona pista situacional pot ser un text breu en un camp de formulari, un empty state ben redactat, un suggeriment després de completar una acció, un missatge d’error que explica com avançar o una nota al costat d’un control que podria generar confusió.

La diferència és en el moment. Una pista situacional no intenta ensenyar tot el producte de manera anticipada. Apareix quan l’usuari és a prop de necessitar aquella informació. Quan està a punt de prendre una decisió. Quan ha arribat a una pantalla buida i no sap quin és el pas següent. Quan ha de triar entre diverses opcions. Quan alguna cosa no ha anat bé. Quan acaba de completar una tasca i pot descobrir una possibilitat nova.

Per exemple, un empty state no s’hauria de limitar a dir que “encara no hi ha elements”. Pot explicar què apareixerà en aquell espai, per què és útil i quina és la primera acció raonable. Un missatge al costat d’un control no hauria de repetir l’evident, sinó aclarir una conseqüència: què passa en activar una opció, a qui afecta un canvi o què pot passar després. Un error no s’hauria de limitar a assenyalar la fallada, sinó ajudar l’usuari a corregir-la sense fer-lo sentir culpable.

Aquest tipus d’ajuda funciona perquè neix d’una intenció real. L’usuari no rep informació en abstracte; està intentant fer alguna cosa. Per això l’explicació té més possibilitats de ser entesa, recordada i aplicada. La interfície no interromp l’aprenentatge per explicar, sinó que aprofita el mateix moment d’ús per ensenyar.

La clau és no confondre ajuda contextual amb soroll contextual. No tot necessita un aclariment. No cada botó necessita un tooltip. No cada pantalla necessita una frase d’acompanyament. Quan les pistes apareixen pertot arreu, deixen d’orientar i comencen a decorar. I quan tot sembla important, res no destaca de debò.

Dissenyar bones pistes situacionals exigeix criteri: detectar on l’usuari realment dubta, on pot cometre un error, on necessita confiança per continuar i on una petita explicació pot desbloquejar una acció. La pregunta no hauria de ser “què més podem explicar?”, sinó “què necessita entendre l’usuari just aquí per avançar millor?”.

En aquest sentit, les pistes situacionals no substitueixen el disseny clar. El complementen. Una bona interfície ha de reduir la necessitat d’explicació sempre que pugui. Però quan l’explicació és necessària, ha d’aparèixer a prop de la intenció, no lluny d’aquesta.

Coachmarks intel·ligents

Els coachmarks poden ser una eina útil dins d’una experiència digital, però només quan s’utilitzen amb precisió. La seva funció no hauria de ser obligar l’usuari a recórrer una visita guiada, sinó ajudar-lo a entendre alguna cosa rellevant en el moment adequat.

Un coachmark ben dissenyat assenyala, orienta i aclareix. Pot servir per presentar una funcionalitat nova, explicar un canvi important a la interfície, destacar una acció poc evident o ajudar a comprendre la jerarquia d’una pantalla complexa. El seu valor és fer visible allò que l’usuari podria passar per alt, no afegir una capa d’explicació sobre cada element del producte.

El problema apareix quan els coachmarks es converteixen en una seqüència obligatòria de passos. En aquell moment deixen d’acompanyar i comencen a interrompre. L’usuari no sent que la interfície l’estigui ajudant, sinó que li estigui demanant atenció abans de permetre-li avançar. I quan això passa, molts senzillament fan clic a “següent” sense llegir, tanquen l’ajuda o intenten escapar del recorregut com més aviat millor.

Per això, un bon coachmark hauria de respectar sempre la tasca principal. No hauria de tapar el contingut més important, bloquejar una acció necessària ni exigir una lectura llarga per poder continuar. Si apareix, ho ha de fer amb un propòsit clar: reduir un dubte, explicar una novetat o facilitar una decisió.

També n’importa la freqüència. Una ajuda que apareix una vegada pot ser útil. Una ajuda que apareix constantment pot convertir-se en soroll. El producte ha de recordar el que l’usuari ja ha vist, evitar repetir explicacions innecessàries i permetre que cada persona tanqui, posposi o ignori una indicació sense sentir-se atrapada.

La segmentació també és clau. No tots els usuaris necessiten la mateixa orientació. Una persona que hi entra per primera vegada pot necessitar una explicació bàsica. Un usuari recurrent potser només necessita entendre què ha canviat. Un perfil avançat pot valorar accessos directes, opcions de configuració o novetats concretes, però no una explicació elemental de funcionalitats que ja domina.

Dissenyar coachmarks intel·ligents implica pensar menys en el recorregut i més en l’oportunitat. Què necessita veure l’usuari ara? Què podria no entendre sense una petita ajuda? Quina informació pot esperar? Quina indicació deixarà de ser útil després de la primera vegada?

Quan s’utilitzen bé, els coachmarks no substitueixen una bona interfície. La reforcen. Funcionen com petits senyals dins del camí, no com un recorregut paral·lel que obliga l’usuari a aturar-se. Menys visita guiada, més orientació puntual. Menys explicació acumulada, més ajuda ajustada al context.

Progressió i descobriment

Una bona experiència no ha de mostrar tota la seva complexitat des del primer moment. De fet, en molts productes digitals, ensenyar massa aviat pot ser una manera d’amagar allò que és important.

Quan una interfície presenta totes les seves funcionalitats, opcions i configuracions des de l’inici, transmet una sensació de potència, però també pot generar bloqueig. L’usuari entén que el producte és capaç de fer moltes coses, però no sempre sap per on començar, què és prioritari o què necessita realment en aquell moment.

Aquí entra en joc la idea de progressió. L’aprenentatge dins del producte hauria d’acompanyar el nivell de maduresa de l’usuari. Primer, l’essencial. Després, el complementari. Més endavant, l’avançat. No perquè la resta no tingui valor, sinó perquè no tot té el mateix valor en el mateix moment.

El progressive disclosure, o revelació progressiva, parteix precisament d’aquesta lògica: mostrar el necessari per avançar ara i revelar més possibilitats a mesura que l’usuari guanya context, confiança i necessitat. Ben aplicat, no empobreix l’experiència. L’ordena.

Això és especialment important en productes SaaS, eines B2B, plataformes de gestió, productes amb intel·ligència artificial o interfícies amb moltes funcionalitats. En aquests entorns, el repte no sol ser únicament que l’usuari descobreixi que alguna cosa existeix, sinó que la descobreixi quan pot entendre per a què serveix i com pot aprofitar-la.

Un producte amb massa opcions visibles des del principi pot semblar complet, però també pot sentir-se com un panell de control infinit. Botons, menús, filtres, automatitzacions, permisos, integracions, dashboards, configuracions i mòduls competeixen per l’atenció abans que l’usuari hagi trobat el seu primer moment de valor.

La progressió ajuda a evitar aquesta sensació. Ho pot fer mitjançant modes bàsics i avançats, recomanacions contextuals, funcionalitats desbloquejades per l’ús, plantilles inicials, presets, accessos progressius o explicacions que apareixen quan l’usuari arriba a una nova fase. La qüestió no és limitar artificialment el producte, sinó construir una corba de descobriment més raonable.

També hi ha un matís important: amagar no sempre és simplificar. Si una funcionalitat clau està massa amagada, l’usuari pot no descobrir mai el valor real del producte. Per això, dissenyar progressió exigeix equilibri. Cal reduir la càrrega inicial sense convertir el producte en una caixa tancada. Cal prioritzar sense invisibilitzar. Cal guiar sense decidir per l’usuari.

L’objectiu no és que l’usuari vegi menys. És que vegi millor. Que entengui què pot fer ara, què podrà explorar després i com cada nou nivell de complexitat apareix quan ja té sentit.

Al capdavall, progressar també és aprendre. I una interfície ben dissenyada no obliga l’usuari a dominar-ho tot el primer dia. Li permet començar amb claredat, avançar amb confiança i descobrir profunditat a mesura que la necessita.

Ajuda contextual, però mesurable

Dissenyar aprenentatge contextual no significa omplir la interfície de petites ajudes i confiar que funcionin. Si l’ajuda forma part de l’experiència, també hauria de formar part del mesurament del producte.

Una pista situacional, un coachmark, un missatge d’error millorat o un suggeriment després de completar una acció no són només elements d’interfície. Són intervencions dissenyades per ajudar l’usuari a avançar. I, com qualsevol intervenció rellevant, s’haurien de poder avaluar: redueixen la fricció?, milloren l’activació?, ajuden a completar una tasca?, faciliten el descobriment d’una funcionalitat clau?, eviten errors?, redueixen les consultes a l’equip de suport?

L’aprenentatge contextual no s’hauria de dissenyar únicament des de la intuïció. La intuïció és necessària, però no suficient. Moltes vegades creiem saber on es bloqueja l’usuari, però les dades mostren una altra cosa: passos amb abandonament inesperat, formularis que es repeteixen, accions que s’inicien però no es completen, funcionalitats importants que gairebé ningú no descobreix o tiquets de suport que pregunten una vegada i una altra pel mateix.

Mesurar ajuda a detectar aquests punts de fricció i a decidir on té sentit intervenir. No es tracta de mesurar per mesurar, sinó d’entendre si l’ajuda apareix al lloc adequat i si realment canvia alguna cosa en el comportament de l’usuari.

Alguns senyals poden ser especialment útils: activació de nous usuaris, èxit de tasca, temps fins al valor, ús de funcionalitats clau, reducció d’errors, disminució de tiquets de suport, abandonament en passos concrets o millora en la finalització de fluxos crítics. En productes SaaS o B2B, també pot ser rellevant observar si una ajuda contextual accelera l’adopció d’una funcionalitat, millora la configuració inicial o redueix la dependència de formació externa.

Però el mesurament també ha de tenir criteri. No tot es redueix al fet que l’usuari faci més clics. Una ajuda pot ser eficaç precisament perquè evita una acció innecessària, redueix un dubte o impedeix un error abans que es produeixi. Per això convé combinar mètriques quantitatives amb senyals qualitatius: entrevistes, sessions d’usabilitat, anàlisi de tiquets, feedback dins del producte o enregistraments de sessió quan el context ho permeti.

La pregunta important no és només si l’usuari ha vist l’ajuda. La pregunta és si l’ajuda li ha servit per avançar millor.

Aquest enfocament permet millorar l’experiència de manera contínua. Si una pista no es llegeix, potser apareix massa tard. Si sempre es tanca, potser interromp. Si es llegeix, però no millora la tasca, potser explica alguna cosa irrellevant. Si redueix errors o accelera una acció important, probablement està complint la seva funció.

L’ajuda contextual també ha d’aprendre. S’ha d’ajustar, reduir, desaparèixer o evolucionar segons el comportament real dels usuaris. Perquè ensenyar dins del producte no és afegir missatges per tranquil·litzar l’equip. És dissenyar intervencions útils, observar-ne l’impacte i millorar l’experiència amb evidències.

El risc

L’ajuda contextual pot millorar molt una experiència, però també la pot deteriorar si es dissenya sense criteri. Una interfície plena de pistes, tooltips, pop-ups, badges, missatges de benvinguda, avisos laterals i recomanacions constants pot acabar generant just el contrari del que buscava: més càrrega cognitiva, més interrupcions i menys claredat.

El problema no és en cada element per separat. Un tooltip pot ser útil. Un missatge contextual pot desbloquejar una acció. Un badge pot destacar una novetat rellevant. El problema apareix quan tots competeixen alhora per l’atenció de l’usuari. Aleshores la interfície deixa d’acompanyar i comença a reclamar atenció de manera permanent.

En aquest punt, l’ajuda es converteix en soroll. Ja no orienta, sinó que distreu. Ja no redueix la incertesa, sinó que afegeix capes. Ja no fa que el producte se senti més clar, sinó més insistent.

A més, una ajuda mal dissenyada pot transmetre una sensació incòmoda: que el producte no confia en la capacitat de l’usuari. Explicar l’obvi, repetir instruccions innecessàries o guiar cada pas com si qualsevol decisió fos perillosa pot resultar infantilitzador. L’usuari no necessita que la interfície el tracti com algú incapaç. Necessita que l’ajudi quan realment hi ha un dubte, una fricció o una conseqüència important que cal entendre.

També existeix el risc de convertir cada novetat en una interrupció. Quan tot s’anuncia, tot es ressalta i tot apareix com a important, l’usuari aprèn a ignorar-ho. Tanca missatges sense llegir, evita recorreguts guiats, deixa de parar atenció als senyals i desenvolupa una mena de ceguesa davant de l’ajuda del producte.

Per això, el bon aprenentatge contextual necessita límits. Ha d’aparèixer poc, aparèixer bé i desaparèixer quan ja no aporta. Ha de tenir memòria: no repetir allò que l’usuari ja ha entès. Ha de tenir jerarquia: no col·locar una explicació secundària per sobre d’una tasca principal. I ha de tenir humilitat: acceptar que, de vegades, la millor ajuda és no afegir res més.

La pregunta no hauria de ser quanta ajuda podem incorporar, sinó quanta ajuda necessita realment aquest moment. Hi ha pantalles que necessiten una explicació clara. Hi ha errors que requereixen una sortida guiada. Hi ha funcionalitats noves que mereixen un senyal. Però també hi ha molts casos en què el millor disseny consisteix a simplificar la interacció, millorar el text principal o eliminar una decisió innecessària.

L’ajuda contextual no ha de ser una capa decorativa que compensi una interfície confusa. Ha de ser una intervenció precisa. Quan apareix sense necessitat, molesta. Quan apareix tard, no serveix. Quan apareix sempre, el seu valor desapareix.

Dissenyar productes que ensenyen en context implica també saber callar. Perquè una experiència que acompanya bé no és la que parla tota l’estona, sinó la que sap quan intervenir i quan deixar que l’usuari avanci.

Conclusió

El millor onboarding no és el que ho explica tot. És el que permet a l’usuari avançar amb confiança.

Aquesta confiança no es construeix únicament en els primers minuts d’ús. Es construeix cada vegada que la interfície ajuda a entendre una decisió, redueix un dubte, acompanya un error, presenta una possibilitat nova o revela una capa de complexitat en el moment adequat.

Per això, dissenyar experiències que ensenyen en context implica deixar de pensar l’aprenentatge com una fase separada del producte. L’usuari no aprèn primer i utilitza després. Aprèn mentre utilitza. Descobreix mentre avança. Entén millor quan l’explicació apareix a prop d’una acció real, no com una lliçó anticipada que ha de recordar més endavant.

El pas de l’onboarding a l’on-living no consisteix a afegir més missatges, més recorreguts o més ajudes visibles. Consisteix a dissenyar una relació més intel·ligent entre producte i usuari. Una relació que acompanya sense envair, guia sense controlar i permet descobrir valor de manera progressiva.

En productes cada vegada més complexos, modulars i canviants, aquesta manera d’ensenyar serà cada vegada més important. No n’hi ha prou de tenir bones funcionalitats. També cal ajudar que les persones les entenguin, les adoptin i les incorporin a la seva manera de treballar sense sentir-se perdudes davant d’un sistema massa gran.

Una experiència que ensenya bé no converteix l’usuari en alumne permanent. Li dona autonomia. Li permet començar amb claredat, equivocar-se amb menys por, descobrir possibilitats quan tenen sentit i créixer dins del producte sense dependre sempre d’una explicació externa.

Al capdavall, ensenyar millor és dissenyar millor. Perquè quan la interfície sap quan parlar, quan acompanyar i quan apartar-se, el producte deixa de ser una cosa que l’usuari ha de desxifrar i comença a convertir-se en una cosa que pot viure.

El teu producte ensenya l’usuari només al principi, o l’acompanya quan realment necessita aprendre?