whitekoat
whitekoat
whitekoat is a startup founded in Sacramento where I worked from 2014-2016. I was the sole designer in a team of 11 people, and as such, I had to wear many hats. I did the research, user experience, interface, branding, internal materials, and some content creation for the site itself.
Before I joined, whitekoat was a medical image library and quizzing platform. However, we soon pivoted into comprehensive medical library and quizzing platform, primarily aimed at medical students.
Our strategy was to use our proximity and connections to the UC Davis Medical School to establish ourselves as an academic tool for both professors and students.
Original whitekoat
The original version of whitekoat Images was solely focused on medical images and annotating medical images. Development was halted, but the core values would still be seen and kept in the images portion of the next iteration of whitekoat.
- The image itself needs to be large, as the important parts of the image would often be small details in often very repetitive surroundings.
- Image annotation had to be quick and easy. "Pixeltags" were our way of allowing users to visually annotate the image and was the major feature of Images.
whitekoat Quizmode was in its early stages when we pivoted to a more generalized medical tool, but the structure of questions grouped into quizzes was the backbone of the new card system.
Goals for the New whitekoat
Because of the extreme variety of information, we wanted whitekoat to be extremely modular. Keeping with the academic and our CEO's own experience in medical school, we wanted to use flashcards as our visual representation of information.
Cards could be separated into types, based on what kind of information they held, such as text, images, videos, and questions. They then could be made into decks in order for users to organize their cards into study devices
Our goal was to mimic flashcards which were used by the majority of the medical students we worked with, but with the advantages of a digital platform.
Much of the product was built purposely to look as simple and low maintenance as possible. We were constantly working with current medical students and medical professionals, which meant there was zero room for any part of the site crashing or not responding. In addition, we would often have to add or change features requested by doctors and students, so having a basic framework meant we could move fast when implementing updates.
The Pocket
In the whitekoat environment, all the cards a user had saved or created would be saved in their Pocket.
The pocket acted as a home page, where a user could access the cards and decks they've created and saved. From here, users could search the site for content created by others to put into their own pocket to use later.
Card Creation
The card creator was the most difficult to design, as the number of modular pieces within the cards would increase with each type of card added to the whitekoat library. Again, all of the pieces within the cards are modular as well, in order to allow users the maximum amount of freedom when creating cards.
The multiple choice question builder was the most extensive, as both questions and individual answers could have multiple forms of media in them. However, this meant that each question and answer could be created just like an individual card, just with a few modifiers for answer choices.
An empty creation form for a Multiple Choice card.
A completed creation form for a Multiple Choice card.
Deck Interactions
Going through a deck was one of the core experiences a user would go through many times. From multiple rounds of user testing with the medical students, we found that the most minimal interface was the one that performed best. Presenting just the card itself created the focused environment they needed when going through their decks, whether just to review cards or when doing full quizzes.
Groups and Clinics
After creating a system in which users can create and share cards with one another, the next step we took was to implement groups. Groups were basically a shared Pocket for any number of people with shared permissions. The early version I worked on was extremely bare bones and was literally a pocket with an administrator page.
Content shared between members of ENDO 221
Administrator view for the settings page of the group. Functionality is limited to membership and content submission approval.
These group pages came in line with partnerships with several small clinics who agreed to use our product as a patient engagement/education tool in the waiting room. The clinics however, required more stringent permissions guidelines in order to make sure they had full control of what patients were able to see.
Controls were added for the administrator and member screens of the Contents tab and a new user type was created that was "read only" for patients to use in the waiting room.
Onboarding
Onboarding process for clinics and practitioners
Onboarding process for patients and students
