PROCESO

1. OBJETIVO

2. ALCANCE

Ofrecer un marco de referencia para el diseño y rediseño de productos de datos técnicos (PDT), orientado a asegurar que generen valor real para los usuarios.

El proceso busca:

Comprender las necesidades reales de los usuarios
Diseñar soluciones útiles, usables y accesibles
Validar hipótesis de manera temprana mediante contacto con usuarios
Guiar la toma de decisiones basada en evidencia y aprendizaje continuo

El foco no está en construir productos, sino en aprender qué producto vale la pena construir.

Este marco guía decisiones que impactan en la experiencia del usuario y en la generación de valor, priorizando la validación temprana y el aprendizaje continuo.

Este proceso aplica al diseño y rediseño de productos de datos técnicos, desde la identificación de oportunidades hasta su uso y evolución en contexto real.

Incluye:

Definición de propuesta de valor y usuarios objetivo
Diseño de la experiencia (User Journey, criterios UX/UI)
Desarrollo y validación de MVPs
Evaluación de uso, adopción y valor generado
Iteración continua en base a evidencia

No establece una secuencia rígida de pasos ni el uso obligatorio de herramientas específicas.

Debe adaptarse según:

Nivel de incertidumbre
Madurez del producto
Contexto de uso

3. DEFINICIONES

4. RESPONSABLE DE PROCESO

ANALISTA GPT DE UX: Permite identificar problemas de usabilidad, claridad y experiencia, y obtener un score UX orientativo junto con recomendaciones de mejora. El objetivo no es alcanzar un puntaje determinado, sino detectar fricciones y oportunidades de mejora de forma temprana.

PDT: Productos de datos técnicos

MODELO DE NEGOCIOS: El Modelo de Negocios resume la forma en la que se va a crear valor, se va a entregar a los clientes y va a generar ingresos (capturar valor) para alcanzar su sostenibilidad.

MVP:El producto inicial mínimo viable debe ser:

Lo más simple posible
sirve para validar ideas con bajo costo/tiempo
Permite aprender directamente de usuarios reales

No se busca calidad perfecta, sino máximo aprendizaje con mínimo esfuerzo.

Líder de desarrollo del Producto de Datos Técnicos

5. DESARROLLO:

5.1 Espíritu del proceso

El proceso funciona como una guía para orientar criterios y decisiones, no como una receta. Su valor está en ayudar a identificar qué profundizar, qué simplificar y qué revisar en cada etapa.

Este enfoque implica:

Trabajar con incertidumbre, ajustando según la evolución del producto
Poner el foco en las decisiones que el producto busca mejorar, más que en sus funcionalidades
Integrar de manera continua la mirada técnica, de negocio y de experiencia de usuario
Evaluar el producto en situaciones reales de uso, no solo en condiciones ideales

5.2 Enfoque lean para el desarrollo de PDTs

🔁 1. Ciclo clave: construir → medir → aprender

El desarrollo se organiza como un loop continuo:

Construir: crear una versión del producto
Medir: obtener datos reales de uso
Aprender: validar o refutar hipótesis. El objetivo no es lanzar features, sino generar aprendizaje validado.

🧪 2. Todo producto es un conjunto de hipótesis

Cada decisión de producto (features, usuarios, valor) es en realidad una suposición que hay que testear. El enfoque Lean propone:

Hacer explícitas esas hipótesis
Diseñar experimentos para validarlas
Evitar avanzar basado en opiniones o intuición sola

Esto permite “poner a prueba científicamente” las ideas antes de invertir fuerte .

🚀 3. MVP (Producto Mínimo Viable)

El producto inicial debe ser:

Lo más simple posible
Lo suficientemente funcional para obtener feedback real
No se busca calidad perfecta, sino máximo aprendizaje con mínimo esfuerzo

👤 4. El usuario está en el centro del desarrollo

El aprendizaje no viene del equipo, sino del usuario; por eso se lo incorpora temprano.
Se mide su comportamiento (no solo su opinión)
Se itera en base a uso real

🔄 5. Iterar o pivotar

Después de cada ciclo hay dos caminos:

Perseverar: seguir en la misma dirección (si la hipótesis se valida)
Pivotar: cambiar de rumbo (si no funciona)

⚙️ 6. Evitar el desperdicio

Muchas veces se construyen productos que nadie quiere o necesita usar; el enfoque lean busca eliminar ese desperdicio mediante:

Validación temprana
Iteraciones rápidas
Decisiones basadas en datos

🧩 7. Desarrollo de producto ≠ solo construir: El desarrollo incluye entender cliente y mercado

5.3 Proceso propuesto

Este proceso debe entenderse como iterativo. Las actividades de desarrollo, medición y aprendizaje se repiten en ciclos continuos a lo largo del tiempo, y no como una secuencia lineal de etapas cerradas.

A- DEFINICIONES DE PRODUCTO

ACTIVIDAD	RESPONSABLE	DETALLE	REGISTRO
INICIO
Definir propuesta de valor del PDT	Líder del PDT	Especifique: qué decisión mejora qué riesgo reduce qué tiempo ahorra. cómo el PDT facilita el aprendizaje colectivo y la comparabilidad entre grupos. El desarrollo de producto no es un proceso de “construir bien”, sino de aprender qué producto vale la pena construir.	canvas
Definir segmento de usuario objetivo	Líder del PDT + Área Técnica	Identifique el segmento al que estará dirigido el PDT, por ejemplo: productor ganadero, agrícola, mixto, asesor técnico, coordinador regional. Describa además el nivel de madurez digital, frecuencia de uso de datos, contexto de decisión y principales frustraciones. Considere la situación en la que se uso / hará carga de datos (ejemplo, en recorridas a campo, en lugares sin acceso a internet). Los problemas surgidos durante estos procesos deben ser parte de la solución.	canvas
Diseñar user Journey	Comunicación + UX	Mapee las etapas desde descubrimiento hasta uso en reunión de grupo, identificando fricciones y oportunidades. Ver ejemplo: USER JOURNEY En esta etapa, considere que el aprendizaje no viene del equipo de trabajo, sino del usuario y que por eso: Se lo incorpora temprano Se mide su comportamiento (no solo su opinión) Se deberá iterar en base al uso real.	Mapa de User Journey
Consolidar el modelo de negocio	Líder del PDT + Administración	Genere el Lienzo CANVAS, visibilizando los siguientes elementos clave: Propuesta de valor: ¿Qué problema resuelve? ¿Qué necesidad satisface? Segmentos de clientes: ¿A quién está dirigido? Canales: ¿Cómo se llega al cliente? Relación con clientes: ¿Cómo se vincula con el cliente y lo fideliza? Fuentes de ingresos: ¿Cómo se gana dinero? Recursos clave: ¿Qué se necesita para funcionar? Actividades clave: ¿Qué se debe hacer bien? Socios clave: ¿En quiénes se debe apoyar para entregar la propuesta de valor? Estructura de costos: ¿En qué se gasta el dinero? Ver: Brief modelo PDT.pptx	Lienzo CANVAS aprobado

B- DESARROLLO DEL PRODUCTO

ACTIVIDAD	RESPONSABLE	DETALLE	REGISTRO
Analizar alternativas existentes	Equipo Técnico	Revise soluciones similares tanto internas como de mercado. Registre y considere para el diseño sus aciertos.	n/a
Desarrollar Producto Mínimo Viable	Tecnología + Área Técnica	Construya una versión simple que permita validar uso y comprensión. Aplique en el diseño los principios de UX: claridad, visualización simple, lenguaje accesible, foco en insights accionables. Ver anexo I Realice pruebas piloto con grupos CREA y recoja feedback estructurado. Observar tareas reales sin intervenir. Iterar rápidamente. Ajuste según problemas detectados (diseño iterativo obligatorio).	Versión MVP funcional
Evaluar e iterar	Tecnología + Área Técnica	A nivel diseño: El PDT debe ser evaluado utilizando el ANALISTA GPT DE UX como herramienta de diagnóstico. Con las sugerencias, itere el modelo: Priorice la resolución de problemas críticos Itere el diseño en base a las recomendaciones Vuelva a evaluar hasta alcanzar un nivel adecuado de usabilidad y claridad 🎯 ¿Cómo interpretar el score del informe? 90–100 → Excelente (raro) Producto muy pulido, casi sin fricción Microdetalles cuidados 80–89 → Muy bueno (objetivo ideal) Claro, usable, eficiente Puede tener detalles menores No frena decisiones 70–79 → Aceptable Funciona, pero requiere esfuerzo cognitivo. No es inmediato Hay margen claro de mejora 60–69 → Deficiente Confunde, genera dudas o errores No escala bien <60 → Problemático Bloquea al usuario directamente El score es una herramienta de diagnóstico, no un objetivo en sí mismo. A nivel experiencia de uso: Evalúe el PDT a partir de pruebas con usuarios, testeo del MVP y análisis del User Journey, observando cómo las personas interactúan realmente con el producto. Identifique fricciones, dudas, errores, desvíos en la navegación y puntos de abandono, así como oportunidades de mejora en comprensión, acceso y toma de decisión. Con base en estos hallazgos, priorice ajustes e itere el producto hasta optimizar su facilidad de uso, fluidez y capacidad de generar valor en la práctica.	GPT
Diseñar plan de comunicación del PDT	Comunicación	Defina el lanzamiento, casos de uso, tutoriales, piezas explicativas. Solicitud de Plan de Comunicación para Eventos Regionales y de Área	Plan de comunicación aprobado

C - LANZAMIENTO

ACTIVIDAD	RESPONSABLE	DETALLE	REGISTRO
Implementar lanzamiento	Comunicación + Área Técnica	Ejecute las acciones de difusión y acompañamiento.	Reporte de lanzamiento
Medir métricas de uso inicial	Tecnología + Datos	Mida: Frecuencia Tasa de carga Uso en reuniones	Dashboard
Evaluación periódica de adopción	Equipo Técnico + Tecnología	Después de cada ciclo hay dos caminos: Perseverar: seguir en la misma dirección (si las hipótesis iniciales se validan) Pivotar: cambiar de rumbo (si lo que planteamos no funciona). Para esto: Revise el nivel de adopción, comprensión y uso efectivo en decisiones. Itere funcionalidades, simplifique o elimine lo que no agrega valor. Un PDT solo se considera exitoso si: Es útil (resuelve necesidad real). Es usable (aprendizaje, eficiencia, memorabilidad, errores, satisfacción). Mejora la toma de decisiones. Aumenta la probabilidad de que el conocimiento sea compartido. Si el usuario necesita capacitación extensa para usarlo, el diseño debe revisarse. Si no se usa en la reunión de grupo, el valor no está siendo capturado. Analice y considere las limitaciones técnicas ante el crecimiento del uso. Elimine o rediseñe aquellos módulos de bajo uso o bajo valor percibido	Registro de mejoras

ANEXO I - PRINCIPIOS DEL UX - https://lawsofux.com/

ACTIVIDAD	RESPONSABLE	DETALLE (criterios aplicados)
Definir principios UX obligatorios	Comunicación + Dirección Técnica	Simplicidad (Navaja de Occam), consistencia (Ley de Jakob), foco en insight clave (Pareto 80/20), reducción de carga cognitiva.
Diseñar arquitectura de información	UX + Tecnología	Agrupar por proximidad, semejanza y región común. Evitar fragmentación innecesaria.
Definir reglas de visualización	UX + Área Técnica	Destacar diferencias relevantes (Von Restorff). Evitar exceso de métricas.
Diseñar interacción eficiente	Tecnología	Minimizar tiempos de respuesta (<400 ms – Umbral de Doherty). Optimizar tamaño y distancia de elementos (Ley de Fitts).
Minimizar complejidad expuesta	Tecnología + Área Técnica	Aplicar Ley de Tesler: absorber complejidad estructural en el sistema.
Diseñar onboarding contextual	Comunicación	Considerar paradoja del usuario activo (no leen manuales). Incluir ayuda contextual y tooltips.
Definir criterios de error y recuperación	Tecnología	Permitir recuperación simple (Ley de Postel). Reducir errores graves.
Evaluar satisfacción y memorabilidad	Comunicación	Medir facilidad de reaprendizaje y experiencia emocional.

6. EVOLUTIVOS:

VERSIÓN	FECHA	APROBADO POR
1	17/04/2026	Líder de Operaciones y Procesos (como sponsor del OKR)