Diseñar una lectura, no un dashboard

Una workstation de trading concentra muchas señales en muy poco espacio. El precio se mueve, el volumen se distribuye, la liquidez aparece o desaparece y las operaciones se ejecutan de forma continua. Presentar cada dato en su propio panel es relativamente sencillo. El problema de producto empieza cuando todos deben ayudar a interpretar el mismo instante sin competir entre sí.

Apex Trader nace como una exploración personal de producto y frontend para estudiar esa coordinación. El objetivo no era reproducir una plataforma comercial completa, sino construir una interfaz suficientemente profunda para tomar decisiones reales de jerarquía, interacción, visualización y arquitectura.

La pregunta central no era cómo mostrar más información, sino cómo permitir que distintas representaciones del mercado se lean como una sola sesión.

El resultado es una demo funcional con tres modos de gráfico, replay histórico, profundidad de mercado, Time & Sales, Volume Profile y un heatmap de liquidez. La landing extrae esas piezas y las presenta de forma aislada; la demo las vuelve a reunir dentro de la workstation.

Entender el dominio antes de diseñar

El proceso partió de una experiencia de dominio acumulada. El trading es uno de mis intereses personales y le he dedicado tiempo a comprender sus herramientas, dinámicas y modelos de lectura. A ese recorrido se suma mi etapa en Bit2Me como Product Designer de Bit2Me Pro, la plataforma de trading de la compañía. Ese contexto profesional aportó una base real desde la que analizar la relación entre datos, decisiones e interfaz.

Para Apex Trader realicé además research de dominio y una auditoría de patrones presentes en herramientas profesionales. No hubo una investigación de usuarios específica para el proyecto, con entrevistas o un estudio cuantitativo, por lo que sus conclusiones no se presentan como validación de mercado. Son hipótesis de diseño informadas por la experiencia previa, el análisis del producto, la microestructura de mercado y la iteración sobre prototipos funcionales.

La primera tarea fue separar cuatro conceptos que suelen convivir visualmente, pero no significan lo mismo:

• Precio: dónde se ha negociado y cómo ha evolucionado el rango.
• Volumen: cuánto se ha ejecutado y cómo se distribuye por nivel.
• Liquidez: qué órdenes permanecen disponibles antes de ejecutarse.
• Ejecución: qué operaciones acaban de cruzarse, con qué tamaño y a qué precio.

Después se analizaron las relaciones entre chart, DOM, Time & Sales, ticket de ejecución, mercados y actividad. Esto permitió identificar una condición de producto fundamental: si cada panel utiliza un tiempo, una escala o un estado distinto, la interfaz puede parecer precisa y seguir contando historias incompatibles.

El alcance se acotó deliberadamente. Markets, cuenta, órdenes y ejecución sirven como contexto de interfaz o simulación local. El núcleo comprobable se concentra en la lectura del mercado y en la coordinación del replay histórico.

Principios para una interfaz de trading

Un contexto temporal compartido

Chart, DOM y Time & Sales se alimentan del mismo reloj histórico. Cambiar el modo del gráfico no inicia otra sesión ni rompe la continuidad del replay. Esta decisión técnica también es una decisión de producto: todas las vistas deben responder a la misma pregunta temporal.

Densidad con jerarquía estable

La interfaz utiliza superficies contenidas, encabezados compactos y tipografía numérica para permitir mucha información sin que todo tenga la misma prioridad. El último precio, los niveles relevantes y los controles activos destacan; el chrome permanece en segundo plano.

Color con significado

Verde y rojo se reservan para estados de mercado y lado agresor. El acento cálido de Apex guía foco y acción. Esta separación mantiene la identidad propia de la workstation sin competir con la semántica financiera.

Configuración próxima a su efecto

Los settings viven en el encabezado del panel que modifican. DOM, Time & Sales y chart mantienen controles locales con foco, teclado y cierre exterior coherentes, en lugar de trasladar decisiones frecuentes a una configuración global desconectada.

Lo visible define el análisis

El Volume Profile, el POC y los límites de la value area se recalculan sobre las velas agregadas visibles. Pan, zoom y timeframe no son solo navegación: cambian el contexto analítico que la persona está observando.

Anatomía del producto

La workstation se organiza alrededor de un núcleo temporal común. Las vistas no son widgets independientes: cada grupo explica una dimensión distinta de la misma sesión.

El chart concentra la lectura principal. DOM y Time & Sales añaden profundidad y ritmo de ejecución. Markets, Execution y Activity completan el escenario de uso sin presentarse como conexiones operativas a un broker.

Tres formas de leer el precio

Cambiar entre Candles, Footprint y Step Profile conserva la sesión y sustituye la forma de observar cada intervalo. No son tres productos: son tres niveles de detalle para una misma pregunta.

La densidad permitida cambia según el modo. Candles admite una visión temporal amplia; Footprint necesita celdas suficientemente legibles; Step Profile protege la geometría de cada distribución. Los límites de zoom responden a esa diferencia y no a una escala arbitraria compartida.

Apariencia propia para cada lectura

Los settings del chart mantienen siempre accesibles las opciones comunes y adaptan el resto al modo activo. En Candles se pueden personalizar y restaurar los colores de velas alcistas y bajistas; Step Profile ofrece el mismo control para sus perfiles bid y ask. Cada preferencia se guarda de forma independiente, por lo que cambiar de representación no traslada una semántica de color que pertenece a otra vista.

Liquidez, aceptación y ejecución

El Volume Profile agrega el volumen de las velas visibles y construye una distribución lateral. El nivel con mayor volumen se convierte en POC. La value area se expande alrededor de ese punto hasta cubrir al menos el 70% del volumen, produciendo VAH y VAL. Cuando cambia el viewport, cambia también el cálculo.

El heatmap y el DOM responden a otra dimensión. Ambos parten de profundidad histórica L2: el heatmap permite observar cómo la liquidez resting se mantiene, aparece o desaparece a lo largo del tiempo; el DOM muestra una escalera precisa alrededor del último precio. Time & Sales, en cambio, registra operaciones que ya se han ejecutado.

El DOM también conecta lectura y operativa simulada. Seleccionar cualquier nivel bid o ask copia ese precio en el campo Limit price de Execution para preparar el ticket sin transcribir cifras entre paneles. La acción solo completa el formulario local: no envía ni ejecuta una orden real.

Separar estos conceptos fue una de las decisiones de contenido más importantes. Ayuda a evitar que intensidad, volumen y actividad se interpreten como señales equivalentes.

Un sistema propio para la workstation

Apex Trader tiene una identidad y un sistema propios, definidos para la lectura de mercados. El canvas oscuro, el acento cálido y la profundidad contenida se ajustan a una workstation con datos densos; los roles para compra, venta, liquidez, niveles analíticos, datos secundarios y estados del replay pertenecen a ese contexto.

El sistema se concreta en patrones repetibles:

• Headers de panel compactos que conservan contexto y settings.
• Controles con bordes sutiles, estados de foco visibles y targets operables.
• Tablas densas con alineación numérica y jerarquía estable.
• Popovers no modales que permiten seguir utilizando el resto de la terminal.
• Capas SVG coordinadas por el mismo viewport, escalas y comportamiento de puntero.
• Superficies y divisores que ordenan la workstation sin añadir decoración innecesaria.

Estas decisiones no proceden de un sistema compartido ni pretenden extenderse a otros productos. En Apex se mantienen juntas porque el dominio exige datos densos, estados semánticos y visualizaciones coordinadas.

Implementar el modelo de producto

La interfaz de Apex está construida con React y Vite. La landing y la demo comparten lenguaje visual, pero tienen fronteras técnicas distintas. La landing carga escenas aisladas con fixtures deterministas y no inicializa el replay. La demo carga la workstation y conecta chart, DOM y Time & Sales al histórico de BTCUSDT.

Los gráficos se componen mediante capas SVG especializadas. Viewport, geometría, escalas, hit testing y niveles analíticos se coordinan mediante interfaces internas para que pan, zoom y cambio de timeframe no desalineen unas capas respecto a otras. El heatmap utiliza una capa Canvas dentro del mismo contexto visual porque trabaja con tiles de liquidez más densos.

La carga histórica diferencia entre datos necesarios y capas opcionales. Si falla el heatmap, la lectura principal puede continuar. Durante buffering se conserva la última vista válida. Cache Storage actúa como optimización y no como requisito para reproducir una respuesta válida obtenida por red.

La arquitectura también protege la página pública: la demo se carga de forma diferida y visitar la landing no solicita manifest, book, trades ni tiles de liquidez. Esta separación reduce coste inicial y mantiene honesta la diferencia entre una explicación interactiva y el producto conectado al replay.

Iterar y comprobar

El proyecto se ha evaluado en tres niveles diferentes:

1. Revisión de producto y diseño: comparación entre modos, jerarquía de los paneles, densidad, consistencia de settings y claridad de la narrativa pública.
2. Verificación técnica: tests unitarios de agregación, replay y presentación; pruebas E2E de rutas, interacción, foco y estados; builds reproducibles de aplicación y biblioteca de componentes.
3. Revisión visual: capturas de la workstation, comprobaciones responsive de landing y revisión directa de los despliegues publicados.

Estas verificaciones demuestran comportamiento y coherencia de implementación. No equivalen a validación de mercado ni a un estudio de usabilidad con traders. Esa diferencia forma parte de la evaluación honesta del proyecto y señala el siguiente tipo de evidencia que necesitaría una evolución comercial.

Qué es y qué no es Apex Trader

El replay aporta un contexto común para comprobar la interfaz, pero no convierte el proyecto en un servicio comercial de market replay. La intención es hacer visible el proceso de entender un dominio complejo y llevarlo desde research y sistema visual hasta código funcional.

Explorar el proyecto