Canceled Visits and Open Appointments
POC Compliance Automation
Front Office Workflow Improvement
Two-Factor Authentication Without Account Creation
Enhanced Scheduling Platform
Dashboard Information Gaps
Non-Compliance with WCAG 2.2 AA Standards
Inconsistent Branding
Inconsistent use of brand colors, layouts, and visuals across the CRM platform undermines brand identity. Standardization is required for a cohesive visual experience.
3 months
Once I have the workflows through discovery, research, and testing, I generally start “designing” what a proof of concept or final product will actually look and feel like. Color, typography, shapes, and motion are all part of my toolbox, but they mean nothing without the infrastructure of understanding.
Every organization is a little different. I worked on well-established products at a large company that require many stakeholders to be involved in the strategy and rollout of a feature or product. I worked at agencies where we built something from nothing and there were far less people involved.
I work with product, engineering, and beta testers to make critical decisions about operational workflows in a physical therapy center.
We had a hypothesis that efficiencies and speed could be built in the way current EMR software operates.
Next, we took a holistic look at the sticker sheet of design patterns and those patterns eventually started to become a “design system. The purpose of this was to have reusable parts that support the brand visually, the users’ experience, product’s function, and designers’/engineers’ efficiency.
At Prompt, UX writes most of the tickets (documented visual, logic, and functionality that engineering builds into the product). Our product teams work in an AGILE environment.
Mapped out the states a patient’s visit can exist in from start to end to work with engineering on the business logic associated with each state.
One of the x-factors while creating PoC was to reduce discrepancies between design & dev by exposing a set of synchronous APIs on both, so a API on Figma translates exactly into a React prop for a developer to consume thereby reducing any possibility of friction.
This process starts with creating an extensive list the all the variants and props that can be given to users. Post these there are internal discussions with developers and designers to decide which props should be exposed and which should not be exposed.
Based on the insights gained from the audit and research, a proof of concept of the component is created. At this stage, the focus is less on the visuals (how the component looks) and more on the functioning (how the component is structured)
This discussion gives the developers a brief overview of how the component is structured and what props are available for the component. On the design side, it helps to understand the tech feasibility or considerations that need to be taken into account, edge cases of the component that might have been missed, and receive quick feedback on the designs.
Once the component structure and API decisions are locked, the base component is created.
Enter copay, coinsurance, and any relevant notes to setup and capture payment for current and upcoming visits.
Comment in multiple areas of the component, tag colleagues, and resolve tasks.
This is owner facing component for located in dashboard thats ultra specific on metrics tracking things like provider capacity, revenue, units per claim, insurances that pay the most, and referring providers.
For usability testing I made a clickable prototype. This allowed users to navigate through tasks.
We receive feedback in early phases of design but images/wireframes or even clickable prototypes are rarely exactly the same experience as a user will have in the actual product under real-life work conditions.
UXR analytics shows
The important part is deciding what these metrics should be so we constantly drive towards a better experience for our users.
The insights gained from this research helps to understand:
The next step is documentation. All the components are intensively documented. The component documentation consists of the following: