yWait

The project had a very tight timeline, so we needed to create an MVP as soon as possible so we could start testing the platform with actual users. Since we didn't have user research for the initial build, we leaned on case study research and internal user testing.

There were two user types we needed to consider for this experience. The patient, whose main goal was to book appointments, and the physician admin, whose main goals were putting appointments up for purchase and managing booked appointments. Since the user goals were symbiotic, it was imperative we achieved all user goals. If any one was neglected, the beta would not succeed.

The patient flow was relatively straightforward, but there were more challenges on the physician admin side. Since the application was not integrated with the software that doctors’ offices use to book appointments, admin users had to manually add their appointment slots into the yWait system. The physician admin would need to verify manually if this patient was already in their system, or if they were a new patient. These hurdles had the potential to disrupt the experience, and potentially disable the users’ awareness that their appointment was confirmed.

Our goal was to identify commonalities between the two kinds of user flows in order to accelerate development and create a simplified architecture. To achieve this, we built both flows and analyzed them to identify shared states. We were able to pare the user flows back and make them mirror each other. Since this was a React application, unifying the user states drastically cut down on development time and complexity.

Physician admins primary interactions were manually adding and booking appointments for potential clients. To satisfy this need, we built a calendar component that allowed for them to add and manage their appointments visually. The calendar would provide notifications on their dashboard for new appointments, alerts if the user is a new patient, and a booking system to add appointments for purchase. These appointments would then populate in the patients’ experience when booking an appointment.

Onboarding a new patient can be extremely complex, so we started the patient experience with a series of questions. These questions allowed for different paths to guide users  away from redundant questions while ensuring we were collecting the right data. Allowing users to focus their energy on what was important—finding an appointment that works for them.

We built the brand from the bottom up starting with a series of moodboards. This approach involved using typography, color and found imagery to create a tone for the brand. We workshopped these boards with the client and landed on a board that brought doctor headshots in bold color, large typography of user reviews, and tech-forward imagery. This created a tone for the brand that was both human and innovative. This final board was vital in building out logo, UI, and other design elements for the application and promotional materials.

Once we understood the full ecosystem of the application, we were able to design components that were visually appealing but had rapid development and versatility in mind. Instead of building hi-fidelity prototypes for each of the application’s screens, our team focused on building individual UI components that served as dynamic building blocks. Our team used the CSS framework Bulma to build out the front end components from the design system, so that the application could scale once more features were added.

The best example of this approach were the card types. The cards were designed to be flexible in displaying different kinds of data based on the users’ state. For example, the same card used for an appointment on physician admin side would share the same styles as the patient’s appointment card, but display data catered for each user. This was especially beneficial as our development team used React in building these components, so the data on these cards could be interchanged in real time.