Construye MVPs internos con Softr
Aprende a convertir una necesidad interna en un prototipo con Softr, conectando datos, preparando pantallas y comprobando cómo lo utilizarían distintos perfiles del equipo.
Encuentra tu punto de partida
Encaja cuando queréis probar una aplicación interna acotada con datos de práctica y comprobar su recorrido antes de plantear su implantación.
- Duración y sesiones
- 12 horas en directo · 6 sesiones de 2 h.
- Tamaño del grupo
- Hasta 12 participantes por formador como referencia, ajustable según la práctica y el feedback.
Qué aprenderás
- 01
Definir los usuarios, las tareas y las pantallas esenciales de un caso interno acotado.
- 02
Conectar datos de práctica y configurar su presentación y navegación en Softr.
- 03
Comprobar un recorrido con perfiles de prueba y registrar los criterios de aceptación y los límites de acceso disponibles.
Una propuesta de trabajo
Construiréis un prototipo de portal de solicitudes internas con Softr y su base de datos nativa. Delimitaréis qué necesita hacer quien solicita y quien revisa, prepararéis las pantallas esenciales y comprobaréis el recorrido con datos y usuarios de prueba, incluidos los accesos que deben quedar bloqueados.
Adaptamos la selección y la profundidad de los módulos al punto de partida y los objetivos del grupo.
01Del problema al prototipo
Usuarios, tareas, datos y alcance mínimo para un caso interno acotado.
Trabajarás en
- Acotar una solicitud interna y separar las tareas de quien solicita y quien revisa.
- Definir los campos mínimos: identificador, asunto, solicitante, estado y contexto.
- Escribir criterios de aceptación sobre navegación, información visible y acceso por perfil.
- Práctica
- Diseñar el recorrido de consulta de una solicitud con una lista, una página de detalle y una tabla de permisos.
- Cómo lo comprobarás
- Un alcance pequeño con campos, pantallas y criterios comprobables; quedan anotadas las funciones que se dejan fuera.
02Construir en Softr
Páginas, bloques y conexión a una fuente compatible con el entorno acordado.
Trabajarás en
- Crear una tabla de práctica en Softr Databases y relacionar sus campos con bloques de lista y detalle.
- Preparar navegación, etiquetas y mensajes para que se pueda encontrar una solicitud y entender su estado.
- Configurar usuarios y grupos de prueba y aplicar restricciones de datos; distinguirlas de ocultar páginas, bloques o botones.
- Práctica
- Construir las pantallas del portal y limitar la lectura del solicitante a sus registros, manteniendo la vista de revisión acordada.
- Cómo lo comprobarás
- Un prototipo conectado a los datos de aula, con campos correctos y reglas de lectura definidas para ambos perfiles.
03Probar el recorrido
Permisos disponibles, validación con perfiles y registro de ajustes pendientes.
Trabajarás en
- Recorrer la app con los perfiles de solicitante y revisor y comparar lo observado con la tabla de permisos.
- Probar un enlace de detalle a una solicitud ajena y comprobar el acceso al registro, además de su ausencia en la lista.
- Revisar las acciones disponibles según el plan y registrar las correcciones, límites y tareas necesarias antes de cualquier uso real.
- Práctica
- Corregir un portal que filtra la lista pero deja accesible una solicitud ajena por su enlace; repetir las pruebas con ambos perfiles.
- Cómo lo comprobarás
- Una matriz de pruebas con resultado esperado, observado y corrección; los límites de acceso se comprueban y no se deducen del aspecto de la interfaz.
El portal debe proteger el registro, no solo ocultarlo
Ejemplo docente
Práctica propuesta: prototipar un portal de solicitudes, consultar información con distintos perfiles de prueba y comprobar que la navegación y los accesos responden a la tarea elegida. Documentamos límites y ajustes pendientes; las funciones se seleccionan según el entorno docente.
Caso ficticio de aula. Lara necesita consultar sus solicitudes internas y Diego revisa las del equipo. La tabla contiene dos registros inventados: SOL-014, de Lara, y SOL-015, de otra persona. Lara debe poder leer únicamente el suyo; Diego puede leer ambos según el perfil de revisión acordado.
- Punto de partida
- La tabla se presenta igual para todos y las solicitudes no tienen una regla de lectura ligada al perfil. El recorrido todavía no cumple los criterios de acceso.
- Primera propuesta
- En el primer prototipo la lista de Lara solo muestra SOL-014, pero el enlace directo a SOL-015 sigue abriendo sus datos. El filtro visual no demuestra que el acceso al registro esté restringido.
- Qué revisamos
- El docente pide revisar las restricciones de datos y repetir la prueba del enlace directo con el perfil de Lara. El grupo contrasta después la vista de Diego y registra por separado qué acciones puede realizar cada perfil según el entorno.
- Resultado
- La prueba corregida permite a Lara consultar SOL-014 y bloquea la lectura de SOL-015. Diego puede revisar ambos registros. El grupo guarda la configuración y el resultado de las pruebas; el prototipo sigue siendo de aula y no se presenta como una app lista para operar.
Portal de solicitudes internas
Datos de aula
SOL-014 · Lara
Solicitud propia, pendiente de revisión.
SOL-015 · otra persona
Registro ajeno al solicitante.
Solicitante · Lara
SOL-014
Lectura permitida.
SOL-015 por enlace
Lectura bloqueada.
Revisor · Diego
Ambas solicitudes
Lectura acordada para revisar.
Acciones del prototipo
Comprobar reglas y plan antes de usarlas.
Esquema didáctico de un caso ficticio; no es una captura de Softr. Ocultar un bloque no sustituye la comprobación de las restricciones de datos.
Antes de darlo por terminado
- Lista y detalle muestran los campos del registro correcto.
- Lara no puede leer la solicitud ajena mediante su enlace directo.
- Diego conserva la lectura acordada y las acciones se comprueban según las reglas y el plan disponibles.
Sesiones para llevarlo a la práctica.
Edición de referencia · 12 h en directo
Edición de referencia: 12 horas en directo, repartidas en 6 sesiones de 2 horas. La definición, construcción y prueba del prototipo se realizan durante las sesiones. Los perfiles, permisos y funciones se confirman antes de empezar; cualquier preparación adicional se acuerda con el grupo.
- Sesión 12 h
Definir la necesidad y el alcance
Elegir una solicitud interna, identificar los dos perfiles y acordar qué recorrido mínimo merece prototiparse.
Al terminarUn alcance con tareas y criterios de aceptación, sin añadir funciones por defecto.
- Sesión 22 h
Preparar los datos de práctica
Crear los campos en Softr Databases y cargar registros ficticios coherentes con el caso.
Al terminarUna tabla de solicitudes con identificador, solicitante, contexto y estado.
- Sesión 32 h
Construir lista y detalle
Conectar bloques y campos, preparar la navegación y comprobar etiquetas y estados de la interfaz.
Al terminarUn recorrido que permite localizar una solicitud y comprender sus datos.
- Sesión 42 h
Definir accesos por perfil
Configurar grupos y restricciones de lectura, publicar sus cambios solo en el prototipo docente aislado y revisar las reglas disponibles antes de probar perfiles.
Al terminarUna tabla de permisos trasladada a la configuración disponible del prototipo.
- Sesión 52 h
Probar lo permitido y lo bloqueado
Contrastar el recorrido con ambos perfiles, incluidos enlaces directos a registros ajenos y acciones fuera de alcance.
Al terminarUna matriz de pruebas con diferencias identificadas y correcciones concretas.
- Sesión 62 h
Revisar y dejar instrucciones
Repetir los casos corregidos con feedback del docente y anotar cómo comprobar el prototipo y qué falta antes de usarlo.
Al terminarUn prototipo de aula revisado y unas instrucciones que otra persona puede seguir.
Si vuestro equipo necesita ir más allá
- Llevar el portal a producción, migrar datos reales, conectar un dominio y organizar su mantenimiento requiere un alcance separado.
- Automatizaciones, integraciones externas, pagos o permisos avanzados que excedan el entorno acordado no se añaden automáticamente a esta edición.
Aprender con alguien que diseña sistemas de trabajo.
Guillermo Mascaraque Piña
Consultor de sistemas de trabajo
Más de dos años de experiencia diseñando sistemas para empresas de todas las industrias y tamaños.
Guillermo es el docente previsto para este programa. Las fechas, el idioma y su disponibilidad se confirman al acordar la edición.
Con guía, práctica y acompañamiento.
Cada edición incluye materiales de trabajo, feedback sobre la práctica y evaluación según los objetivos acordados.
Materiales que podéis conservar
Guía, ejercicios y criterios de revisión descargables y versionados, para uso interno.
Para preparar y cerrar la edición
Recomendación breve, kit editable de comunicación e informe de aprendizaje del grupo.
Diploma propio de TOF
De aprovechamiento, al superar la evaluación acordada. No es una certificación del fabricante.
Un mes de soporte por correo
Sobre lo trabajado en clase, hasta dos horas acumuladas para todo el grupo.
La práctica la realiza tu equipo. Los servicios de implantación se acuerdan aparte. Ver el alcance →
Softr Partner
Somos Softr Partner. Nuestra experiencia en aplicaciones y portales aporta contexto para trabajar con datos, permisos y recorridos de usuario.
Una solución de TOF publicada por Softr ↗El partnership corresponde a The Optimal Flow. El diploma de Learn es propio de TOF y no es una certificación del fabricante.
