Stellaromics

Transformar un prototipo de investigación en un instrumento que un laboratorio pueda operar.

Diseñamos y entregamos la capa de software orientada al instrumento, desde la interfaz de usuario hasta la renderización de imágenes de alto rendimiento y la integración del control de experimentos, transformando un prototipo de investigación, utilizable solo por sus inventores, en un producto que un técnico de laboratorio puede operar.
Investigación de UX
Diseño de UI
Desarrollo
Integración HMI
WPF
Acerca de Pyxa

Una plataforma multiómica espacial 3D y el software que la hace operable

Pyxa combina la preparación de muestras, la imagen automatizada y el análisis de datos 3D en un solo sistema. Captura la expresión génica en secciones de tejido gruesas de hasta 100 µm, con resolución de una sola célula, superando los límites de la biología espacial 2D. La plataforma consta de tres elementos: un instrumento físico, química propietaria (sondas SNAIL, secuenciación SEDAL) y software.
Este caso de estudio trata sobre una parte de ese software, el software de control del instrumento: la interfaz que un operador utiliza para cargar una muestra, ejecutar el flujo de trabajo de varios días y seleccionar las regiones que merecen ser secuenciadas. La ciencia no cambió. El producto a su alrededor sí lo hizo.
The Pyxa instrument by Stellaromics, a 3D spatial multi-omics platform for gene expression analysis in thick tissue sections at single-cell resolution.
El desafío

Pyxa ya funcionaba, pero solo para las personas que lo habían creado. Operarlo implicaba entender el ensayo, el hardware y la lógica interna del prototipo. Tuvimos que lograr que funcionara en manos de un técnico de laboratorio que no tenía ese contexto y no podía cometer un error, sin eliminar la profundidad en la que los científicos aún confían.

Dos usuarios, un producto
Un científico que entiende el ensayo y un técnico que lo ejecuta, compartiendo una misma interfaz con necesidades opuestas.
Conocimiento sin un único propietario
El hardware al otro lado
Operaciones largas, eventos asíncronos y estados físicos que la interfaz no puede simular.

“Lo que destaca de UXDivers es su capacidad para equilibrar la experiencia del usuario, los objetivos del producto, las limitaciones técnicas y las realidades de la interacción software-hardware. Nos ayudaron a simplificar un flujo de trabajo científico complejo manteniendo una implementación optimizada y de alto rendimiento.”

Daniel Bollish
Daniel Bollish
Ingeniero de Software Principal en Stellaromics
Lab technician in gloves reviewing the Monitor Run screen on the Pyxa instrument interface, showing well status grid and experiment progress.
$80
M
Serie B recaudada
Lenguaje de dominio

Mapeando el vocabulario del laboratorio.

Antes de diseñar una pantalla, mapeamos el flujo de trabajo multi-ómico espacial con los científicos de Stellaromics, término por término, con sinónimos y casos límite. Sin un lenguaje compartido entre nuestro equipo, los técnicos y los investigadores, cualquier flujo de trabajo que diseñáramos se quedaría corto.
La mitad del trabajo inicial no fue la interfaz; fue un glosario, y ese glosario se convirtió en la columna vertebral de cada etiqueta, estado y mensaje de error en el producto.
Glosario — extracto
Región de interés (ROI)
La subárea de una muestra que el operador selecciona para la ejecución completa.
Grupo de análisis
Un conjunto de ROI relacionados agrupados para un análisis compartido.
Amplicon
La señal de ADN amplificada generada a partir de un objetivo durante la preparación de la muestra.
Escaneo general
Un escaneo rápido de tejido utilizado para identificar y definir regiones de interés para análisis posteriores.
Archivo de panel
Una configuración de experimento reutilizable que define el ensayo, los reactivos necesarios, la preparación de la muestra y los ajustes del instrumento.
Sección de tejido grueso
Una muestra de 20 a más de 100 µm de espesor, visualizada en 3D en lugar de como una sección plana en 2D
Cómo trabajamos

Diseñar con las personas que desarrollaron la ciencia.

Trabajamos en tres modos en paralelo, no en tres fases en secuencia. Codiseñamos con los científicos que crearon el método, validamos cada paso con los técnicos que lo ejecutarían y conciliamos ambos aspectos con las limitaciones de los equipos de hardware e ingeniería. Las decisiones se mantuvieron porque cada grupo que era parte del problema contribuyó a darles forma.
Codiseño con los creadores
Sesiones de trabajo con los científicos creadores del método, para elaborar el modelo de interacción en lugar de solo aprobar maquetas.
Validación con operadores
Probando cada paso con los técnicos que realizan experimentos para los clientes.
Conciliación frente a las limitaciones
Conciliando las dos perspectivas con las realidades de hardware, firmware e ingeniería.
Ambient Weather despuésAmbient Weather antes
Antes
Después
Decisiones de producto

Cinco decisiones que dieron forma al producto.

01
Diseñar para dos operadores a la vez
Pyxa tiene dos tipos de usuarios con necesidades opuestas: un científico que entiende el ensayo de principio a fin, y un técnico que lo ejecuta para un cliente y no lo comprende. Establecimos una ruta guiada y protegida como predeterminada, y añadimos un modo Avanzado que permite a los usuarios expertos omitir las comprobaciones que no necesitan. Un tercer modo, Demostración, ejecuta el producto en una única pantalla táctil en conferencias. Un solo producto satisface a los tres sin comprometer a ninguno de ellos.
02
Reordenar el flujo de trabajo para que el fallo sea económico
La secuencia original comprometía reactivos caros antes de confirmar que la muestra era viable, por lo que una preparación fallida desperdiciaba miles de dólares y una muestra irremplazable. Reordenamos el flujo: el instrumento realiza un escaneo rápido y confirma la señal antes de pedir al operador que descongele los reactivos. Ahora, el fallo ocurre temprano, cuando no cuesta nada.
03
Mostrar solo lo que el operador necesita
Una ejecución de multiómica espacial implica mucha más complejidad de la que requiere cualquier paso individual. Diseñamos la interfaz en torno a la divulgación progresiva, una guía paso a paso basada en imágenes y una entrada de texto mínima, ya que no hay teclado, con un nivel de profundidad. El operador ve solo las decisiones que importan en ese momento; todo lo demás permanece oculto hasta que se necesita.
04
Hacer que la interfaz refleje la máquina
Las operaciones largas y asíncronas y los estados físicos no pueden simularse, y una acción realizada fuera de secuencia puede dañar el instrumento o arruinar una ejecución. Convertimos muchas pantallas en superficies de estado no interactivas que reflejan el estado real del hardware, y construimos los flujos de trabajo para detectar acciones fuera de secuencia, explicarlas claramente y revertirlas de forma segura. El operador nunca se queda adivinando qué está haciendo la máquina, ni se queda atascado.
05
Diseñar el flujo de trabajo para que sea reconfigurable
La ciencia seguía cambiando bajo la interfaz, y seguían apareciendo nuevos contextos. Definimos el flujo de trabajo de forma declarativa, cada pantalla se describe a sí misma, no a la siguiente, y aislamos la interfaz de usuario del software de control del instrumento detrás de una capa dedicada. El resultado fue directo: un modo de demostración completo para conferencias se preparó en días, y los cambios en el backend rara vez estropearon la experiencia.
Notas de ingeniería

En el fondo.

El software de Pyxa coordina grandes conjuntos de datos 3D, un instrumento físico y una estación de trabajo que no puede estar conectada a la nube. Tres decisiones de ingeniería mantuvieron unido el resto del producto.
WPF
DirectX
.NET
MVVM (Prism)
Uniendo DirectX 9 y 11 para renderizado 3D
WPF renderiza de forma nativa en DirectX 9, pero las imágenes de tejido de Pyxa, grandes, en mosaico y con zoom en 3D, necesitaban DirectX 11. Construimos una capa de interoperabilidad que comparte texturas de GPU entre ambos y un renderizador personalizado encima: el lado .NET controla lo que se dibuja y a qué nivel de zoom, mientras que la renderización se mantiene cerca de la GPU. La misma superficie ahora impulsa la selección de ROI basada en el tacto y se reutiliza en todas las herramientas internas.
Aislamiento de la interfaz de usuario del instrumento
Colocamos una capa de abstracción entre la interfaz y el software de control del instrumento y los protocolos propietarios. Cuando el equipo científico cambió algo de bajo nivel, actualizamos una capa y nada más se rompió, lo que permitió que el diseño iterara rápidamente sin depender del backend.
Definición declarativa del flujo de trabajo
El producto es un gran flujo de trabajo guiado, definido como datos en lugar de transiciones codificadas rígidamente, para que ninguna pantalla necesite conocer la siguiente. Esa decisión se amortizó sola: un modo de demostración para conferencias se montó en días redefiniendo el flujo de trabajo, y el modo Avanzado reutilizó el mismo motor.
Lab technician in gloves interacting with the Pyxa touchscreen interface, navigating the Confirm Run Setup screen with well status indicators.

¿Construyendo un sistema complejo?

Diseñamos y desarrollamos interfaces listas para producción para sistemas embebidos, plataformas de escritorio y productos multiplataforma.th Untitled.
Agendar una llamada