Building Quip Medical
Digital Product Design
Research & Design • Lean UX/UI • Strategy
Startup Founding Journey
October 2023
This case study follows the latest in my product design journey, Quip Medical. It’s an AI-powered enterprise healthcare platform that I built in collaboration with students from uOttawa’s Faculty of Medicine and uWaterloo’s Faculty of Engineering. We created the platform with one vision in mind: to empower healthcare teams to focus on the work that matters.
Between May of 2023 and April of 2024, I worked at Quip part time as the Founding Product Designer, collaborating with our operational and engineering teams to get the gears turning on our MVP launch and bids for early-stage investment. In that time, I led research workshops, built the ecosystem information architecture, conceptualized a product roadmap, developed user research protocols, and created development-ready prototypes. I also owned the development of our brand identity and early promotional materials as we sought to establish ourselves in the market.
Our engineers worked tirelessly over the months to apply this design work to a test-ready alpha release, making use of the latest in AI tech while prioritizing responsible practices and regulatory compliance in the process. At the time of my departure from the company, we had successfully launched our beta program and had begun working with our medical partners to get the software ready for a full release. I look back at my time with Quip fondly, and am excited to share the journey that we went on in my time there.
Scoping the Space
In the early summer months of 2023, I was approached by a friend of mine about a project that she had been scoping out throughout her studies and wanted my input on. She was a Medical student at the University of Ottawa at the time, and she noticed through some of her practical experiences that there was a critical flaw in the clinical system that seemed to be far behind the times – medical notes.
As she put it, most of the preceptors that she was working with seemed to have established incredibly efficient clinical workflows through their time in the field, rotating through patients and pinging off team members like clockwork, day in and day out. It was a marvel to look at and was unique to each Physician that she worked under, but the one thing that always stuck out like a sore thumb was how post-consult administration was handled.
The process went something like this:
1. A patient arrives for a consult with their Doctor
2. The Doctor carries out the consult, reviewing patient health charts simultaneously
3. They take rough in-consult notes as it progresses to try and capture key points
4. The patient leaves their consult, and the next patient is funneled in
5. Hours later, Doctor recollects what they can to condense each consult into a medical note
6. The notes are saved directly in the patient Electronic Medical Record for future use
With minutes in between consults and hours between note-taking, Doctors would have no choice but to rely on their memory and intuition to make sure that the primary artefact from their consults came together.
There’s clearly a problem here, so we got to work on defining it.
Defining our Problem
We started by building a database of research that would inform our early product direction. We gathered articles, research papers, testimonies, and statistics that could help give us additional insight into the pervasiveness of this problem and whether it runs as deep as her anecdotal evidence suggested.
We also interviewed relevant stakeholders within our collective networks to get a deeper feel of the nuances of the problem, and the different points in the clinical workflow that it may impact. We ended up holding semi-structured interviews with 4 Doctors and 2 Medical Scribes.
With a diverse body of research to lean on, qualitative and quantitative, our next step was an affinity mapping workshop to help us hone in on what our users were experiencing in their current state journey. We took 10 minutes to asynchronously jot down as many insights that we had gathered from our research as we could. The priority in these 10 minutes was quantity over quality. We then spent the next hour and a half discussing key insights, clustering them by theme, and determining scope priorities.
To codify the priorities we determined, we came up with 6 needs statements from the perspectives of our users. They were as follows:
Understanding our Market
With a UXR base established for the product, we also needed to understand the market that we were to be tackling in order to build an implementation strategy. We already knew that healthcare was our industry of choice, and admittedly, we had already biased our solution to make some use of Artificial Intelligence. This meant that there were two main dimensions that we needed to understand about the space we were entering: Healthcare & Technology.
This is a simple breakdown that we used to identify major players in the space, learn about the roles that they play, and determine how we can differentiate our value proposition.
Here’s a map that illustrates some notable competition on our radar:
Fortunately, some of these players were directly accessible to us through our networks, giving us the opportunity to learn directly from them. In an effort to keep our approach as grassroots as possible, we set up calls with Doctors that were either founders of or involved in some of the ventures we identified, picking their brains about the experiences they’ve had and what to expect for our product pipeline. These were valuable mentorship opportunities for us, giving us our first focused look into the world of regulatory compliance when dealing with health tech. This includes HIPAA & PIPEDA Compliance, basic security standards, and the nuances of an academic vs industry approach to development.
From our market analysis, we had a few key takeaways:
The market for AI in Healthcare is underserved, but tech giants are rapidly approaching
Established players in the space are yet to adapt to a post-LLM Artificial Intelligence world
There are layers of bureaucracy at every turn, many of which we’ve yet to uncover
Existing solutions to our problem, agnostic of tech-forwardness, are expensive
In order to effectively penetrate the market at a resource capacity that is realistic to our current size and potential growth, we needed to have a differentiation strategy that addressed these hurdles. And so, we decided that the path we needed to take was one that did the following:
Prioritizes Product Affordability
giving a cost-effective solution to the users that can’t afford the premium alternatives at present or future
Starts with Specialized Segments
choosing an underserved and generalizable segment to develop competencies and adopt a backdoor growth strategy
Emphasizes Technological safety
taking a grassroots approach to development and positioning it as the safe & responsible choice compared to competitors
Scoping Features & Architecture
With a deeper understanding of the market on hand, our next step was to take our project from problem to solution. We held a second workshop where, guided by our 6 needs statements, we came up with features that our proposed solution may need. We took a similar approach to the last session, but this time with the benefit of thorough needs statements and asynchronous analysis on our side. Quantity was less of a priority at this point.
This helped us build a base set of features that we were to consider for our product, and on top of that, some additional topics that we needed to explore with our users to guide how we approach the features.
From this and our competitive analysis, it also became clear that an ecosystem approach was going to be necessary if we were to see any sort of adoption within our user base. This was a user base that is averse to the introduction of new technologies as it is, meaning that the introduction of any unfamiliar hardware or software was likely to create more friction. So, our priority was to embed our product solution into an ecosystem of software and hardware that they would already be familiar with within their clinic.
What did this mean practically? This meant creating a push and pull relationship with the Electronic Health Record (EHR) system that all other patient data was stored within, making use of microphones ready on their smartphones, and optimizing mobile app workflows so that minimal time is spent on "new" interfaces.
I built a preliminary Information Architecture that embodied all of these takeaways in a way that is robust and can be divided into product phases. This architecture mapped out the different entities that would be at play within our product, and broke down how the mobile and desktop user flows would look like. These were all done visually using Miro, and and were used to inform both priority screens and our future ERD development.
This is what they looked like -
Prioritizing AI Responsibility
A central consideration of the work that I was doing at this stage was building the foundations for responsible AI use.
I had just come off the heels of a freelance project with another startup where I saw what the irresponsible adoption of AI – in healthcare especially – looked like in practice. Enamored by the wonders of ChatGPT, this client abandoned his workforce of medical contractors (and in the process all data safety practices that may have justified his product strategy) in order to build a GPT clone that would give new parents medical advice about their young children. Of course, this initiative had no involvement of medical professionals at any stage, avoided addressing the shortcomings of LLMs in a non-generative context, did not involve any model evaluation ahead of release, and skirted all of its problems by including a “This is not medical advice” disclaimer beside it.
As you may imagine, working on that project allowed me to come into this one with a skeptic eye and a healthy dose of what not to do. The term of that project also coincided with data ethics research that I was working on as part of my Master’s degree, allowing me to ground my academic findings in a practical context. And so, there were a few commitments that we made early on as a team to avoid unintended outcomes.
Avoid the integration of proprietary models for summarization at all costs, no matter how bulletproof they may look.
Involve our target users (primarily Doctors) at every stage of development, scaling their involvement as the project scales.
Assess and address potential sources of bias at every stage of input, processing, output, and use.
Test, test, test
The stakes are high in healthcare settings, making the responsible use of AI critical to both social safety and user uptake. We can move as fast as we need to when creating our proof of concept, but as soon as real people are involved, there is no way forward without getting it absolutely perfect. This means high model precision AND accuracy.
With my technical background not extending far beyond low-stakes and research-centric contexts, it was time to look outward. We recruited a Biomedical Engineer & Data Scientist from uWaterloo to begin taking our requirements from concept to model, embodying the values we laid out through and through. At this stage, our two-person operation grew by one, and we were ready to prototype.
Prototyping
There were two faces to our prototyping phase – of the model and the platform. While I continued to be involved in the model development acutely through brainstorming and general consultation, my team members owned most of the process. I took the reins on building the platform itself, starting with the mobile version, which is where the primary user processes were to take place.
Using the Information Architecture I had already put together as a baseline, I started with lo-fidelity sketches to begin riffing on the layouts and information that would need to exist on each page. I then pulled together a moodboard of design motifs and competitor interfaces to help me take the sketches to a medium fidelity wireframe.
This is what some of it looked like -
We got together as a team for a group critique session grounded in user insights, technical limitations, and design heuristics. From this, I went back to the drawing board to take my screens from wireframe to hi-fi mockup. I drew 5 main insights that, in tandem with our needs statements, I used as guiding motifs for the MVP:
Users will need affordances to get their bearings and organize their daily workflows
User flows will need to be simple & guided to keep app use passive & ambient
Users will need to have reliable contingencies and in-app error handling processes
Users will need to be funneled to desktop for any active or terminal workflows
Different members of a team will need to be able to use different feature subsets
To refine the aesthetics, I started by looking at the repeatable UI components across my wireframes and understanding the information hierarchy on each screen. From this, I created a design system of repeatable components and colors that I drew from to make a consistent user interface. I kept the color system relatively simple for our MVP so that we could avoid getting bogged down on micro-interactions and brand nuances. I then made sure that OS constraints, mobile development standards, and visual accessibility requirements were in check before putting finishing touches for dev handoff.
At this stage, our three-person team grew to four! We onboarded our first Software Engineer to get the gears spinning on our priority screens and backend development. To help facilitate this process and ensure no interactions were lost in translation, I added functional markdowns to the mockup screens and put together some preliminary user stories.
You can see a few of them here:
We’ve since gotten to work on updating our MVP baseline based on feedback from our usability tests, more time to refine the UI, and new constraints that we identify moving through the process. Our new screens trim the fat on what we determined to be non-critical features, simplify some of the more complex elements of our solution architecture, and now feature a dark mode for users looking for something a little easier on the eyes. This also involves the design of our web app, optimized for desktop use and all its associated user journey differences.
While still a work in progress, you can see a preview of what we’re working with here:
Creating a Brand Identity
In parallel with prototyping, it also came time to legitimize our product with the creation of a brand identity.
The first step was the name. We got together to brainstorm a set of name ideas, prompting ourselves by riffing on different characteristics of the product we were building and what some of our competitor approaches looked like. With the “- scribe” suffix being an overdone trope among our competition, and the goal of our app to move beyond the mental model of the traditional scribe role, we knew that we needed to ground our name in something that looked beyond modern times while sounding both approachable and familiar.
In the end, we landed on the name Quip Medical, or just Quip for short.
Our rationale for the name is as follows -
“Quip Medical draws inspiration from the Quipu devices of the ancient Incas while appealing to how critical patient information can often be buried in small pockets of conversation in a medical consult. Quip Medical helps physicians identify these buried pockets in context and streamline their administrative work - minutes, hours, or even days after they take place.”
With a name and design rationale in place, I then needed to create a robust logo set that we could use as the backbone of our identity. I knew that these logos needed to be a combined representation of our name, our industry, the tech paradigm we were riding on, the seamlessness of our product workflow, and the value that it brings to the lives of physicians. I put together a few preliminary sketches that encapsulated these values -
And after many rounds of revisions, these were the primary designs I landed on:
And here is the full logotype set:
This was not all on the brand identity front, however, as we still needed customer-facing promotional materials to generate leads and gauge consumer traction.
To do this, I built a website landing page that provides a high-level summary of our product and its potential for impact on users. Getting an MVP for the website was determined to be a priority ahead of our alpha release, so I spent a few days distilling what we had and creating a design that I could implement on my own. I put together some visual assets that would supplement this design as well.
I built and launched the site using the Squarespace CMS Fluid Engine - in the process prioritizing accessibility, screen size responsiveness, and clean CSS to keep it scalable. Since putting together the initial MVP build, I’ve refreshed our brand colors, assets, and logo set (as represented above), so a newly polished version of the site is currently in the works and slated for launch in Q4 2023. We’ve launched! You can find the new and improved live website through the below link.
Where we’re at: From Concept to Product
And that brings us to where we’re at (as of October of 2023). Our humble team of two has now tripled, of which there is myself (Product Designer), our Operational Director, our ML Engineer, and our three Software Engineers. We’ve deployed the alpha release of our mobile app and are actively conducting usability tests with potential users – some we spoke to early in the process, and some brand new. We’ve also been working on fleshing out our go-to-market strategy while pitching to prospective investors. Here’s the a pitch deck we put together for reference.
As far as next steps go for the product, we’ve been working on maturing our capabilities to prepare it for a beta release. For me, this means reworking the mockups to leverage our refreshed brand identity and user feedback, building desktop mockups within the constraints of our EHR integration strategy, and creating a 2.0 version of the website that reflects these changes. I’m working with a very talented group to get this project on its feet, and I’m excited to see what the future holds for it.
