Encargas una app interna como si fuera un producto de consumo: onboarding tipo Duolingo, ilustraciones de empty state, un store listing que nadie va a ver. Seis meses después la gente sigue mandándose Excels por correo y usando la herramienta «oficial» solo cuando hay auditoría.
El error no es de diseño gráfico. Es de marco. Una app de la App Store compite con otras apps. Las apps internas de empresa compiten con el Excel que ya funciona, con el WhatsApp del equipo y con el café de la oficina donde se resuelven las cosas de verdad. Nadie las eligió. Nadie las puede desinstalar. Y aun así, pueden fracasar.
Este artículo explica por qué no se diseñan igual, qué cambia en roles, adopción y onboarding, y cómo lo planteamos en Truman cuando el usuario final no es un cliente: es tu plantilla.
Por qué las apps internas de empresa no se diseñan como un producto de consumo
Un producto de consumo se diseña para seducir: la persona puede no abrirlo nunca. Una herramienta interna se diseña para que el trabajo salga. El criterio no es «¿le gusta?». Es «¿deja de usar el equipo paralelo?».
Eso cambia casi todo. En consumo, reduces fricción para que alguien se registre. En interno, la fricción está en el proceso real: un parte de incidencias, un inventario, una validación de calidad, un cierre de caja. Si la app pide diez campos que en papel eran tres, has diseñado contra el trabajo, no para el trabajo.
En Truman lo vemos cuando un briefing llega con referencias de fintech o de apps de productividad de moda. Esas referencias sirven para densidad, tipografía o componentes. No sirven para decidir qué pantalla es la principal. La pantalla principal de una app interna es la tarea que se hace veinte veces al día, no la que queda bien en un mockup.
El usuario no eligió tu app: diseñaste contra Excel
En una store, si fallas, te desinstalan. En una empresa, si fallas, te rodean. Aparece la hoja compartida, el grupo de WhatsApp, el PDF impreso y firmado. La app oficial sigue «en producción». El trabajo se hace fuera.
93
apps de media desplegadas por empresa; las grandes (≥2.000 empleados) llegan a 231
Okta, Businesses at Work 2024
Esa cifra no dice que tu herramienta vaya a triunfar. Dice lo contrario: entra en un ecosistema saturado. Cada login extra, cada menú que no parece el del resto de herramientas de la casa, cada campo que no se puede autocompletar con datos que ya existen, es un motivo para volver al Excel.
El diseño útil aquí es poco glamuroso. Atajos de teclado. Valores por defecto sacados del último registro. Búsqueda que entiende códigos internos, no solo nombres bonitos. Estados de error que dicen qué hacer, no «ha ocurrido un problema». Impresión y exportación el día uno, no en el backlog del trimestre siguiente.
| Decisión de diseño | Producto de consumo | App interna |
|---|---|---|
| Éxito | Retención, reviews, viralidad | Tarea completada sin workaround |
| Onboarding | Activación en la primera sesión | Formación + primeros casos reales |
| Empty states | Ilustración y copy de marca | Datos de ejemplo o importación |
| Personalización | Temas, perfiles, discovery | Roles, turnos, planta, idioma |
| Si duele usarlas | Churn | Excel paralelo y datos sucios |
Roles, permisos y el flujo que no existe en B2C
En una app de consumo hay, como mucho, usuario y admin. En una interna hay quien crea, quien valida, quien solo consulta, quien cierra el mes y quien no debería ver salarios ni márgenes. Si diseñas una sola interfaz y «ya esconderemos botones», vas a rehacer pantallas a mitad de desarrollo.
En EIM Jeanología el trabajo no era lucir una interfaz de producto. Era construir una herramienta digital para un entorno industrial con lógica propia: datos, flujos y un usuario que no está explorando, está operando. Eso obliga a sentarse con quien usa el sistema, no solo con quien lo encarga.
Weddle no es una intranet, pero enseña lo mismo por el otro lado: cuando hay varios tipos de usuario (quien organiza, quien participa, quien gestiona), el diseño UX/UI se rompe si fuerzas un único recorrido. En interno el coste de ese error no es una mala review: es un supervisor que no puede aprobar a tiempo y un operario que inventa un atajo.
¿Puedes dibujar en una servilleta quién crea, quién aprueba y quién solo mira? Si no, todavía no tienes una app. Tienes una lista de pantallas.
El modelo que pedimos antes de diseñar: actores, objetos (pedido, incidencia, lote, factura) y verbos por actor. Sin eso, el prototipo miente. Y el prototipo que miente es el que luego pide «un pequeño cambio de permisos» que mueve media arquitectura. Si te interesa el lado técnico de ese modelado, el problema se parece al de los errores de UX que hacen abandonar una app, pero con una diferencia: aquí el abandono es silencioso.
El onboarding interno no es el de reducir churn
En producto de consumo el onboarding existe para que no te borren. En interno existe para que el primer martes real no se caiga el turno. No es lo mismo, aunque las dos cosas se llamen «primera experiencia».
Un carousel de beneficios es ruido. Lo que funciona: cuentas de formación con datos reales (o realistas), un checklist de las cinco tareas del puesto, y un humano de referencia la primera semana. La app puede acompañar —tooltips en contexto, no un tour de veinte pasos— pero no sustituye a la jefa de planta.
El artículo que escribimos sobre diseño de onboarding para reducir churn vale para producto. Para interno, añade una capa que el B2C no tiene: política. Quién obliga a usarla, qué se deja de aceptar en papel, qué pasa si alguien no carga el parte. Sin esa decisión de dirección, el mejor UX del mundo convive con la hoja de cálculo. El diseño no puede ganar una batalla que la organización no quiere dar.
Cómo se mide la adopción si nadie puede desinstalar
Descargas y DAU mienten. Todo el mundo «tiene» la app si IT la instala. La pregunta es otra: ¿qué porcentaje de tareas críticas sale por el sistema y no por el canal paralelo?
Métricas que sí sirven: tiempo hasta completar la tarea núcleo, tasa de error por campo, número de tickets de «¿dónde se hace X?», volumen de exportaciones a Excel (si sube a las tres semanas, tienes un problema de interfaz, no de cultura), y entrevistas cortas en planta a los 15 y 45 días.
También importa el dispositivo real. Muchas internas se diseñan en un Mac de 14 pulgadas y se usan en un Windows de 2018, con guantes, o en un Android de empresa con teclado lento. La decisión nativa vs híbrida no es ideológica: es de contexto. Lo desglosamos en app nativa vs híbrida en 2026. En almacén o fábrica, un webview que se come la memoria es un defecto de producto, no un detalle técnico.
Tip técnico: el empty state interno es un importador
En consumo, el empty state vende el producto. En interno, el empty state tiene que llenarse. Diseña desde el día uno la importación (CSV, Excel, API del ERP) y el modo «copiar el registro de ayer». Si la primera pantalla vacía pide crear todo a mano, has regalado una semana al Excel. En código: un endpoint de seed con datos de formación y un flag de entorno para que nadie mezcle el sandbox con producción. Suena obvio. Se olvida en el 80% de los kickoffs que vemos.
Qué pedimos en Truman antes de dibujar pantallas
Discovery con usuarios reales, no solo con el sponsor. Observación de la tarea actual —aunque sea fea— durante al menos un ciclo completo (un turno, un cierre, una semana). Lista de excepciones: lo que el Excel permite y el proceso «oficial» niega. Esas excepciones son el producto.
Si tu app interna necesita un vídeo de diez minutos para crear un registro, no tienes un problema de formación. Tienes un problema de diseño. El Excel no tenía vídeo y aun así ganaba.
Luego prototipamos el flujo más frecuente, no la home. Testeamos con tres perfiles distintos. Y solo entonces hablamos de componente, de desarrollo web o de app empaquetada. El orden inverso —tecnología primero, usuarios después— es el que produce herramientas bonitas que conviven con la hoja de cálculo.
Antes de encargar una app interna, verifica esto
- ¿Has listado las 8–12 tareas que pagan el sueldo, no el mapa de pantallas?
- ¿Sabes qué Excel, WhatsApp o PDF va a sustituir, y en qué fecha?
- ¿Están dibujados los roles (crear, aprobar, consultar) antes del prototipo?
- ¿Has observado un ciclo real de trabajo, no solo la reunión de kickoff?
- ¿El empty state incluye importación o datos de ensayo, no una ilustración?
- ¿El dispositivo y las condiciones reales (guantes, ruido, PC viejo) están en el brief?
- ¿Hay dueño de adopción en dirección, no solo un interlocutor de IT?
- ¿Cómo vas a medir el workaround, no solo los logins?
Preguntas frecuentes sobre apps internas de empresa
¿Cuándo una empresa necesita una app interna y no un Excel bien montado?
Cuando hay validaciones, varios roles, histórico que no cabe en un archivo compartido, o cuando el error humano sale caro (trazabilidad, calidad, dinero). Si el proceso lo hace una persona con una hoja y no hay aprobaciones, un Excel gobernado sigue siendo la respuesta honesta.
¿Qué diferencia hay entre una app interna y un producto SaaS de consumo?
El SaaS se diseña para que te elijan y te paguen. La interna se diseña para que el trabajo salga dentro de un proceso que ya existe. Métricas, onboarding, empty states y permisos cambian. Copiar el patrón de una app de store es el atajo que más proyectos internos tuerce.
¿Cómo se consigue la adopción si el uso es obligatorio?
La obligación no basta. Hay que retirar el canal paralelo en una fecha, formar en la tarea (no en la app) y medir si el trabajo sale por el sistema. Sin corte del Excel, la obligatoriedad es teatro: todo el mundo «usa» la app y nadie la usa.
¿Hace falta una app nativa para un proceso interno?
Solo si el contexto lo pide: offline, cámara, sensores, rendimiento en dispositivos justos, o distribución controlada. Muchos procesos viven bien en una web bien hecha. La pregunta no es nativa o híbrida: es dónde y cómo se trabaja. Eso se decide en discovery, no en la slide de tecnología.
