Roadrunner AI Platform Redesign
A ground-up redesign of an evidence-synthesis platform, delivered as a 44-screen working prototype. One designer directing an AI implementer, with every decision documented.
Systematic reviews, without the months.
Roadrunner AI is an evidence-synthesis platform for researchers. Its job is to compress work that traditionally takes a research team months into something closer to an afternoon.
A systematic review is the backbone of academic evidence. You define a question, gather every study that might answer it, screen them against inclusion criteria, extract the data that matters, and report what the evidence says, documenting every decision along the way so another researcher can audit your reasoning. Done properly it is slow, meticulous, and unforgiving of shortcuts.
Roadrunner's engine does this well. Its search returns genuinely good cited answers, and its five-step review flow, ending in a PRISMA diagram that accounts for every study included and excluded, is the real intellectual property. That engine is the reason the product exists.
The experience around it was the problem.
02 / THE AUDIT
I started by using the product as a new customer would.
Before proposing anything, I signed up for a fresh account and worked through the live product screen by screen, documenting what I found. The brief came out of that audit rather than preceding it.
What surfaced fell into four groups.
The evidence chain contradicted itself. A completed systematic review rendered a PRISMA diagram of all zeros. A summary panel and the generated report disagreed on how many studies had been excluded. For a product whose entire value is a defensible, auditable evidence trail, numbers that do not reconcile are not a cosmetic issue. They undermine the thing being sold.
The information architecture was redundant. Account menu items opened the same screens as settings tabs. Two separate activity trackers disagreed with each other. The navigation shifted position from page to page, so the target you were aiming for moved as you moved.
The value proposition was buried. One entry point named "Synthesis" led to two genuinely different kinds of work, and named neither of them.
Details were eroding trust. Three different names for the same subscription tier across marketing, app, and help. A credit meter that could not be mapped to any action. A signup consent line declaring that account emails "cannot be unsubscribed from." A developer error page shipped to production.
None of these were failures of the engine. Every one of them was the experience getting in the engine's way.
03 / THE DIAGNOSIS
One door, two very different jobs.
The most consequential finding was the smallest to describe.
Researchers came to Roadrunner for two distinct reasons. Sometimes they wanted a fast, cited answer to a specific question, in minutes. Sometimes they wanted the full guided systematic review, the months-long process compressed. These are different jobs with different expectations of time, rigour, and output.
Both lived behind a single entry point called "Synthesis," which described neither. The quick-answer intent, the more common of the two, had no visible home at all. Users had to discover by trial that the product could do the thing they most wanted.
That framing set the direction for everything that followed. Make the two modes legible and separately addressable. Make the evidence chain internally consistent wherever it appears. Unify the information architecture so the same destination is reachable one way. And strip out every detail that reads as machine-generated or unfinished, because in a product asking researchers to trust its output, those details are not cosmetic.
04 / HOW THE WORK WAS RUN
I made the decisions. The AI did the execution.
This engagement was produced by a product lead directing an AI implementer, Claude Code, across long working sessions. That arrangement is only as good as the discipline around it, so the discipline was the first thing built.
The standard was written before any screens were. A project specification encoded the design system, the component specs, and the working rules, including a standing instruction that any design file provided is treated as a pixel-perfect spec, with a mandatory difference table produced and reviewed before code is written. Quality did not depend on how well any individual instruction happened to be phrased. It was enforced by a document that outlived every session.
Judgment shows up in what got rejected. A flush three-column variant, reverted because it made the surface busier. A review-first restructure of the library, reverted. An over-corrected declutter of the summary panel, reverted to the previous design. Design exploration was frequently delegated to a design-focused subagent that returned written specifications, which I then accepted, amended, or overruled. The record of what was turned down is a more honest account of the work than the record of what shipped.
Verification was measured, not eyeballed. Contrast ratios were computed rather than judged by eye. Navigation tab positions were measured to the pixel across all forty-four pages. Table scroll behaviour was confirmed in the DOM rather than assumed. Every tool flow was run end to end in an iframe, which caught a JavaScript error that structural checks had passed cleanly.
That discipline caught the AI's own mistakes. A regular expression that silently swallowed three cards. A function declaration stripped out of freshly inserted code. Card labels overflowing their tabs. A pricing model invented before the real one was known. Each of these surfaced because something was measuring the work, not because the tool reported that it was fine.
This is the part I would want a client to look at hardest. Directing an AI implementer is not the difficult bit. Knowing when it is wrong is.
05 / WHAT WAS BUILT
Forty-four screens, fully interactive.
The deliverable is a self-contained working prototype covering both work modes end to end. Every screen runs on fixed data, but nothing is a picture of an interface. Filters filter, tabs switch, drawers slide, tools run and produce output, forms validate.
Two modes over one shared corpus. Quick answer for a fast cited response. Guided review for the full five-step process, Define through Report, each step its own screen, with the report gated until every study is confirmed. A shared question composer feeds both, so the question is written once and the mode is a choice made afterwards.
A systematic review as an object. The review hub presents a review as a thing with a state: its question, its step rail, its evidence flow, its protocol, its screening record with per-decision attribution, its extraction table, its team, its activity.
The supporting surfaces. A 261-item library with combinable faceted filtering and a slide-out source preview. Six analysis tools, each with a complete pick-sources, run, output, save flow and a genuinely distinct output artifact. Four import methods. One consolidated settings home replacing a structure that previously spread the same destinations across seven tabs, four profile sub-tabs, and an account menu. Nineteen fully written guide articles. A time-grouped notifications drawer.
Consistency without a framework. Common behaviour lives in shared assets injected into every page, including one shared responsive layer giving every layout family a tablet and phone behaviour. The global header is byte-identical across all forty-four pages, which makes the nav-shift defect from the live product structurally impossible rather than merely fixed.
06 / WHAT I DELIVERED
Three strands, one engagement.
The work ran in two phases, and the first one produced the foundation the second inherited.
A marketing website, built from scratch. Four pages covering the landing, features, pricing, and enterprise story, built as a self-contained static site and deployable. This is where the product's positioning was settled: purpose-built for the rigour and methods of life sciences and biomedical research rather than a generic AI research tool, with the workflow spine named as search, screen, extract, synthesize. That spine and the teal and coral brand established here were carried wholesale into the app redesign. Two client constraints shaped the site and were preserved throughout: no references to writing or authoring, since the product's value is synthesis rather than drafting, and no named data sources anywhere in copy or mockups.
Three audit documents. An IA and UX audit of the live product, produced from a walkthrough on a fresh account with every populated flow exercised rather than inferred, cataloguing thirteen findings with the strengths worth preserving named explicitly. A UX heuristic audit as its companion, grading the same product against established frameworks including Nielsen's heuristics, WCAG, Morville's honeycomb, Norman's principles, and cognitive load theory, so that every finding carried a second justification a design-literate stakeholder could check against a known standard. And a marketing site inventory, which existed to reconcile the two: where the promise made in marketing and the reality of the app diverged.
A forty-four screen interactive prototype. The full redesign, covering both work modes end to end, delivered as a working build rather than a set of comps.
And the strategy documents that closed the engagement. A design brief, competitive research, and a scoped, costed proposal for connecting the redesigned frontend to a real backend.
07 / DESIGN SYSTEM AND SPECIFICATION
A full system, specified for desktop and mobile.
Alongside the prototype, the design was delivered as a complete Figma specification covering desktop and mobile, with the design system documented as the source of truth for both.
The system is built on restraint. A deep teal ground with coral as the single action accent, used sparingly enough that one coloured element on a surface reads as intentional rather than as a warning. Inter for prose and interface, with a monospace face restricted to numerics and all-caps micro-labels, so data reads as data. One rule governs the copy across every screen and article: the actor is always Roadrunner, never a bare "AI". A product asking researchers to trust its output should name itself when it acts.
Everything delivered in Figma adheres to WCAG 2.2. Contrast was computed rather than judged by eye. Minimum type sizes were set as a floor rather than a target. Keyboard and escape handling was specified on every overlay, and reduced-motion preferences honoured throughout. In a product built for institutions with procurement and compliance requirements, accessibility is not a finishing pass. It is a condition of the sale.
08 / WHAT'S NEXT
The prototype specifies what the backend has to serve.
The redesign is front-end only by design. Fixed data throughout, no persistence, no live sources. Its purpose is to specify precisely what a real backend must deliver, which makes the next phase an extension rather than a guess.
Reading the running product established what already exists: a React application, a same-origin REST API, a real database, working authentication. It also established something useful about the original defect. The PRISMA aggregation runs client-side, which reframes the all-zeros diagram from an unknown failure into an aggregation bug over data the API already holds. Small, well-understood, and high value.
The engagement closed with a scoped and costed proposal for that build. The important move in it was commercial rather than technical. The client did not have the engineering bandwidth to take on a backend project, so the ask was reframed. Not "build us a backend," but "name one engineer to review the work at three gates": the data and authorization model before any code is written, continuous review of small weekly increments, and a security and load review before launch. Roughly a day up front, a few hours a week, and two to three days before launch.
The decision put to stakeholders stopped being whether this could be built, and became whether they could name a reviewer.
09 / REFLECTION
What this engagement taught me, and what I would question.
The domain was new, and twenty years of product design did not close that gap.
Healthcare and biomedical research was unfamiliar territory. I invested real time in understanding the users and the processes they work within, but I would be overstating my confidence if I claimed that closed the distance. Two decades of designing products teaches you how to learn a domain quickly. It does not give you a researcher's instinct for where the risks sit in their work, and there were blind spots I am certain I did not see. In a field where the output has to withstand academic scrutiny, not knowing what you do not know is a genuine design risk, and it is the part of this engagement I would most want a second pass on.
Designing evidence-based flows taught me more than I brought to them.
The systematic review process is unlike most product flows I have designed. It is not a funnel to be optimised or a task to be shortened. Every step exists to make a decision auditable by someone who was not there, and the discipline of that changes what good design means. A shortcut that saves a user thirty seconds is a defect if it removes a decision from the record. Learning to design for defensibility rather than efficiency was the most valuable thing I took from this work.
We did not do proper user testing, and I flagged that.
The client's position was that the CEO was the user, and that feedback from the product team was sufficient. I raised this at the time and it remains the largest gap in the engagement. Feedback from people who built the product and people who commissioned it is not user testing. It cannot tell you where a first-time researcher gets lost, and it systematically misses the things insiders have stopped noticing.
The redesign is grounded in a screen-by-screen audit of the live product and in domain research, which is real evidence but not the same evidence. With more time and access I would have run unmoderated testing with practising researchers before committing to the two-mode structure. That structure is the single largest bet in the redesign, and it is currently supported by reasoning rather than by observation.
And the prototype is a confident specification for a system I had not yet read.
Forty-four screens of fixed data make a very specific claim about what a backend should serve, written before I had seen that backend's code. Some of those assumptions will turn out to be wrong. The delta analysis in the proposed next phase exists precisely for that reason, which is the correct way to handle it, but it is worth naming plainly rather than presenting the prototype as settled.