Como trabajo

Empiezo por mapear cómo funciona realmente el sistema: las personas, la información, las restricciones y los objetivos de producto o de negocio, no solo la interfaz. Entender la realidad operativa y el contexto de negocio desde el principio es lo que evita que el discovery se quede en la superficie.

A partir de ese mapa busco el punto específico donde se cruzan el dolor del usuario, la fricción operativa y las barreras a los objetivos de producto. No una lista general de problemas: nombrar el problema real con precisión es lo que evita que el resto del trabajo termine siendo decoración.

Construyo el caso con la evidencia disponible y relevante: entrevistas, observación de campo, flujos de trabajo, documentos y datos de producto como errores, tiempos o adopción. La investigación con usuarios convierte un debate de opiniones en una decisión basada en lo que realmente pasa.

Convierto lo aprendido en estructura: oportunidades priorizadas, hipótesis, arquitectura de información y user flows. Genero varias alternativas y las comparo por valor, esfuerzo y riesgo antes de comprometerme con una, para que el plan quede honesto sobre de qué depende.

No todos los problemas necesitan una interfaz nueva; a veces lo más fuerte es arreglar lo que hay debajo. Cuando sí corresponde diseñarla, paso de la estructura a la interacción y la interfaz: wireframes, prototipos y, si el proyecto lo justifica, componentes reutilizables. La accesibilidad y el responsive entran acá, no como chequeo al final.

Trato la primera versión como una hipótesis y la pruebo con usuarios y con el contexto real, no solo en revisión interna. Defino de antemano qué significaría que está mal y qué medir: éxito en la tarea, errores, tiempos, adopción o carga de soporte. Iterar contra ese objetivo es lo que hace que la siguiente versión sea mejor y no solo distinta.