Resultado de Aprendizaje (RAP)
Guía 3 — Prototipado Estático, Interfaz de Usuario (UI) y Validación Continua
El prototipo es una hipótesis visible que se prueba y se mejora con evidencia.Comenzar la práctica ↓
¿Cómo se conectan las 4 guías de la fase de Análisis y Planeación?
Se caracteriza el proceso y se recolecta información autorizada con dos instrumentos distintos.
Los hallazgos se convierten en contexto, historias, requisitos y ejemplos verificables.
Una historia toma forma en un flujo y se observa a una persona intentando una tarea.
La evidencia ajustada se ordena en un objetivo y un plan de trabajo realista.
Primero aprende el lenguaje; luego construye, prueba y decide.
Representación parcial de una solución para aprender antes de invertir más. Puede ser papel, imagen o pantalla navegable; no es el producto terminado.
Ejemplo: cuatro pantallas enlazadas para ensayar el registro de un equipo.Boceto de baja fidelidad que muestra estructura, contenido y orden sin concentrarse en colores o acabado.
Ejemplo: rectángulos para campo Serial, mensaje y botón Registrar.Representación visual más detallada de una pantalla. Muestra tipografía, color y apariencia, pero puede no responder a clics.
Ejemplo: diseño final de la confirmación de ingreso.Controles, textos y estados mediante los cuales una persona opera el sistema.
Ejemplo: etiqueta, campo, ayuda, botón y mensaje de resultado.Percepción completa antes, durante y después de lograr una tarea; no es solo que la pantalla se vea bonita.
Ejemplo: entender qué hacer, evitar errores y recuperar el control.Qué tan eficaz, eficiente y satisfactoria resulta una tarea para personas y contexto definidos.
Ejemplo: un guarda registra correctamente sin ayuda y comprende el resultado.Condiciones para que personas con distintas capacidades puedan percibir, comprender y operar la interfaz.
Ejemplo: etiqueta programática, foco visible y error explicado con texto, no solo color.Situación visible de la pantalla antes, durante o después de una acción.
Ejemplo: inicial, procesando, vacío, éxito, error y sin permiso.Secuencia de acciones, decisiones y estados que lleva a un objetivo; incluye alternativas y recuperación.
Ejemplo: buscar → no encontrado → registrar → confirmar.Contraste con necesidades y personas: comprueba si se está resolviendo el problema correcto. No equivale a una firma automática.
Ejemplo: observar una tarea, registrar hallazgos y acordar cambios.El simulador comprueba presencia y cantidad de componentes del ejercicio. No prueba usabilidad ni aprueba el proyecto.
Una persona representativa ejecuta una tarea; tú observas, registras y ajustas el prototipo.
El instructor aplica los criterios SENA al PDF, la trazabilidad, la sesión y las decisiones justificadas.
E-01 → H-01 → CTX-01 → HU-01 → RF/RNF-01 → CA-01 → PR-01 → UI-01 → VAL-01 → BL-01Cada artefacto tiene propósito, entradas, instrucciones, ejemplo, criterio, instrumento y transferencia. Completa la ruta con tu propia HU.
Trae desde Guía 2 una Historia de Usuario priorizada, RF/RNF, criterios BDD, pruebas, datos, estados, riesgos y una tarea con DoR. Si alguno falta, regístralo como pregunta abierta; no inventes la solución.
Para qué sirve: identificar proyecto, ficha, aprendices, centro, instructor y fecha.
Completa: programa, proyecto, ficha, integrantes, centro, instructor, fecha y código de evidencia por confirmar.
Se verifica: la autoría y la identificación son inequívocas. Entrega: primera página del dossier.
Para qué sirve: demostrar de dónde sale cada pantalla, estado y acción. Así evitas inventar requerimientos de la nada.
Incluye: Identificador de origen (E/H/CTX), la historia (HU), los requisitos (RF/RNF), criterios (CA/BDD), datos, estados y riesgos asociados.
Se verifica: cada elemento tiene fuente trazable o es una pregunta abierta (DoR). Entrega: tabla de origen.
Para qué sirve: mostrar acciones, decisiones, éxito, vacío, error, permisos y recuperación.
Ejemplo: Inicial → diligenciar → error de serial → corregir → procesando → éxito.
Se verifica: otra persona puede explicar cómo llegar al objetivo y recuperarse.
Para qué sirve: hacer visible la hipótesis antes de construir.
Incluye: solo vistas necesarias para recorrer la HU y sus alternativas, con datos ficticios.
Se verifica: el flujo puede recorrerse sin pantallas decorativas ni estados ocultos.
Para qué sirve: justificar cada componente y estado con HU, RF/RNF, criterio y prueba.
Ejemplo: Campo Serial + Buscar → HU-01 → RF-02 → CA-01 → prueba de búsqueda.
Se verifica: no quedan elementos relevantes sin razón o comprobación.
Para qué sirve: observar una tarea con una persona representativa en un contexto acordado.
Incluye: fecha, perfil, contexto, tarea neutral, consentimiento, tiempo, errores, frases, observaciones y limitaciones.
Se verifica: se prueba el prototipo, no a la persona; los datos están protegidos.
Para qué sirve: convertir observaciones en ajustes o preguntas pendientes.
Separar: hecho observado, interpretación, decisión, requisito afectado, prioridad, responsable y estado.
Se verifica: cada hallazgo termina en aceptar, modificar, rechazar o devolver a Guía 2.
Para qué sirve: evidenciar cómo la validación cambió la hipótesis.
Ejemplo: v0 usaba solo color para el error; v1 agrega texto, foco visible y orientación de recuperación.
Se verifica: existe evidencia antes/después, accesibilidad revisada y riesgos residuales.
Para qué sirve: permitir que Guía 4 planee sin inventar comportamiento.
Incluye: HU y criterios ajustados, UI v1, VAL-01, matriz, riesgos, dependencias, pruebas, DoR y responsables.
Se verifica: los pendientes bloqueantes permanecen visibles.
Para qué sirve: declarar propuestas de IA, verificación, riesgos y decisión humana.
Incluye: propósito, datos protegidos, variante, verificación, sesgos, decisión, responsable y fecha.
Se verifica: la IA no aparece como autora ni como evidencia de validación.
Entender el prototipo a través de la arquitectura civil
Los planos y modelos permiten conversar sobre uso, espacio y restricciones antes de ejecutar decisiones costosas.
La estructura y las instalaciones se coordinan con los planos y pueden obligar a revisarlos. El diseño no es una promesa inmutable.
El equipo convierte requisitos en un prototipo y una interfaz de usuario para observar tareas, preguntas y errores antes o durante pequeños cortes de construcción.
Backend, datos e interfaz evolucionan en cortes coherentes. La evidencia reduce retrabajo, pero no reemplaza pruebas técnicas ni decisiones de arquitectura.
Conclusión clave: el prototipo es una hipótesis barata para conversar y aprender. La validación aporta evidencia sobre el flujo, mientras la arquitectura, los datos y el software se construyen y comprueban en incrementos trazables. No es una firma, una aprobación automática ni una prueba de que el sistema funciona.
Cada elemento relevante de la pantalla debe señalar la historia, el requisito o el criterio que lo justifica. El prototipo permite contrastarlos; no los aprueba por sí solo.
Caja de texto numérica con validación visual y botón destacado para consulta rápida.
Columnas para Serial, Marca, Propietario, Fecha/Hora de Ingreso y Badge de Estado (En Sitio / Salida).
Modal flotante para pedir confirmación al instructor cuando no hay cita previa en sistema.
Usa la especificación de la Guía 2 como entrada, prueba la interfaz con personas y entrega decisiones verificables a la Guía 4.
Convierte una historia de usuario (Guía 2) en una secuencia visual. No diseñes solo el estado "feliz", debes considerar todos los escenarios.
(Viene de Guía 2: "Como guarda, quiero registrar un equipo para llevar control de ingreso")
Decisión clave: Cada pantalla, estado y acción relevante debe conservar un vínculo con HU, RF/RNF, criterio, prueba o pregunta explícita de la Guía 2.
Usa los "dolores del usuario" descubiertos en las entrevistas de la Guía 1 para probar tu diseño. Pide al usuario que ejecute una tarea y observa.
(El guarda mencionó: "Pierdo mucho tiempo buscando si un serial ya está registrado")
| Tarea Solicitada | Comportamiento Observado | Decisión (UI) |
|---|---|---|
| "Busca este equipo antes de registrarlo" | No encontró la barra de búsqueda rápida | Mover la barra al header global |
| "Registra el serial X-123" | Digitó mal y no notó el error | Añadir texto grande y validación en vivo |
Decisión clave: Un hallazgo produce un ajuste en el prototipo, una pregunta pendiente o una razón documentada para no cambiar.
Relaciona cada elemento de interfaz con la función (RF) y la calidad (RNF) definidas en la Guía 2.
| Elemento Visual (UI) | Requisito (Guía 2) | Regla / Prueba |
|---|---|---|
| Caja "Serial" + Botón Buscar | RF-02: Consulta de equipo | RNF-01: Respuesta en ≤ 2 segundos. |
| Mensaje de error rojo brillante | RF-03: Validación de entrada | Accesibilidad: Contraste WCAG y texto claro. |
| Modal de confirmación | RF-01: Autorización explícita | Seguridad: No permitir envío doble. |
Decisión clave: Si un botón o texto en el prototipo no tiene requisito o criterio en la Guía 2, se elimina o se devuelve a análisis.
Puedes pedir a una IA ideas de microtexto, estados, rutas alternativas o controles de accesibilidad. La respuesta es una propuesta, no evidencia de usabilidad. Tu aporte humano es observar la tarea real, reconocer emociones y contexto, proteger la privacidad, evitar patrones manipulativos y decidir qué cambio aporta valor.
BITÁCORA HUMANO–IA · G3
Uso: [no utilizada / utilizada]
Pantalla, flujo o texto apoyado:
Propósito, prompt y datos protegidos:
Variante producida:
Cómo se verificó: [trazabilidad / accesibilidad / sesión]
Riesgos o sesgos detectados:
Decisión humana: [aceptar / modificar / rechazar]
Justificación, responsable y fecha:Laboratorio de cobertura estructural y constructor de UI
Arrastra componentes HTML aquí
para construir tu wireframe
Los elementos se organizarán automáticamente con CSS Grid/Flexbox
Ponte a prueba sobre Prototipado, Fidelidad y Validación
Registra la cobertura del laboratorio; la validación real se documenta con el instrumento VAL
Verifica que tu canvas contiene los componentes estructurales solicitados para la Historia de Usuario activa. Esta revisión automática no observa a una persona ni ejecuta el software.
Completa las comprobaciones estructurales del ejercicio para habilitar el resumen.
Formación SENA por Proyectos
El diseño de interfaz (UI/UX) materializa la interacción de las personas con el sistema. Aplicando la metodología de Formación por Proyectos del SENA, este recorrido web (principios de usabilidad, maquetación de prototipos, trazabilidad de requisitos y registro de validación) constituye una evidencia de trabajo para tu Proyecto Formativo; no reemplaza la evaluación del instructor.
Consolida un dossier de prototipado UI/UX en PDF. Trabaja una Historia de Usuario priorizada y un flujo completo; la cantidad de vistas depende de sus estados, no de pantallas genéricas.
E → H → CTX → HU → RF/RNF → CA/PR → UI → VAL → BL se puede seguir, la v1 muestra las decisiones y las preguntas pendientes tienen responsable.
Sube tu dossier PDF al LMS institucional indicado por tu instructor, en la actividad correspondiente a:
Referencia de nomenclatura didáctica — confirma el código y título oficiales antes de entregar
Nomenclatura de ejemplo (no oficial; confirma el código con tu instructor): CODIGO_EVIDENCIA_PrimerNombre_PrimerApellido.pdf