Formació com a Producte: Per Què l'Onboarding és Part del Desenvolupament
El 80% de les funcionalitats d'un programari empresarial no s'usen més d'una vegada. No és problema de producte: és enginyeria mal classificada com a documentació.
El 80% de les funcionalitats d'un programari empresarial mai s'usen més d'una vegada.
No és perquè siguen males funcionalitats. És perquè ningú sap que existixen, no troben com activar-les, o la primera vegada que les van provar van generar prou confusió com per a no tornar.
Açò no és un problema de producte. És un problema d'enginyeria que la majoria d'equips continua classificant com a "documentació".
El mite del handoff
El model tradicional d'entrega de programari empresarial és una seqüència de transferències:
- L'equip de producte definix els requisits.
- Els desenvolupadors construïxen les funcionalitats.
- L'equip de suport o un partner extern escriu la documentació.
- Recursos Humans o un consultor d'adopció organitza les sessions de formació.
- L'usuari final intenta entendre què fa l'eina.
Cada transferència introduïx pèrdua. La documentació s'escriu sense accés al context tècnic que va motivar les decisions. Les sessions de formació es dissenyen sense haver vist com es fa servir el programari en el dia a dia. Els usuaris reben PDFs que es queden sense obrir.
El resultat és predictible: programari que tècnicament funciona i operativament no s'adopta.
Com detallem a Del Full de Càlcul al Dashboard: la Resistència al Canvi, el problema d'adopció rarament és dels usuaris. És de com se'ls entrega el producte.
L'onboarding és part de la superfície del producte
La superfície d'un producte no són només les seues funcionalitats. És el que els usuaris poden descobrir i usar sense ajuda.
Un botó amb un nom confús no és una funcionalitat — és soroll. Un flux que requerix consultar un manual per a començar no és producció — és treball en progrés. Una eina on el 70% d'usuaris només usa el 10% de les funcionalitats no és un producte avançat — és un producte fallit al 90%.
La mètrica real d'"acabat" no és "el codi funciona". És "l'usuari aconseguix el seu objectiu sense ajuda externa".
El que costa no fer-ho
Mirem els números d'un projecte típic de programari a mida:
| Concepte | Onboarding com a add-on | Onboarding integrat |
|---|---|---|
| Desenvolupament (3 mesos) | 60.000€ | 60.000€ |
| Documentació post-entrega | 8.000€ | Inclòs |
| Sessions de formació | 5.000€ | Mínim |
| Suport intensiu (3 mesos post-llançament) | 12.000€ | 4.000€ |
| % funcionalitats realment usades | 30-40% | 70-85% |
| Cost real per funcionalitat útil | 190€/h efectiva | 75€/h efectiva |
El càlcul no és només el que costa entrenar els usuaris. És el que costa haver construït funcionalitats que després ningú usa perquè ningú va saber trobar-les.
Què significa tractar l'onboarding com a producte
No és escriure millor documentació. És construir el programari de manera que la documentació siga innecessària per al 80% de les tasques.
En la pràctica, açò es traduïx en coses concretes:
- Empty states amb instruccions: quan una pantalla està buida, no mostres "no hi ha dades". Mostra què fer perquè n'hi haja.
- Onboarding contextual, no genèric: el primer click de l'usuari ha de portar a una acció real, no a un tour de 12 passos que es tanca al segon.
- Microcopy que ensenya: els noms dels botons, les etiquetes dels camps i els missatges d'error són la documentació que sí es llig.
- Defaults intel·ligents: si el 80% dels usuaris configurarà un camp igual, no preguntes — preomple.
- Progressió per ús: les funcionalitats avançades no apareixen fins que l'usuari ha dominat les bàsiques.
Cadascun d'estos punts és treball d'enginyeria. No és treball de suport ni de màrqueting. És codi que s'escriu en el mateix sprint que la lògica de negoci.
Per què la majoria d'equips no ho fan
La raó principal és comptable: l'onboarding és invisible en una demo. Quan un sponsor demana "veure el progrés", el que vol veure són funcionalitats noves, no la fricció que s'ha eliminat de les existents.
Com hem analitzat a L'Sponsor Absent: el Patró Darrere del 70% dels Fracassos, els projectes que premien l'aparença de progrés sobre la usabilitat real generen exactament este tipus de programari: tècnicament complet, operativament abandonat.
La segona raó és la divisió del treball. Si els desenvolupadors s'ocupen del codi, l'equip d'UX del disseny, el de docs dels manuals i el d'adopció de les sessions, ningú és l'amo del moment crític: la primera vegada que un usuari real obri l'eina.
Com ho construïm a SAUCO
A SAUCO tractem cada projecte amb un criteri simple: si l'usuari necessita preguntar com fer una cosa més d'una vegada, açò és un bug.
Açò no significa que escrivim manuals gegants. Significa el contrari: invertim el temps de "documentació" en empty states ben dissenyats, en microcopy que explica sense necessitar tooltips, i en fluxos on el següent pas és obvi.
El criteri d'"acabat" per a una funcionalitat inclou una pregunta concreta: pot un usuari nou del client, sense formació prèvia, completar la tasca en menys de 5 minuts?
Si la resposta és no, la funcionalitat no està acabada. No importa que el codi passe els tests.
Açò ens obliga a involucrar-nos amb els usuaris reals abans del llançament, no després. És més treball. Però el resultat és programari on el percentatge de funcionalitats realment usades s'acosta al 100% en lloc del 30%.
Estàs construint programari que tècnicament funciona però ningú usa? Consulta la nostra guia sobre digitalització de processos de negoci o agenda una sessió amb l'equip.