No-code authoring platform for medical educators

A research-grade learning method only earns field deployment when someone besides the inventors can author with it. The PALMs Authoring Tools were the bridge—turning a perceptual-adaptive learning PoC into a no-code product clinical educators could actually run.

My role

I was the design engineer on a small R&D team at Insight Learning Technology—the only person carrying product design, interaction design, code templates (HTML/CSS that later became React components), and design/usability QA across the full surface. Day-to-day this meant facilitating research and whiteboarding with our domain experts, owning the click-through wireframe system, partnering with engineering on the editor and authoring flows, and keeping the experience coherent as the codebase and content model matured. The companion case study, PALMs: from cognitive science to product PoC, covers the learner-side product I worked on alongside this; this page is specifically about the authoring side—the product that lets educators turn course content into PALMs without asking engineering for help.

Team during the build: two domain experts (the inventors and instructional-design authority on PALMs), one project manager, four engineers, and one design engineer (me). The vision and program mandate were set by leadership and our customer; I owned the product translation—what to build first, what to defer, and what “authorable by an educator, not a developer” actually had to look like end to end.

Program context

The program paired Insight Learning Technology with institutional buyers scaling perceptual-adaptive learning into medical education; the end users were clinical and medical educators. The mandate was to build a platform that lets those educators convert existing course content into PALMs—the perceptual and adaptive learning modules already validated by the research line. The proprietary learning method existed, the runtime existed, and individual custom-built modules existed. What did not exist was a way to scale authoring beyond the team that invented the science.

Internally, this work sat under Insight’s broader EdTech SaaS ecosystem play—an authoring layer, a delivery layer, and an analytics layer that had to feel like one product even though they shipped on different tracks. The PALMs Authoring Tools were the tip of the spear: if educators could not credibly author with them, the rest of the ecosystem story did not survive contact with a real institutional buyer. Heaviest delivery sat across 2016–2018, with continued iteration after.

Institutional delivery and instructional design

Most “authoring tool” roadmaps are written as if the customer is a friendly SaaS buyer who tolerates beta surfaces. This was not that. Two constraints set the bar:

Institutional programs. The platform had to be deliverable on a schedule that aligned with milestone-based program obligations and ship with a working demo path in the customer’s delivery environment. Ambiguity about scope, browser support, or what “done” meant was not a backlog discussion; it was a delivery risk.
Instructional design. PALMs is not a quiz engine. It encodes a specific theory of pattern recognition, factual learning, and procedural learning—and authors had to be able to express that without being walked through the cognitive-science literature. Naming, flow, and defaults had to nudge educators toward valid module shapes, not just toward shipped pixels.

Anything we built also had to live next to a proprietary runtime for module delivery. The authoring product could not redefine the data contract on a whim; field-side compatibility with already-deployed modules was a hard line.

The problem we framed

Mastery-based education needs more than didactic teaching. PALMs had already shown its effectiveness in the research record. The product question was not “does this work?”—it was:

How do we eliminate the technical barrier for educators so they can author PALMs the same way they assemble a lecture or a slide deck—without hand-coding modules?
How do we build a system around proprietary tech owned by a team of inventors—respecting their model—while turning it into something a non-author can use?
How do we do all of that for a high-profile program on a delivery clock, while keeping the door open to multi-year revenue rather than a single milestone payout?

Reframed concretely: the unit of value was an authored module that an educator could produce without engineering intervention, that the PALMs runtime would happily accept, and that another educator across a campus or partner site could reuse, edit, and grade against. Anything that did not contribute to that loop was scope.

Approach we sequenced

Because the underlying tech was proprietary and held by a small group of experts, the early work was as much organizational as design. I led research and roadmap-shaping sessions, drove group whiteboarding, and spearheaded a reverse-engineering pass on existing PALMs modules to extract the implicit interaction models, content requirements, and author-facing primitives. The goal was to translate a body of informal expertise into something a UI could be designed against—and a program delivery could be measured by.

From that base, the work moved through three deliberate passes:

Click-through wireframe system (50+ screens). Not decoration—an executable mental model. Every assumption and hypothesis about authoring a PALMs module became a screen, with navigation that domain experts and engineers could click through to argue with. This is where the bulk of disagreement got cheap.
Responsive UI templates → React components. I built the templates as production-grade HTML/CSS that engineering then converted into React components, so the fidelity translated cleanly from design to build. This kept the visual and interaction language consistent across editor surfaces and authoring flows—rather than letting each screen drift into its own dialect.
Cross-device and cross-browser hardening. Educators don’t all live on one IT-blessed laptop. We tested rigorously across devices, browsers, and screen sizes—because for an institutionally sold product, “it works on my machine” is a delivery defect, not a punchline.

Feedback came from three sources, layered intentionally: team members who knew the runtime, pilot educators who matched the actual buyer profile, and novice users probed in both unmoderated and task-primed sessions. The point of the novice cohort wasn’t to redesign for beginners; it was to surface the moments where domain literacy was quietly carrying the interface, so we could decide where to add scaffolding versus where to keep the expert path fast.

What shipped

The product that landed in the customer’s delivery environment was a responsive, web-based authoring platform—usable on desktop and on mobile—that let educators compose PALMs without touching code. Concrete capabilities included:

Module composition from author-facing primitives: create modules, organize them, and prepare them for delivery against the existing PALMs runtime contract.
Asset upload for images and text used as the stimulus material in pattern-recognition and factual/procedural sequences.
Question authoring: create, edit, and prioritize questions inside a module so the order and weight reflect instructional intent—not file-system order.
Question-level controls such as per-item timers, where the perceptual-adaptive method requires bounded response windows to do its work.
Responsive editor surfaces—the same primary authoring views worked across screen sizes, instead of forcing educators onto a single approved workstation.
Reusable React components built from the design system layer, so every authoring screen drew from the same visual/interaction vocabulary as the rest of the editor.
A platform that was live in the program environment with a working demo available—so reviews and customer conversations had a real artifact, not a deck.

What stayed deliberately out of scope in the MVP—because they did not serve the “educator can ship a module on their own” loop—were surfaces such as deep authoring analytics, heavy admin/governance tooling, and any rework of the underlying PALMs runtime. Those were not bugs; they were the part of the roadmap that had to wait for the authoring core to prove itself.

What I'd do differently

A few things only became obvious after watching real authors use the product:

Authors optimize iteratively. Educators didn’t sit down once and produce a finished module; they refined modules and assets over many sessions. Treating authoring as a one-shot wizard underestimated how much time users spent tuning already-created content.
Small inefficiencies compound. A two-extra-clicks cost on a single screen is invisible in usability testing and painful when an author repeats it across hundreds of items. We learned to budget interaction cost the way other teams budget page weight.
Invalidated hypothesis: wizards. We assumed structured wizards would be the lowest-friction path for educators. For high-volume material—exactly the kind of course conversion institutional programs generate—wizards were too slow. The fix wasn’t prettier wizards; it was investing in the main editor as a high-throughput surface, and reserving wizard-style flows for first-time authoring and edge cases. That was a real reversal in our roadmap.
Refinement is its own phase, not a closing sprint. We expected late, post-delivery feedback (stakeholder review cycles guarantee it) and treated visual-language polish, edge-case handling, and component-quality work as a deliberate phase rather than something to squeeze in around marketing screenshots.

Outcomes and traction

The PALMs Authoring Tools product was delivered on time and at the quality bar the customer expected, and shipped live in the program environment with a working demo path. The same authoring core supports educators on desktop and mobile and encodes the perceptual-adaptive method without asking authors to carry the cognitive-science literature in their heads.

External validation followed:

Program partners ran structured usability testing on the PALMs platform and its associated authoring tool—work that fed into broader evaluation of training outcomes and instructional requirements. That mattered far more than internal demos because it came from the field.
On the company side, a credible authoring product supported Insight’s broader medical-education and training work—a period over which the company executed against $5M+ in awarded contracts. The authoring tool was one piece of that picture, not the whole of it.

What this work was not: a glossy lab demo that read well in slides. It was a deliverable that survived stakeholder review cycles, field-side testing, and the daily reality of educators using it to produce real modules.

Closing

The unsexy lesson under all of this: the moment a research method has to leave the inventors’ hands, design and product work stops being decoration and starts being the thing that determines whether the method survives in the field. PALMs already had the science. What it needed was an author-facing surface credible enough to put in front of medical educators, schedule-tight enough to satisfy institutional delivery milestones, and theory-respecting enough that the resulting modules still did what the research said they would do. Building that surface was the work.