01 — PRODUCTO DIGITAL · SAAS

NODUX

De gestionar catálogo, pedidos y tienda en partes separadas a conectarlos dentro de un mismo producto.

NODUX es un producto digital para gestionar parte de la operación comercial de un negocio y conectar esa gestión con su tienda online.

Tipo
SaaS · gestión comercial · e-commerce
Mi participación
Product Design
Foco
Producto · información · personas
Estado
Producto en evolución
02

Un producto que fue creciendo mientras también crecía lo que necesitaba resolver.

NODUX reúne funciones relacionadas con catálogo, ventas, inventario, pedidos y tienda online. A medida que el producto creció, también aumentaron las relaciones entre pantallas, reglas, información y decisiones que una persona necesita comprender para usarlo.

Durante sus primeras etapas, gran parte de esa lógica podía sostenerse porque quienes construíamos el producto también sabíamos cómo funcionaba. Pero esa dependencia empezó a convertirse en parte del problema.

MapaMapa general del producto
03

El producto tenía que empezar a explicar por sí mismo cómo usarlo.

El desafío dejó de ser solamente mejorar pantallas individuales. NODUX necesitaba convertirse en un sistema donde una persona pudiera entender qué configurar, qué información necesitaba, qué podía hacer en cada momento y cómo una acción afectaba otras partes del producto.

La pregunta pasó a ser: ¿Puede una persona entender NODUX, empezar a usarlo, conseguir lo que vino a conseguir y seguir utilizándolo sin depender de quienes lo construyeron?

Hacer que el conocimiento del producto deje de vivir únicamente en la cabeza de sus creadores.
04

Trabajé sobre el comportamiento del producto, no solo sobre sus pantallas.

Mi trabajo ha incluido definir y revisar recorridos, arquitectura de información, lógica, estados, interacción e interfaz, además de acompañar decisiones durante la implementación y volver sobre ellas a medida que el producto evoluciona.

También utilizo implementación asistida con IA como parte del proceso para construir, probar y revisar decisiones sobre el producto funcionando.

Áreas de trabajo

Product Design · Information Architecture · User Flows · Interaction Design · UI · Systems Thinking · AI-assisted implementation

05

Una decisión en una pantalla casi nunca termina en esa pantalla.

Para diseñar NODUX necesito entender cómo se relacionan distintas capas del producto: el negocio, su catálogo, la tienda online, los pedidos, la operación interna y la experiencia del cliente final.

Eso cambia la pregunta de ‘¿cómo debería verse esta pantalla?’ por preguntas como: ¿Qué información necesita existir antes? ¿Qué acción habilita esta decisión? ¿Quién necesita verla después? ¿Qué cambia en otra parte del producto?

NEGOCIO
CATÁLOGO
TIENDA ONLINE
CLIENTE
PEDIDO
OPERACIÓN
Esquema conceptual · no representa una arquitectura técnica exhaustiva
07

Un mismo producto, distintos momentos de uso.

Gestionar catálogo

Organizar la información que después alimentará otras partes del producto.

FlujoCarga y organización de catálogo

Configurar la tienda

Definir los datos y decisiones que hacen posible vender online.

FlujoConfiguración de tienda

Recibir y gestionar pedidos

Convertir una compra en información accionable para el negocio.

FlujoGestión de pedidos

Comprar y hacer seguimiento

Permitir que el cliente final complete la compra y entienda qué ocurre después.

FlujoCompra y seguimiento
08

NODUX existe, se usa y todavía está aprendiendo a funcionar con menos dependencia de nosotros.

El producto ya reúne distintas partes de la operación comercial y existen negocios utilizándolo. Al mismo tiempo, todavía hay aspectos —especialmente relacionados con configuración, activación y autonomía— que continúan evolucionando.

Por eso no considero el producto terminado. Parte del trabajo actual consiste precisamente en identificar qué conocimiento todavía depende del equipo y convertirlo en estructura, información y comportamiento dentro del propio producto.

¿Qué necesita saber el producto para poder orientar a una persona sin que nosotros estemos presentes?

Diseñar NODUX ha sido decidir cómo deben conectarse sus partes.

DECISIÓN 01

Permitir cargar el catálogo que el negocio ya tiene.

SituaciónUn comercio puede llegar a NODUX con información organizada de maneras muy distintas.

DecisiónEn lugar de obligar primero a comprender la estructura interna del sistema, el producto debe poder recibir la información existente y ayudar a estructurarla.

CriterioReducir la distancia entre la forma en que el negocio trabaja hoy y la forma en que NODUX necesita organizar esa información.

EstadoDirección de producto en desarrollo.

MóduloCarga de catálogo / IA
DECISIÓN 02

Conectar gestión y tienda online.

SituaciónLa tienda pública no puede funcionar como una pieza aislada del sistema de gestión.

DecisiónCatálogo, disponibilidad, información comercial, compra y pedidos necesitan compartir una lógica coherente.

CriterioLa experiencia del cliente final depende de decisiones que empiezan mucho antes del storefront.

RelaciónPanel / storefront
DECISIÓN 03

Hacer visible qué necesita configurar el negocio.

SituaciónParte de la activación histórica de las tiendas dependía de acompañamiento del equipo.

DecisiónTrabajar el producto para que pueda mostrar qué está listo, qué falta y qué decisiones necesita tomar el negocio.

CriterioConvertir conocimiento interno en orientación visible dentro del producto.

EstadoEn evolución.

ActivaciónActivación de tienda
DECISIÓN 04

Conectar pedido y seguimiento.

SituaciónLa compra no termina cuando el cliente confirma el pedido.

DecisiónDiseñar estados y seguimiento para que negocio y cliente puedan entender qué ocurrió y qué sigue.

CriterioEl estado de un pedido es información operativa para el negocio y, al mismo tiempo, información de experiencia para el cliente.

SeguimientoPedido / tracking

Dónde está hoy

Ya existe

  • gestión de partes de la operación comercial
  • storefront / tienda online
  • pedidos y seguimiento
  • configuración del producto

En evolución

  • activación más autónoma
  • orientación dentro del producto
  • reducción de dependencias del equipo

Siguiente pregunta

¿Qué necesita saber el producto para poder orientar a una persona sin que nosotros estemos presentes?

Lo que este producto me está enseñando.

  1. Una pantalla más clara no necesariamente hace más claro el producto si la lógica que conecta esa pantalla con el resto sigue siendo implícita.
  2. Diseñar autonomía también significa diseñar cómo el producto comunica lo que sabe y lo que necesita del usuario.
  3. Cuando un producto crece, arquitectura, información e interacción dejan de poder resolverse como decisiones separadas.