Cada aplicación de negocio que construí necesitaba las mismas cuatro páginas
1
Homepage
One per user group. Their top actions, and what needs them now.
2
Utility
Login, reset password, 404. Required, and not where the app gets good.
3
Entity
One per object. The list, the view that suits it, and adding a record.
4
Detail
One record in full, its actions, and everything related to it.
Four years of internal tools and portals, and about 90% of the pages were one of these.
He construido decenas de aplicaciones de negocio en los últimos cuatro años. Herramientas internas, CRM, ERP, intranets, portales de clientes, portales de proveedores, salas de acuerdos. Diferentes empresas, diferentes datos y, básicamente, el mismo conjunto de páginas cada vez.
Cuatro familias. Cubren aproximadamente el 90% de lo que necesita una aplicación de negocio. Conocerlas convierte la pregunta más difícil al inicio de un proyecto, qué páginas necesito realmente, en una breve lista de verificación.
Me refiero a aplicaciones en las que los usuarios inician sesión. Los directorios públicos y los sitios de marketing funcionan de otra manera. Una aplicación de negocio tiene un alcance estrecho y definido: un portal de clientes existe para que los clientes vean sus proyectos y tareas, y para que tu equipo pueda verlos todos. Esa estrechez es lo que hace que un conjunto pequeño de páginas sea suficiente.
1. La página de inicio, y primero la cuestión del grupo de usuarios
Antes de diseñar una página de inicio, enumera los grupos que inician sesión. Clientes y personal interno. Profesores, padres y alumnos. Empleados y equipo financiero. Esta decisión va antes que todo lo demás, porque determina si construyes una sola página de inicio o varias.
Mi regla general: si más de la mitad de los bloques de la página diferirían entre dos grupos, asigna a cada grupo su propia página de inicio. Si es menos, usa una sola página con condiciones de visibilidad en algunos bloques.
Una página de inicio compartidaLos grupos coinciden mayormente
- Un puñado de bloques mostrados por condición
- Una sola página que rediseñar si cambia la marca
- Se vuelve ilegible rápidamente tras unas pocas condiciones
Una página de inicio por grupoLos grupos quieren cosas distintas
- Cada página parece diseñada específicamente para ellos
- Sin lógica de condiciones que rastrear
- Los cambios compartidos deben hacerse dos veces
Qué debe incluir: las dos a cuatro acciones que más realiza este grupo y aquello sobre lo que deben actuar ahora. Nada más. La aplicación tiene un alcance estrecho, por lo que la página de inicio también debe serlo.
Un gestor de gastos lo hace concreto. Un empleado inicia sesión para enviar una solicitud, por lo que el formulario está a un clic y, debajo, sus propias solicitudes pendientes. El equipo financiero inicia sesión para aprobar, por lo que ven las solicitudes que esperan por ellos. No todas las solicitudes enviadas alguna vez, ni las denegadas en marzo. La lista sobre la que deben actuar.
Todo lo demás puede vivir en la barra de navegación, y normalmente debería estar ahí.
2. Páginas de utilidad, en las que no deberías perder tiempo
Inicio de sesión. Registro, o un registro desactivado si se trata de una herramienta interna y el acceso es por invitación. Olvido de contraseña y restablecimiento de contraseña. El error 404. Un flujo de onboarding si quieres obligar a alguien a completar su perfil antes de acceder a la aplicación.
Todo es aburrido. Todo es obligatorio. Y nada de esto es lo que hace que tu aplicación sea buena.
Esta es la familia de páginas que preferiría no construir y, con Softr, no lo hago: ya vienen configuradas, y el trabajo consiste en el estilo y el texto. Si estás construyendo desde cero, presupuesta tiempo para ellas de todos modos, porque todas existen en cada aplicación y olvidar la 404 es hacer que alguien llegue a un callejón sin salida sin forma de volver.
3. Páginas de entidad, una por objeto
Una vez que la base de datos es correcta, estas casi se escriben solas. Una página por cada tabla que signifique algo para el usuario. Un CRM tiene contactos, empresas, acuerdos y tareas. Entra en HubSpot y eso es exactamente lo que ves en la navegación.
La página enumera los registros, y el formato es una decisión que conviene tomar por cada objeto:
- Una tabla cuando el objetivo es encontrar una fila entre muchas y la densidad de datos ayuda.
- Un tablero kanban para cualquier cosa con un estado que la gente mueva, como tareas o acuerdos.
- Un calendario cuando la fecha es el criterio principal de navegación.
- Una cuadrícula de tarjetas cuando un logotipo o una foto es la forma en que la gente reconoce un registro.
Puedes ofrecer dos opciones, como pestañas en la misma página, cuando diferentes personas trabajan de manera distinta. En mi CRM, la página de acuerdos tiene el pipeline por defecto y una vista de tabla al lado.
Las acciones también pertenecen aquí. Añadir un registro. Exportar la lista como CSV, que no cuesta nada y alguien siempre lo pide. Importar un CSV, si los usuarios llegan con lotes de datos.
A veces la página de entidad es la funcionalidad completa. Una tabla de documentos con un nombre y un archivo, sin relación con nada más, puede ser simplemente una lista con opciones de editar y eliminar en cada fila. No hace falta una página de detalles.
4. Páginas de detalles y qué hay debajo de ellas
Normalmente, sí quieres abrir un registro. Una fila de tabla no tiene espacio para trabajar, y una empresa tiene una descripción, un sitio web y notas que deben estar en algún lugar.
Una página de detalles tiene tres partes.
El registro en sí, con los campos que vale la pena mostrar, que son más de los que muestra la página de entidad. Las acciones sobre él: editar, eliminar, cambiar estado, asignar a alguien. Los permisos se aplican individualmente, por lo que borrar un contacto puede ser solo para administradores mientras que todos pueden editarlo.
Luego está la parte que siempre añado y la que hace que una aplicación se sienta terminada: los registros relacionados, enumerados debajo. Abre una empresa y verás sus contactos, sus acuerdos y sus interacciones pasadas. Abre una tarea y verás el proyecto al que pertenece.
Abre esto en un modal en lugar de en una página completa, ya sea centrado o deslizándose desde el lateral. La URL no cambia, la lista permanece detrás y volver consiste en cerrar un panel en lugar de cargar una página. En una lista en la que alguien está trabajando, esa diferencia es lo que define la velocidad percibida de la aplicación.
Las dos páginas extra que conviene planificar
Un panel de control. Gráficos y recuentos. A veces es la página de inicio, otras veces es una página independiente cuando hay contenido suficiente.
Un formulario en su propia página. Esto es un argumento de mantenimiento. Si hay cuatro lugares diferentes donde se puede crear una empresa y cada uno tiene su propio formulario configurado, añadir un campo implica editar cuatro formularios y arriesgarse a olvidar uno. Crea el formulario una sola vez en su propia página y haz que cada botón abra esa página en un modal. Un solo formulario que mantener.
Estructurar un ERP de la misma manera
Las cuatro familias se mantienen en aplicaciones más grandes, solo que se agrupan. En un ERP organicé la navegación por departamento en lugar de por objeto: inventario, ventas, finanzas. Detrás de cada uno, las mismas páginas de entidad.
Dos cosas que hice diferente allí y volvería a hacer. Algunas páginas consolidan dos objetos, por lo que ventas incluye pedidos y clientes juntos, ya que quienes trabajan en ventas operan con ambos. Y la página de inicio no enumera todos los productos, sino aquellos con menos de 100 unidades en stock, bajo un encabezado que indica que requieren atención. En una página de inicio, una lista filtrada por acciones pendientes es mejor que una lista completa.
Define bien la base de datos y las páginas vendrán solas
- 1Definir el alcanceQué permite hacer a los usuarios
- 2Listar grupos de usuariosQuién accede y qué necesita cada uno
- 3Diseñar las tablasUna por objeto real, campos correctos
- 4Derivar las páginasUna página de entidad por objeto, detalles detrás
Una tabla por objeto real, con los campos que le corresponden. Una tarea tiene una descripción, una fecha de entrega y un responsable. Una empresa tiene un nombre, un sitio web y un sector. Si esto falla, ningún diseño de página podrá salvarte.
La IA es realmente buena en esta parte. Describe el CRM que quieres y obtendrás una primera base de datos razonable, que es como empiezo la mayoría de mis proyectos ahora.
Conocer el marco de trabajo es lo que permite abandonarlo
El constructor de IA de Softr produce aplicaciones con exactamente esta estructura. También lo hacen los demás. Lo que plantea una pregunta válida: si la herramienta ya conoce el patrón, ¿para qué aprenderlo?
Porque la versión generada es un valor predeterminado, y los predeterminados son el promedio de las aplicaciones de todos, no de la tuya. Los momentos que hacen que una aplicación sea buena son las desviaciones: no crear la página de interacciones, abrir los detalles en un panel lateral en lugar de una ruta, filtrar la lista de inicio según lo que requiere atención. Un constructor de IA no propondrá eso, porque nada en tu prompt le indicó que tu equipo trabaja con una lista todo el día.
Encuentro lo mismo con los agentes en general, tanto en Claude Code como en un constructor de aplicaciones. Son rápidos produciendo la forma estándar, y lo que tú aportas es saber qué parte de esa forma estándar no te sirve. Eso solo se consigue habiendo construido la herramienta a mano las veces suficientes como para tener una opinión al respecto.
Así que usa el generador. Luego abre lo que haya creado y cambia las tres cosas que habrías hecho de manera diferente.