LEAD

2022

Pecus Control

Conecta un collar de monitoreo animal con una plataforma de gestión, cuyo uso se disparó de la noche a la mañana con la pandemia. El objetivo: migrar una gestión ganadera dependiente de procesos manuales y desconectados hacia un ecosistema digital offline-first.

3

Sprint

6 Sem.

Duración

Mobile

Dispositivo

Metodología

Cómo decidí abordarlo

Híbrido entre Lean UX y validación cuantitativa, no un proceso de design thinking clásico de punta a punta. El producto ya estaba en producción no había espacio para descubrir desde cero. Cada decisión se apoyó en una prueba específica: benchmark y entrevistas para entender el contexto, card sorting y A/B testing para validar con números, heurístico y NPS para cerrar con evidencia y no con opiniones.

01 · Contexto

El problema

Pecus Control ya era un producto exitoso: collar de monitoreo animal + plataforma de gestión para administradores y veterinarios. La pandemia disparó su uso de la noche a la mañana y la arquitectura de información se rompió justo donde se concentraba el trabajo diario: vistas de animales, resúmenes de información y administración de usuarios en terreno.

02 · Decision Log

3 decisiones que definieron el resultado

El proceso no fue lineal. Fueron decisiones bajo restricción de tiempo, con un producto en producción y un equipo externo esperando handoff. Estas son las que más impactaron el resultado, con las pruebas que las respaldaron.

TRADEOFF
Sprint 1 · Investigación y análisis

Hi-fi sobre lo existente, no low-fi desde cero

Empezar wireframes desde cero (low-fi → mid-fi → hi-fi) o iterar directamente sobre el producto en producción.

Descarté

Proceso lineal completo. El producto ya existía y funcionaba parcialmente. Volver a low-fi habría consumido 2 sprints solo en redibujar lo que ya existía.

Elegí

Tratar el diseño actual como wireframe de alta fidelidad y refinarlo en iteraciones validadas con usuarios reales.

«Debido a las limitaciones de tiempo, no haremos wireframes de media o baja fidelidad, sino que tomaremos el diseño actual y lo utilizaremos como base para crear wireframes de alta fidelidad.»

Del case study original

PRUEBAS

Benchmark competitivo

3/3

Offline era requisito de mercado

Farmbrite, Mobble y Ranch Manager ya resolvían acceso offline. La oportunidad era integrar esa expectativa sin romper el producto actual.

Farmbrite
Mobble
Ranch Mgr.

Entrevistas

5 temas recurrentes en 9 participantes

User personas

2 perfiles para sostener decisiones

RESULTADO DEL SPRINT 1

El benchmark confirmó que offline no era un diferencial sino una expectativa de mercado. Las entrevistas revelaron que el problema real no era falta de funcionalidades sino fricción en las vistas más usadas: animales, resúmenes y administración en terreno. Con eso claro, el Sprint 2 arrancó directo con validación cuantitativa, sin iterar sobre supuestos.
MÉTODO
Sprint 2 · Pruebas de usuario y wireframe

Validación cuantitativa combinada

¿Cómo asegurar que el rediseño realmente mejoraba la experiencia, no solo que se veía mejor?

Descarté

Refinar solo con feedback cualitativo del product owner y del equipo externo. Hubiera sido rápido pero subjetivo.

Elegí

Closed card sorting (n=13) para validar la arquitectura nueva contra la vieja, seguido de A/B testing (n=24) con dos grupos y 5 métricas cuantitativas comparables.

PRUEBAS

Card sorting cerrado

90%

Arquitectura de información validada

Optimal Workshop · dendrogramas y matrices de clustering · 5 categorías testeadas con usuarios y stakeholders

Animales 100%
Collar 90%
Usuario 90%

A/B Testing

5/5

Versión nueva ganó en todas las métricas

Se evaluaron 2 grupos de 12 · 5 métricas cuantitativas medidas antes y después del rediseño

Tiempo −40%
Errores −10pp
Satisfacción +20pp

Wireframe de Media

RESULTADO DEL SPRINT 2

El card sorting confirmó que los usuarios navegaban la nueva arquitectura con naturalidad. El A/B testing lo midió: menos tiempo, menos errores, más intención de uso. Con un 88% de aprobación general, el Sprint 3 arrancó con una sola pregunta pendiente: ¿qué tan lejos llegamos?
WIN
Sprint 3 · Pruebas finales y entrega

Heurístico post-launch para definir backlog v3.1

¿Cerrar el ciclo con el A/B testing y entregar como «completo», o medir lo que queda por mejorar?

Descarté

Cerrar el proyecto con el A/B testing y entregarlo como producto terminado, sin diagnóstico final.

Elegí

Sumar una evaluación heurística de Nielsen sobre el producto en producción y una encuesta NPS para identificar huecos priorizables como backlog v3.1, con evidencia y no opiniones.

PRUEBAS

Encuesta NPS · post-launch

87%

Aceptación post-launch con evidencia cuantitativa

Escala 0–10 · 67% dio nota 9 o 10 · NPS clásico (promotores − detractores) = 60

Nota 9: 55%
Nota 10: 12%
Notas 8–10: 87%

Heurística Nielsen · 10 criterios

8/10

8 de 10 criterios en 4 o 5 sobre 5

Escala 1–5 · 2 criterios en 3/5 → identificados como backlog v3.1 prioritario

Consistencia 5/5
Estética 5/5
Errores 3/5

RESULTADO DEL SPRINT 3

8 de 10 heurísticas en 4 o 5 puntos. Los dos huecos, manejo de errores y ayuda contextual, quedaron documentados como backlog v3.1 con evidencia, no con opiniones. El producto llegó a producción a tiempo con un 87% de aceptación y un plan de mejora claro para la siguiente versión.

03 · Diseño final

Pantallas de la aplicación

Resultado del rediseño en producción. «Las vistas que se muestran son una selección representativa del trabajo entregado. El acceso completo al prototipo está sujeto a acuerdo de confidencialidad con AtlasCrop».

04 · La entrega

Lo que cambió y cómo lo entregamos

Pecus Control llegó a producción con una arquitectura validada por usuarios reales, no por suposiciones. El proceso pasó por benchmark, entrevistas, card sorting y A/B testing antes de tocar una sola pantalla de desarrollo. El resultado: menos tiempo de tarea, menos errores, más intención de uso. Los huecos que quedaron están documentados. Eso también es parte del trabajo.

−40%

tiempo de tarea promedio

A/B testing · 24 usuarios

5 min → 3 min

15% → 5%

tasa de error en tareas críticas

A/B testing · misma muestra

−10pp absoluto

87%

aceptación post-launch

Encuesta NPS · escala 0-10

67% dio nota 9 o 10

90%

clasificación correcta

Closed card sorting · n=13

Validación de arquitectura

05 · Reflexión

Qué haría distinto hoy

Dos cosas:

Validar offline-first con datos reales de red en zonas rurales, no solo con feedback cualitativo. Los entrevistados decían que la conectividad era problema, pero nunca medimos cuánto. Habría justificado priorizar el modo offline como feature crítica, no como recomendación de roadmap.

Sumar evaluación heurística desde el Sprint 1, no al final. Detectar temprano los huecos en ayuda contextual y manejo de errores (ambos en 3/5) habría permitido cerrarlos en este ciclo, no dejarlos para v3.1.