Skip to content
Diseño · 02.2

Las pantallas que nadie enseña en la presentación.

Un producto se juzga después de la primera demo: en el formulario con errores de validación, en la tabla con miles de filas, en el estado vacío del primer día. Diseñamos esas pantallas primero, porque deciden si sus usuarios encuentran valor en el producto.

Diseño
Estados del formulario
Default
ErrorRevise el email
EmptyAún no hay datos
Success✓ Guardado
01 / Qué es

Qué diseñamos.

01

Paneles y vistas generales

Elegir qué va en la primera pantalla y defender esa decisión frente a métricas que compiten por el espacio.

02

Flujos y procesos por pasos

Altas, solicitudes, pagos y aprobaciones, sobre todo qué pasa cuando alguien abandona a mitad y vuelve.

03

Formularios y entrada de datos

Orden de los campos, momento de la validación, redacción de los errores y comportamiento del teclado.

04

Tablas y vistas de datos

Filtros, ordenación, acciones masivas y densidad: una tabla de 12 filas no se diseña igual que una de 12.000.

02 / incluido

Qué incluye el trabajo de interfaz.

Todos los estados diseñados

Carga, vacío, parcial, error, sobrecarga y sin permisos, todos dibujados, no descritos.

Estados vacíos que enseñan

La primera pantalla vacía como superficie de bienvenida.

Los errores, redactados

Mensajes en lenguaje claro, con el siguiente paso sugerido, escritos durante el diseño.

Recorridos de teclado

Orden de tabulación, atajos y gestión del foco.

Decisiones de densidad

Cuánto cabe en pantalla, pensado para un uso de ocho horas diarias.

Comportamiento responsive

Cómo se comportan las tablas en el móvil, decidido en diseño.

03 / qué vigilar

Contra qué diseñamos.

Cinco hábitos que hacen que un producto luzca en la demo y funcione mal en el uso diario, y cómo los evitamos.

×Diseñar con datos de ejemplo limpios y entregarlo a usuarios con datos desordenados y voluminosos.
Diseñamos con nombres largos, campos vacíos y volúmenes reales.
×Pulir el caso ideal e improvisar los errores durante el desarrollo.
Diseñamos la versión de error de cada pantalla clave.
×Dar a todas las opciones el mismo peso, hasta que ninguna destaca.
Una jerarquía explícita, con una acción principal por vista.
×Añadir cada funcionalidad como una pestaña más, hasta que la navegación parece un listado de departamentos.
Revisamos la navegación completa a medida que crece el producto.
×Diseñar el onboarding al final, para un usuario imaginado y no observado.
Lo diseñamos primero, observando a usuarios reales.
04 / cómo funciona

Cómo funciona.

Así trabajamos normalmente. El presupuesto fija las fechas reales antes de empezar.

  1. Semana 1

    Encuadre

    Quién usa el producto, con qué frecuencia y qué intenta terminar. Entregables: mapa de flujos y lista de prioridades.

  2. Semanas 2–3

    Estructura

    Wireframes de baja fidelidad, navegación y jerarquía, probados con los casos más difíciles. Entregables: wireframes y decisiones estructurales.

  3. Semanas 4–5

    Interfaz

    Diseño visual aplicado a través del sistema, con todos los estados de cada pantalla clave. Entregables: diseños de pantalla y cobertura de estados.

  4. Semana 6

    Prototipo y entrega

    Un prototipo navegable de los flujos críticos, documentación y una sesión de traspaso con desarrollo. Entregables: prototipo y especificación de entrega.

05 / preguntas

Preguntas

No. Diseñamos las pantallas de riesgo y el sistema que mantiene el resto predecible, y revisamos las que construye su equipo.

Enséñenos qué está diseñando.

Descríbanos el proyecto en unas líneas. Le respondemos con un plan, un calendario y un presupuesto cerrado, en un día laborable.