Stellaromics

Einen Forschungsprototypen in ein Instrument verwandeln, das ein Labor nutzen kann.

Wir haben die instrumentenseitige Softwareschicht konzipiert und implementiert – von der Benutzeroberfläche über die Hochdurchsatz-Bildwiedergabe bis zur Integration der Experimentsteuerung. So wurde aus einem Forschungsprototypen, der nur von seinen Entwicklern bedienbar war, ein Produkt, das ein Labortechniker bedienen kann.
UX-Forschung
UI-Design
Entwicklung
HMI-Integration
WPF
Über Pyxa

Eine 3D-räumliche Multi-Omics-Plattform und die Software, die sie bedienbar macht

Pyxa kombiniert Probenvorbereitung, automatisierte Bildgebung und 3D-Datenanalyse in einem System. Es erfasst die Genexpression in dicken Gewebeschnitten von bis zu 100 µm, mit Einzelzellauflösung, jenseits der Grenzen der 2D-Raumbiologie. Die Plattform besteht aus drei Komponenten: einem physischen Instrument, proprietärer Chemie (SNAIL-Sonden, SEDAL-Sequenzierung) und Software.
Diese Fallstudie befasst sich mit einem Teil dieser Software, der Instrumentensteuerungssoftware: der Benutzeroberfläche, die ein Bediener verwendet, um eine Probe zu laden, den mehrtägigen Workflow auszuführen und die sequenzierungswürdigen Regionen auszuwählen. Die Wissenschaft änderte sich nicht. Das Produkt drumherum schon.
The Pyxa instrument by Stellaromics, a 3D spatial multi-omics platform for gene expression analysis in thick tissue sections at single-cell resolution.
Die Herausforderung

Pyxa funktionierte bereits, aber nur für die Leute, die es entwickelt hatten. Der Betrieb erforderte ein Verständnis des Assays, der Hardware und der internen Logik des Prototyps. Wir mussten es so gestalten, dass es von einem Labortechniker bedient werden konnte, der diesen Kontext nicht hatte und sich keinen Fehler leisten konnte, ohne dabei die Tiefe zu verlieren, auf die sich die Wissenschaftler weiterhin verlassen.

Zwei Benutzer, ein Produkt
Ein Wissenschaftler, der den Assay versteht, und ein Techniker, der ihn durchführt, teilen sich eine Benutzeroberfläche mit gegensätzlichen Anforderungen.
Wissen ohne einen einzigen Verantwortlichen
Die Hardware auf der anderen Seite
Lange Operationen, asynchrone Ereignisse und physische Zustände, die die Benutzeroberfläche nicht vortäuschen kann.

"Was UXDivers auszeichnet, ist ihre Fähigkeit, Benutzererfahrung, Produktziele, technische Einschränkungen und die Realitäten der Software-Hardware-Interaktion in Einklang zu bringen. Sie haben uns geholfen, einen komplexen wissenschaftlichen Workflow zu vereinfachen und gleichzeitig eine optimierte und leistungsstarke Implementierung beizubehalten."

Daniel Bollish
Daniel Bollish
Leitender Softwareentwickler bei 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 eingeworben
Fachsprache

Erfassung des Laborvokabulars.

Bevor wir einen Bildschirm entwarfen, erfassten wir den räumlichen Multi-Omics-Workflow gemeinsam mit den Wissenschaftlern von Stellaromics, Begriff für Begriff, mit Synonymen und Randfällen. Ohne eine gemeinsame Sprache zwischen unserem Team, den Technikern und den Forschern wäre jeder von uns entworfene Workflow unzureichend gewesen.
Die Hälfte der anfänglichen Arbeit war keine Benutzeroberfläche; es war ein Glossar, und dieses Glossar wurde zum Rückgrat jeder Beschriftung, jedes Status und jeder Fehlermeldung im Produkt.
Glossar – Auszug
Interessierender Bereich (ROI)
Der Unterbereich einer Probe, den der Bediener für den vollständigen Durchlauf auswählt.
Analysegruppe
Eine Gruppe verwandter ROIs, die für eine gemeinsame Analyse zusammengefasst wurden.
Amplikon
Das amplifizierte DNA-Signal, das während der Probenvorbereitung von einem Target erzeugt wird.
Übersichts-Scan
Ein schneller Gewebescan zur Identifizierung und Definition interessierender Bereiche für die weitere Analyse.
Panel-Datei
Eine wiederverwendbare Experimentkonfiguration, die den Assay, erforderliche Reagenzien, Probenvorbereitung und Geräteeinstellungen definiert.
Dicker Gewebeschnitt
Eine Probe von 20 bis über 100 µm Dicke, in 3D abgebildet statt als flacher 2D-Schnitt
Unsere Arbeitsweise

Gestaltung mit den Menschen, die die wissenschaftlichen Grundlagen geschaffen haben.

Wir arbeiteten in drei parallelen Modi, nicht in drei aufeinanderfolgenden Phasen. Wir haben gemeinsam mit den Wissenschaftlern, die die Methode entwickelt haben, entworfen, jeden Schritt mit den Technikern validiert, die ihn ausführen würden, und die beiden Ansätze mit den Einschränkungen der Hardware- und Engineering-Teams abgestimmt. Die Entscheidungen waren tragfähig, weil jede Gruppe, die einen Teil des Problems besaß, an deren Gestaltung beteiligt war.
Co-Design mit den Urhebern
Arbeitssitzungen mit den Wissenschaftlern, die die Methode entwickelt haben, um das Interaktionsmodell zu entwerfen, anstatt Mockups zu genehmigen.
Validierung mit Bedienern
Jeden Schritt mit den Technikern testen, die Experimente für Kunden durchführen.
Abstimmung mit den Einschränkungen
Abstimmung der beiden Ansichten mit den Gegebenheiten von Hardware, Firmware und Technik.
Ambient Weather danachAmbient Weather davor
Davor
Danach
Produktentscheidungen

Fünf Entscheidungen, die das Produkt prägten.

01
Entwicklung für zwei Bediener gleichzeitig
Pyxa hat zwei Benutzer mit gegensätzlichen Bedürfnissen: einen Wissenschaftler, der den Assay von A bis Z versteht, und einen Techniker, der ihn für einen Kunden ausführt und nicht über dieses umfassende Verständnis verfügt. Wir haben einen geführten, abgesicherten Pfad zur Standardeinstellung gemacht und einen erweiterten Modus hinzugefügt, der erfahrenen Benutzern ermöglicht, unnötige Prüfungen zu überspringen. Ein dritter Modus, Demo, führt das Produkt auf einem einzigen Touchscreen auf Konferenzen aus. Ein Produkt bedient alle drei, ohne Kompromisse bei einem von ihnen einzugehen.
02
Den Workflow neu ordnen, um kostengünstiges Scheitern zu ermöglichen
Die ursprüngliche Sequenz verbrauchte teure Reagenzien, bevor die Lebensfähigkeit der Probe bestätigt wurde, sodass eine fehlgeschlagene Vorbereitung Tausende von Dollar und eine unersetzliche Probe verschwendete. Wir haben den Ablauf neu geordnet: Das Instrument führt einen schnellen Scan durch und bestätigt das Signal, bevor es den Bediener auffordert, Reagenzien aufzutauen. Fehler treten jetzt früh auf, wenn sie nichts kosten.
03
Nur das Nötigste für den Bediener sichtbar machen
Ein räumlicher Multi-Omics-Durchlauf birgt weitaus mehr Komplexität, als ein einzelner Schritt erfordert. Wir gestalteten die Benutzeroberfläche nach dem Prinzip der progressiven Offenlegung, mit bildbasierter, schrittweiser Anleitung und minimaler Texteingabe, da keine Tastatur vorhanden ist, und mit einer weiteren Detailebene. Der Bediener sieht nur die Entscheidungen, die jetzt wichtig sind; alles andere bleibt ausgeblendet, bis es benötigt wird.
04
Die Schnittstelle als Spiegel der Maschine gestalten
Lange, asynchrone Operationen und physikalische Zustände können nicht vorgetäuscht werden, und eine außer der Reihe ausgeführte Aktion kann das Instrument beschädigen oder einen Durchlauf ruinieren. Wir gestalteten viele Bildschirme als nicht-interaktive Statusanzeigen, die den tatsächlichen Hardware-Zustand widerspiegeln, und entwickelten die Workflows so, dass sie fehlerhafte Aktionen erkennen, diese klar erklären und sicher rückgängig machen. Der Bediener muss nie raten, was die Maschine tut, und bleibt nie stecken.
05
Den Workflow rekonfigurierbar gestalten
Die wissenschaftlichen Grundlagen änderten sich ständig hinter der Benutzeroberfläche, und neue Kontexte tauchten immer wieder auf. Wir definierten den Workflow deklarativ, jeder Bildschirm beschreibt sich selbst, nicht den nächsten, und isolierten die Benutzeroberfläche von der Steuerungssoftware des Instruments hinter einer dedizierten Schicht. Der Erfolg war unmittelbar: Ein vollständiger Konferenz-Demo-Modus war innerhalb weniger Tage einsatzbereit, und Backend-Änderungen beeinträchtigten die Benutzererfahrung selten.
Technische Hinweise

Unter der Haube.

Die Software von Pyxa koordiniert große 3D-Datensätze, ein physisches Instrument und eine Workstation, die nicht an die Cloud angebunden werden kann. Drei technische Entscheidungen bildeten das Fundament des restlichen Produkts.
WPF
DirectX
.NET
MVVM (Prism)
DirectX 9 und 11 für 3D-Rendering überbrücken
WPF rendert nativ auf DirectX 9, aber Pyxas Gewebebilder, die groß, gekachelt und in 3D zoombar sind, benötigten DirectX 11. Wir haben eine Interop-Schicht entwickelt, die GPU-Texturen zwischen den beiden teilt, und einen benutzerdefinierten Renderer darüber gelegt: Die .NET-Seite steuert, was gezeichnet wird und bei welcher Zoomstufe, während das Rendering nah an der GPU bleibt. Dieselbe Oberfläche steuert nun die berührungsbasierte ROI-Auswahl und wird in internen Tools wiederverwendet.
Die Benutzeroberfläche vom Instrument isolieren
Wir haben eine Abstraktionsschicht zwischen der Benutzeroberfläche und der Steuerungssoftware sowie den proprietären Protokollen des Instruments platziert. Als das Wissenschaftsteam etwas auf niedriger Ebene änderte, aktualisierten wir eine Schicht, und nichts anderes ging kaputt, was es ermöglichte, das Design schnell zu iterieren, ohne auf das Backend warten zu müssen.
Den Workflow deklarativ definieren
Das Produkt ist ein großer, geführter Workflow, der als Daten und nicht als fest codierte Übergänge definiert ist, sodass kein Bildschirm den nächsten kennen muss. Diese Entscheidung hat sich ausgezahlt: Ein Konferenz-Demo-Modus wurde innerhalb weniger Tage durch Neudefinition des Workflows erstellt, und der erweiterte Modus nutzte dieselbe Engine wieder.
Lab technician in gloves interacting with the Pyxa touchscreen interface, navigating the Confirm Run Setup screen with well status indicators.

Ein komplexes System entwickeln?

Wir entwickeln und gestalten produktionsreife Schnittstellen für eingebettete Systeme, Desktop-Plattformen und plattformübergreifende Produkte.th Untitled.
Gespräch vereinbaren