Sinaí Alfaro
UX/UI · Usabilidad & Accesibilidad
← Volver al trabajo

Caso 05 · UX/UI · App de Campo (iPad) · React Native

KDF Connect

Plataforma de campo para las cuadrillas de KDF — app iPad con ruta GPS, check-in por QR y firma digital semanal, más un dashboard administrativo. Bocetada antes de tocar React Native, para que dejar el papel se sintiera como menos esfuerzo, no más.

Cliente KDF (Servicios de Campo)
Rol UX/UI · Diseño de producto field-first · Sistema de diseño (Pattern Lab)
Año 2021
Duración 2021 (propuesta → producción, menos de un año)
Herramientas React Native (Expo), Pattern Lab, Wireframing en papel
Portada del caso KDF Connect

Route Tracker en producción — el mismo esqueleto panel + mapa del boceto.

Antes que nada

Cuadrillas en el campo, papel en la oficina. Cero registro de por dónde pasaron.

KDF operaba cuadrillas de campo en varios sitios. El check-in y el check-out de cada empleado eran verbales. Las horas vivían en timesheets de papel. Y la ruta que una cuadrilla recorrió en un turno —por dónde pasó, qué fotografió, si el trabajo se completó— quedaba en lo que el supervisor recordara mencionar al volver a la oficina.

La restricción no era de presupuesto de features: era de contexto de uso. Cualquier pantalla tenía que funcionar en un iPad, al sol, con guantes puestos, y con una sola mano libre porque la otra sostenía algo más. Mi parte fue diseñar esas pantallas antes de que existiera una sola línea de React Native — este caso es sobre dos de ellas: el mapa que un supervisor revisa a media jornada, y la firma que cierra la semana.

El problema real

No era un problema de features. Era un problema de manos ocupadas.

El papel nunca exige nada de la atención de alguien — se firma y se archiva. Una pantalla sí. Si el diseño pedía dos manos, texto fino o una secuencia de taps cuidadosa, la cuadrilla iba a volver al papel en la primera semana. El reto de diseño real era que cambiar de papel a tablet se sintiera como menos esfuerzo, no más.

Antes de abrir una herramienta de diseño, bocetié cada pantalla en papel — la misma disciplina que uso en tableros de datos, aplicada acá a una interfaz táctil de campo. Abajo están las dos que más deliberadamente diseñé: el mapa de seguimiento de ruta, y el cierre semanal con firma.

Lo que decidí, y por qué

La pantalla que un supervisor revisa en movimiento.

01
Decisión 01 · Zonificación

El mapa ocupa dos tercios de la pantalla. El panel es apoyo, no protagonista.

Un supervisor abre esta pantalla con una sola pregunta —¿dónde está mi cuadrilla ahora mismo?— y esa pregunta la responde el mapa, no una lista de datos. El panel de información queda angosto, ordenado de lo que cambia menos (la cuadrilla asignada) a lo que cambia todo el tiempo (las acciones). Ningún control del mapa —cerrar, centrar, hacer zoom— comparte chrome con el panel: cada mitad se lee sola.

Boceto de zonificación del Route Tracker: panel de información vs. mapa
02
Decisión 02 · Ubicación de acciones

Tres lugares para tres botones. Gana el que no obliga a cambiar de agarre.

Probé una barra superior (deja el mapa despejado, pero es un estiramiento con una tablet apoyada), un ”+” flotante que se abre en tres opciones (libera espacio, pero le cobra un tap extra a las dos acciones que se usan todo el turno), y una fila fija abajo del panel. Gana la fila fija: el pulgar de un supervisor ya está ahí, revisando la cuadrilla — no hay que reposicionar la mano para tomar una foto o agregar un comentario.

Tres ubicaciones exploradas para los botones de acción del Route Tracker
Wireframe final anotado del Route Tracker, calcado de la pantalla real
El wireframe calcado sobre el layout que se entregó — diez decisiones defendidas, desde el color de los tres puntos de GPS hasta por qué 'Finalizar ruta' es el único botón con color cálido. Click para ampliar.

Una ruta en papel era lo que el supervisor recordaba contar. Esta se dibuja sola, y no le pide a nadie que recuerde nada.

Un cambio de riesgo

De la firma en papel a un registro que nadie edita en silencio.

Si el Route Tracker resuelve “¿dónde estuvo la cuadrilla?”, el cierre semanal resuelve algo con más peso: el momento exacto en que 44 nombres, horas regulares, extras y dobles quedan aprobados y no se pueden tocar de nuevo. Eso pedía dos superficies distintas —revisar no es lo mismo que comprometerse— y una decisión incómoda: ¿qué pasa si alguien no firmó?

03
Decisión 03 · Dos superficies

Revisar y comprometerse son dos pantallas, no un formulario largo.

La lista es plana y se puede recorrer sin consecuencias. El modal de cierre rompe esa sensación a propósito — una tarjeta elevada sobre un fondo oscurecido, con los tres números que un supervisor tiene que leer (empleados, horas totales, horas extra) antes de que la firma aparezca en pantalla. Nadie firma a ciegas.

Boceto de zonificación del flujo de cierre semanal: lista vs. modal
04
Decisión 04 · El empleado sin firmar

Una semana real siempre tiene un rezagado. Tres formas de manejarlo.

Bloquear el envío hasta el 100% firmado suena responsable, pero deja el pago de toda la cuadrilla rehén de un solo timesheet atrasado. Enviar en silencio y marcar el hueco después en el dashboard admin es peor: le quita la decisión a la única persona que estuvo ahí esa semana. Gana la advertencia suave — “¿Continuar con empleados sin firmar?” — porque deja la decisión exactamente donde tiene que estar: con el supervisor, en el momento en que de todas formas la va a notar.

Tres formas de manejar empleados sin firmar en el cierre semanal
Wireframe final anotado del flujo de cierre semanal, lista y modal
La lista oscurecida detrás de la tarjeta no es decoración — es la señal de que dejaste de navegar y empezaste a comprometerte. Click para ampliar.

Lo que se sostuvo

Dos pantallas, un mismo lenguaje.

El Route Tracker y el cierre semanal comparten ADN aunque resuelven problemas distintos: la misma barra de iconos a la izquierda, la misma jerarquía de “lo fijo arriba, la acción en la zona del pulgar”, el mismo criterio de que un color cálido se reserva para la única acción que no se puede deshacer. Ese lenguaje visual se formalizó después en una librería Pattern Lab compartida entre la app de campo y el dashboard admin, para que ningún equipo tuviera que decidir dos veces cómo se ve un botón.

La ingeniería tuvo su propia versión de esta misma disciplina: las coordenadas GPS, fotos y comentarios se guardan localmente cuando no hay señal y se sincronizan en orden al reconectar, para que lo que el supervisor ve en pantalla —el trazo, los marcadores— nunca dependa de que el sitio tenga cobertura.

En producción

Cómo quedó, en la app y en el dashboard admin.

Route Tracker en producción, iPad
Route Tracker en producción — mismo esqueleto que el Sketch 03: panel a la izquierda, mapa protagonista.
Dashboard administrativo de KDF Connect
Dashboard admin — la misma librería de componentes que la app de campo.
Vista de timesheets en el dashboard admin
Timesheets con desglose de horas regulares, extra y doble tiempo por empleado.

Cómo se notó

De un timesheet de papel a un sistema que una cuadrilla usa todos los días, con guantes puestos.

2
Pantallas rediseñadas de cero a partir de boceto en papel — Route Tracker y Cierre Semanal — sobre un sistema de cuatro componentes en producción.
10+10
Decisiones de diseño registradas y defendidas por pantalla, desde el tamaño de los botones hasta qué color se reserva para la única acción irreversible.
0
Cambios de layout necesarios entre el boceto y lo que construyó ingeniería — el esqueleto panel + mapa se sostuvo intacto hasta producción.

Si esto te suena

¿Tu equipo de campo todavía reporta el día por papel o WhatsApp?

Contame cómo trabaja tu gente hoy. Estas apps no suelen fallar por falta de funciones — fallan porque nadie diseñó pensando en guantes, sol directo y una sola mano libre.

Hablemos
Siguiente caso CoolBrand