NULISA Analysis Software is where Alamar's researchers spend hours scanning dense data, reviewing QC, and generating reports. It's a genuinely capable platform — built science-first by a small team moving fast to keep pace with an ambitious product. As adoption grew, Alamar saw the right moment to invest in the interface's next level of consistency and polish, and brought me in to lead that work.
The brief: bring a cohesive design system and a few well-established usability principles to an already-working tool — refining the experience for researchers who live in it for hours at a time, without disrupting the science they rely on it for.
Rather than jumping to visuals, I ran a structured heuristic evaluation of the live application — grounding every design decision in a named, defensible principle instead of taste. I adapted Jakob Nielsen's 10 usability heuristics for a Shiny/Bootstrap context, then layered in established UX laws to guide the refinements.
A few principles shaped the biggest calls. Miller's Law guided consolidating table options into a single, focused control. Law of Proximity shaped grouping related actions and adding a dashboard summary, so researchers get context on entry. WCAG contrast informed a color system where each color carries one clear meaning.
I organized the work into a prioritized design plan across seven areas — information architecture, color, content, actions, data tables, modals, and front-end/responsive. The through-line of each:
Established a color system where each color carries a single, consistent meaning — keeping selection, status, and category clearly distinct.
Unified date/time formatting and adopted sentence case throughout — tuned for fast, comfortable scanning across long tables.
Gave complex actions like Edit analysis room to breathe as full-page flows, and added a dashboard summary so researchers get context the moment they open an analysis.
Streamlined the tables with clearer filter controls, sensible defaults, and tidier options — so the data stays the focus.
Added consistent interaction states across buttons and links, so it's always clear what's interactive.
Moved to responsive layout classes and a message bundle — smoother across screen sizes and ready for future localization.
I designed all five screens as a complete, clickable prototype — the full analysis flow, not a slide deck of suggestions. Every decision traces back to a principle and to how researchers actually work.
For each screen you can toggle between the starting point, the design I proposed, and what shipped. Because I was in the codebase, not handing a file over the fence, I made a series of in-flight calls as the design met real data and edge cases. The full design also proposed net-new surfaces sequenced for a later release; what's below is the flow that shipped.
An empty state that guides instead of just labeling: an illustration, a clear heading, and one sentence telling the user what selecting a row will do.
Mockup → shipped: the mockup added a "welcome back" banner, a resume-last-analysis shortcut, shared-by metadata, and an entry into a new QC Explorer. Those needed session state, sharing, and a brand-new surface — beyond a restyle — so I sequenced them. In their place I added the Runs range filter, once I saw how researchers actually narrow a long list.
The loaded preview restructured into a scannable hierarchy — headline stats, a QC-warnings callout, sample breakdown, and configuration — so a reviewer reads the analysis at a glance instead of parsing a wall of pills and notes.
Mockup → shipped: the mockup led the preview with an "Open QC Explorer" button and collaboration metadata — both needing new infrastructure. Working with real uploads, I set those aside and added the Sample Breakdown (CSF / serum / plasma) the mockup hadn't anticipated, because matrix composition is the first thing researchers check.
A sentence-case title, a labeled required field with a real-world example, and a helpful "nothing to preview yet" state guide first-time setup.
Mockup → shipped: the mockup reimagined this as a full-page flow that led with importing runs from the connected command center. That integration was real back-end work, so the release kept New Analysis as a modal — local upload first, command-center import as the second tab — the same two paths, scoped to what could ship now.
The same dense boxplot and QC table, with consistent navigation, sentence-case labels, and a single-meaning color system for the status pills — so status reads clearly at a glance.
Mockup → shipped: this is where scope showed up most. The mockup proposed a guided three-step workflow — QC → Statistics → Report — plus a net-new AI assistant and a re-categorized sidebar. Re-routing the app's navigation was beyond the release, so the brief became "keep the sitemap, apply the new system inside it." Shipping the restyle now beat shipping the re-architecture never.
The model-summary table and options panel cleaned up — a calmer header, sentence case, and clearer grouping of the fold-change and p-value controls.
Mockup → shipped: the mockup pictured a drag-and-drop model builder — drag covariates into the model, set reference groups and effect types, a distribution chart per covariate. That's a sizeable build, so the release restyled the existing model-summary and results tables instead — statistics on the new system now, with the builder captured in the roadmap.
The report builder reorganized around scope — a clear Report Scope control up top, three labeled export groups, and a single primary action instead of scattered options.
Mockup → shipped: the mockup folded reporting into the guided wizard as a final "Generate Report" step, with a model-completed status and a bundled ZIP. Held to the existing sitemap, it shipped as a standalone, restyled Download Report — the same scope control and grouped exports, without the wizard chrome that depended on the unshipped workflow.
The work delivered the cohesive, consistent experience the platform was ready for. And I didn't stop at design: I integrated the highest-value theme changes directly into the Shiny/R codebase myself — so the work lands in the product, not just a prototype.
Because not every change fits a single release, I sequenced the design plan into a roadmap the team can execute release by release — turning a one-time engagement into a durable path to the full experience. Scoping the work to what ships well, rather than everything at once, was part of the job.
Status: Design and redesign complete and approved; theme implementation underway in the R/Shiny codebase; a prioritized roadmap delivered for NAS 2.0 and beyond.
Currently open
Diagnose before design, then ship it in code. If you’ve got a complex, data-dense product that deserves the same treatment, let’s talk — open to product design roles in biotech and complex software.