To make it easy to illustrate some prototyping concepts, I’ve invented a fictitious Web application that manages feline veterinary office pet medical records. In actuality, this work was drawn from an application designed for records management clerks at one of my former companies. The details and real world parallels and paradigms have been obscured to protect for non-disclosure and confidentiality agreements.
I’ll describe the target audience/user group, some goals that they have, and a few challenges that they encounter. I’ll also describe my strategy and approach to designing interfaces that help them surmount their challenges and accomplish their goals.
The Context for the Product
The primary target audience members for this Web application are veterinary office receptionists. This user group manages the pet records for feline patients and their owners. Their tasks are setting up appointments, tracking changes in charts, updating records, and so on. The database of cat records is shared by a group of different veterinary offices, many of them spread throughout multiple cities and counties.
Not infrequently, cats are entered into the records management system multiple times. This is most often the result of one cat being entered into the database in more than one location – typically when an owner moves residences – by staff working in different offices. One of the challenges faced is accounting for duplicate entries; if vaccination dates and other medical data aren’t transferred over properly, a cat could face a serious problem in getting the appropriate treatment.
Veterinary receptionists need the ability to consolidate records when they find duplicates. The screen below shows the concept for duplicate record comparisons.
When you view this screen, take note of the following features:
The Date of Birth field in the lower right has a ‘plus’ icon. This indicates that this piece of information is contained in Secondary Record A, but NOT in the Primary Record. Clicking the the icon adds that information to the Primary Record.
The push pin in the upper right of the Primary Record. This icon indicates the the Primary Record is being “pinned.” In the pinned state, the Primary Record does not scroll with the page, and the user can re-size it to make more or less room for the Secondary Records visible in the screen space below. The Secondary Records scroll up *through* the Primary Record. The user has the option to view it in the “unpinned” state, as well, in which case the Primary Record would scroll out of view like the rest of the content.
One of the challenges faced when consolidating duplicate records is distinguishing what information is unique to the Secondary Record that is not already on the Primary Record. To address this, the application lets the user hone in on specific lines of the Primary Record and scroll the Secondary Record right up against the former. On top of this, the ‘plus’ icon indicates unique information that’s missing from the Primary. Adding it to the Primary Record is as simple as clicking on the icon. Keeping track of which information has been added to the Primary Record is simple, because the added text is the same color as the ‘plus’ icon, and hovering over the text reveals a tooltip indicating the source record for the data.
An affordance is the design aspect of an object which suggests how the object should be used; a visual clue to its function and use. For example, a door handle affords turning. In Image 1 above, the drop-shadow at the lower edge of the Primary Record panel is intended to at least hint to the user that scrolling content will move up and underneath the Primary Record. Additionally, the pin icon in the upper right of the Primary Record panel communicates a fixed state, or that that portion of the screen is static, and will not move when the user scrolls.
In Image 1 above, note the silhouette of a kitten in the upper-right corner of the beige panel. That image – a small cat batting at butterflies – indicates that the record being viewed is a kitten’s record. The image at left (Image 2) shows a cat that is sitting and NOT playing, indicating in this case that the record is that of an adult cat. This image treatment provides the staff with valuable information, because the care of a kitten is different than that of an adult cat, especially an elderly cat. The kitten image creates a frame through which the user sees and thinks about the patient, allowing her to place that patient within the proper mental context.
Design Considerations for Forms
This application, being a records management system, makes heavy use of forms. As you can see from the screenshot below, I made careful use of typography for the display of static information.
Image 3 shows a set of three form field data points with both labels and values. In order to maximize readability – the measure of how easy it is to read words, phrases, and blocks of copy – and the ease with which information can be distinguished from associated labels, I used a condensed font in a larger size for the values (Roboto Condensed) and a normal, smaller font (Open Sans Regular, all in caps) for the labels. I conducted research with 21 participants and 6 font pairings where only the condensed font was varied. The results: 66% of participants found this font pairing to be the easiest to read. That figure is high, especially considering that there were 6 options to choose from.
At the heart of the veterinary medical records database are its documents. The documents stored for each pet include information about scans (x-rays, ultrasounds, etc.), references to documents from previous veterinary offices, images and cards (Christmas and Thank-you cards, etc.), results of tests, notes taken during visits, and documentation of purchases like prescription foods and supplements. The qualities of the document repository interface that are described below all contribute to a better user experience for office staff and doctors.
The document repository interface that is displayed at left (Image 4) shows a table providing access to a collection of artifacts associated with a pet. The interface is clean and simple, and provides functionality that makes office staff members’ jobs easier. There is functionality to sort by any column, for instance, by clicking on the column header for file type to group like files. The user can filter both the folder structure and the table using the filter fields at the top of each. The office staff members can drag and drop files into and out of folders, and can easily move the folders around in the hierarchy on the left. They can apply tags, export, print and delete one or many files at a time by using the four icons on top of the grid along with the checkboxes to select one or more table rows. They can upload/import using the plus icon at the top, and insert links to large files using the link icon adjacent to the upload icon. Uploading will bring a file in from a different vet’s file system or from a scanner, whereas linking references files that would take up inordinate amounts of local memory if imported fully.
Clicking on ‘Open’ for any particular document will open the document in that file type’s default application. For instance, an image would be opened in the default image viewer, and an x-ray would be opened in the default DICOM viewer.
These capabilities – including sorting and filtering, the ability to execute actions on multiple files simultaneously, manipulate the file structure via drag-and-drop, and quickly view documents in default applications – are all means by which the system can help veterinary office staff members – who are constantly looking for ways to streamline their record-keeping – be more efficient, effective, and satisfied at work.