Context
Prescriptions are a small but important part of day-to-day dental practice.
For clinicians, prescribing needs to be fast, accurate, and easy to complete between appointments. For practice teams, prescriptions also need to be visible, traceable, printable, and clearly connected to the patient record.
Before this project, prescriptions were handled through Dentally’s correspondence workflow. This worked, but it meant a clinical task was being treated more like document creation. Users could produce a prescription, but the experience lacked the structure, visibility, and confidence expected from a dedicated prescribing workflow.
The goal was to design a clearer end-to-end experience for creating, reviewing, printing, and managing prescriptions inside Dentally.
More importantly, we needed to understand what the right MVP should be.
Early ideas included e-prescribing, pharmacy delivery, digital signatures, AI-assisted prescribing, and deeper clinical automation. But before committing engineering time, we needed to learn what dental practices actually needed first.
The Core Problem
The main problem wasn’t that users couldn’t create prescriptions.
It was that the workflow didn’t feel purpose-built.
Dentists and practice staff needed a way to:
create common prescriptions quickly
review details before committing
print and hand-sign prescriptions
find previous prescriptions later
understand whether a prescription was active, printed, or cancelled
keep prescribing clearly connected to the patient record
There was also a product risk: building too much too early.
Prescribing is a regulated clinical workflow, and requirements vary across regions. A large, complex solution could easily slow the project down or introduce unnecessary risk.
The challenge was to design something simple enough to ship, but structured enough to become a foundation for future prescribing improvements.
Discovery
I started with lightweight research and product discovery.
Rather than running a long research phase before design, I used an iterative process:
research → HTML prototype → customer testing → refinement → retesting
This allowed us to learn quickly without staying abstract for too long.
Research included 11 customer and stakeholder sessions, along with internal feedback from product, engineering, support, and clinical subject matter experts.
The early research focused on understanding:
how dentists currently create prescriptions
how often they prescribe
which medications are commonly repeated
where prescriptions should live in the patient record
what information clinicians need before printing
what practice staff need after a prescription has been created
what should be included in MVP versus later phases
One of the clearest findings was that users did not need a highly advanced prescribing system immediately. They needed a dedicated, reliable workflow that matched how they already worked: select or enter a prescription, review it, finish it, print it, and sign it by hand.
That insight helped narrow the scope significantly.
AI-assisted research synthesis
AI played a major role in the research process, but not as a replacement for design judgement.
After customer sessions, I used AI to help structure raw notes, identify repeated themes, compare feedback across practices, and separate genuine workflow needs from isolated feature requests.
This helped me move faster through synthesis while still making the final decisions manually.
AI was particularly useful for:
summarising interview notes
clustering repeated feedback from the 11 sessions
identifying contradictions between practices
turning raw observations into opportunity areas
comparing customer feedback against MVP scope
drafting discussion prompts for product and engineering reviews
keeping track of which prototype changes were based on evidence
The biggest benefit was speed of learning.
AI helped accelerate the research process, but the design decisions still came from customer evidence, product constraints, and clinical risk.
Design Hypothesis
The strongest design hypothesis was:
If prescriptions had their own dedicated workflow inside the patient record, clinicians would feel more confident creating, reviewing, and finding prescriptions without relying on correspondence workarounds.
This led to a few key product principles.
The workflow needed to be:
fast for common prescriptions
structured enough for clinical confidence
simple enough for occasional users
clear about when a prescription becomes locked
practical for paper-first prescribing
flexible enough to support future digital prescribing
Why I built an HTML prototype
Instead of starting with polished Figma screens, I created a working HTML prototype in Cursor.
This was a deliberate choice.
The riskiest part of the project wasn’t the visual design. It was the workflow behaviour.
We needed to test how users moved through the experience, where they expected to start, how they understood prescription states, and whether a common prescription workflow made sense.
A static prototype would have made this harder to evaluate.
The HTML prototype allowed users and stakeholders to interact with a more realistic version of the product, including navigation, filters, editable forms, batch prescriptions, review states, print preview, and settings. It also helped engineering conversations because the prototype behaved more like a product than a presentation.
Prototype coverage
The prototype covered the core prescribing journey:
a dedicated Prescriptions tab
populated and empty prescription list states
a common prescription picker
a blank prescription option
a single prescription form
an “add more” flow
batch prescriptions
review before finishing
locked prescription state
print preview
prescription detail page
common prescription settings
This gave us enough fidelity to test real workflow questions without waiting for engineering build.
Instead of asking users whether they liked an idea, we could watch how they used it.
Exploration & Iteration
The first version of the prototype was intentionally broad.
It explored several possible directions, including more advanced digital prescribing concepts. But testing quickly showed that the most valuable MVP was simpler and more practical.
Several design decisions came directly from research and prototype feedback.
Dedicated Prescriptions area
Users expected prescriptions to live as part of the patient record, not hidden inside correspondence. This led to a dedicated Prescriptions tab with list, search, filters, status, and clear actions.
Common prescriptions first
Many dental prescriptions are repeated patterns. Users responded well to the idea of selecting from common prescriptions, then editing the details before review. This reduced repeated manual entry while keeping clinicians in control.
Paper-first workflow
Rather than trying to solve digital prescribing immediately, the MVP focused on a realistic paper workflow: create, review, finish, print, and hand-sign. This matched current practice behaviour and reduced delivery risk.
Review before finish
Because prescriptions are clinical documents, users needed a clear moment to check details before committing. The review step made the final action feel deliberate.
Locked after finish
Once finished, a prescription could no longer be edited. This created a clearer audit model: if something was wrong, the prescription should be cancelled and recreated rather than silently changed.
Batch prescribing
Testing showed that multiple medications may be created together, especially for pain management or infection scenarios. The prototype included a batch flow so users could add several prescriptions, edit them as cards, and review them together.
Patient context sidebar
Recent medication and recent visit context were kept visible during the form flow. This reduced the need for clinicians to rely on memory or navigate away from the task.
AI-assisted prototyping with Cursor
Cursor allowed me to move much faster than I could with traditional design tools alone.
I used it to create a realistic prototype structure with reusable page patterns, shared styling, patient data, form states, and basic interactions.
This changed the design process in a few ways.
First, I could test flow logic earlier. Instead of drawing one screen at a time, I could build the actual journey and see where it felt too long, too vague, or too fragmented.
Second, I could explore edge cases quickly. Empty states, batch flows, print views, locked states, and settings pages could all be created and adjusted without needing to rebuild an entire Figma prototype.
Third, it made collaboration with engineers easier. The prototype was not production code, but it gave engineers a clearer view of the intended behaviour, hierarchy, and interaction model.
The most useful part was not that AI made the UI faster.
It was that it shortened the distance between an idea and a testable product behaviour.
Collaboration with Engineering
After the prototype had been tested and refined, I worked closely with engineering to translate the flow into a production-ready feature.
This involved clarifying:
which parts of the prototype belonged in MVP
which interactions needed to be simplified for build
how prescription states should work
what should happen after a prescription is finished
how printing and reprinting should be handled
which events needed to be tracked in Mixpanel
which future ideas should remain out of scope
Once the direction was agreed, I moved into high-fidelity design.
High-fidelity Design
The high-fidelity phase focused on translating the tested prototype into Dentally’s design system and production patterns.
Because the structure had already been validated, the high-fidelity work was less about inventing new flows and more about refining the experience for clarity, consistency, and build readiness.
This included:
improving the hierarchy of the prescription list
refining the common prescription picker
simplifying the prescription form layout
designing batch prescription cards
clarifying the review and finish step
refining empty states and settings
designing print preview and prescription detail views
tightening microcopy across actions, hints, warnings, and labels
I also worked through QA-style design reviews during build, checking that the implemented product still matched the intended workflow.
Beta Release
After testing and refinement, engineers built the product and released it as a beta.
It is still early, so we are not claiming long-term impact yet. However, early impressions from beta users and internal teams have been strong.
The dedicated workflow appears easier to understand than the previous correspondence-based approach, and the common prescriptions pattern is showing strong potential for reducing repeated manual entry.
Just as importantly, the team now has a measurable foundation for learning from real usage.
Measurement
To evaluate the beta, we are monitoring key events in Mixpanel.
The goal is to understand where users move smoothly, where they hesitate, and which parts of the workflow create the most value.
Key events include:
prescription flow started
common prescription selected
blank prescription started
add-more flow used
batch prescription created
review step reached
prescription finished
print preview opened
prescription printed
prescription cancelled
drop-off points within the flow
This data will be reviewed alongside qualitative feedback from beta practices.
The next step is to use this evidence to refine the workflow before wider release and inform future prescribing capabilities.
Impact
The biggest impact so far has been reducing product uncertainty.
Before build, the team had a broad problem space with many possible directions. Through lightweight research, AI-assisted synthesis, and a working prototype, we were able to narrow the MVP into something practical, testable, and aligned with real practice behaviour.
The project helped the team:
validate the core workflow before engineering build
avoid over-scoping early e-prescribing features
align product, design, engineering, and clinical stakeholders
give users a clearer dedicated prescribing experience
create a scalable foundation for future prescribing improvements
set up analytics to measure real-world adoption and friction
The product is now in beta, with early positive signals and a clear measurement plan.
Reflection
This project reinforced the value of learning quickly before polishing deeply.
AI helped accelerate the process, but not by replacing research or design judgement. It helped me synthesise feedback faster, explore more workflow options, and create a realistic prototype earlier than would have been possible through static design alone.
The most important design decision was actually one of restraint.
Rather than designing the most advanced prescribing system possible, we focused on the workflow users needed first: create, review, finish, print, and manage prescriptions with confidence.
That restraint made the MVP stronger.
It gave engineers a clearer build path, gave stakeholders confidence in the direction, and gave beta users a workflow that felt immediately understandable.
For me, the project showed that AI is most useful when it helps designers learn faster, not just produce faster.
