Para Schneider Electric
Zeigo HUB es donde un supplier le reporta a la empresa a la que le vende cuánta energía usa y cuánto emite. Cada sitio, cada fuente de energía, cada mes, con la unidad correcta. Es el tipo de dato que toda empresa tiene en algún lado, casi siempre en una planilla, y el tipo que nadie quiere retipear en un producto que abrió hace cinco minutos.
AntesDespués
Nadie me pidió arreglar el onboarding. Estaba leyendo el funnel en Mixpanel y vi dónde se rompía: en los pasos de datos. Cerca de dos tercios de los suppliers que llegaban se iban sin terminar. Llevé el funnel al equipo y propuse el import.
El formulario ya tenía autosave y un link de Invite Collaborator. Eso te dice algo: la gente se iba a mitad de camino y se lo pasaba a otro. Solo Scope 3 son 15 categorías en dos años. Energy Consumption pide electricidad, vapor, calor y frío por año más cada región donde operás.
La hipótesis era simple: los suppliers ya tienen estos datos en una planilla. Si pueden darnos la planilla, la mayor parte de la caída desaparece. Descarté acortar el formulario, porque los campos son regulatorios; guardar progreso y recordar por mail, porque trata el síntoma; e integrar con el sistema contable de cada supplier, porque son miles y no hay un sistema común. La planilla era lo único que todos tenían.
La decisión que lo hizo funcionar fue diseñar una sola estructura de datos y hacer que tres cosas la hablaran: sitio, fuente de energía, período, cantidad, unidad. El template que descargan los suppliers tiene exactamente esas seis columnas. El parser en el navegador mapea el upload a esa forma. La tabla renderiza esa forma. El backend solo recibe la forma, ya confirmada.
El import nació en Zeigo Activate, donde los sitios ya reportaban energía por fuente y por mes. El PDF de instrucciones todavía lleva el logo de Activate. Cuando la survey de HUB mostró la misma caída, traje el patrón en vez de diseñar uno segundo.
Los archivos reales nunca están limpios. Los usuarios de US escribían 1,000.5; los europeos 1.000,5. Algunos dejaban unidades dentro de las celdas, otros mezclaban períodos. En vez de rechazar el archivo o normalizarlo en silencio, el upload cae en una tabla de revisión. Las celdas dudosas quedan teñidas y marcadas. Las vacías muestran un más. El encabezado cuenta lo pendiente, y Confirm and update queda deshabilitado hasta que ese contador llega a cero.
Clic en una celda marcada abre los valores parseados con dos botones: Reject Data o Save and confirm. Los datos se pueblan en la interfaz pero nada se envía hasta que cada ítem está confirmado. Un diseñador solo habría entregado un upload que falla y pide intentar de nuevo. Un ingeniero solo habría normalizado del lado del servidor y perdido la confianza del usuario en el momento en que una coma se convierte en un error de mil veces.
Construí la primera versión como un prototipo en código con Claude y Cursor, conectado al template real, en una semana. Lo suficientemente rápido para medir en vez de debatir. Lo pusimos frente a suppliers reales con Mixpanel para la finalización y grabaciones de Clarity para ver dónde dudaban. La primera versión confiaba en el archivo. Los usuarios lo rompieron en un día con comas, decimales, unidades y formatos regionales. De ahí salió la capa de revisión.
Abrí el PR. Los engineers de HUB lo adaptaron a sus convenciones y salió con cambios chicos.
35% →70%Suppliers que completan los pasos de datos
45 min →5 minTiempo de cargar una empresa
0 →40%Uploads con un problema de formato atrapado antes del backend
6 →1 uploadPasos a tipear a mano
La estructura sobrevivió a la feature. El mismo patrón template, upload, filas de revisión se reutilizó tal cual para Invite Collaborators: descargar un template, subirlo, filas con estado. Y cada componente de Zeus que HUB necesitó en el camino volvió al sistema.
Qué haría distinto: entregar la capa de validación en el primer prototipo. Los datos reales de usuarios nunca están limpios. Lo sabía y aun así probé primero el happy path.
“Working with X has been great. He is reliable and fast. The solutions he designs are creative and empathetic to the end-user experience!”
Exelobaiza | Design Engineer