PROBLEM AND SOLUTION
After ideating, these wireframes came to represent the mPOWEr user's primary motivations.
shows a photo or photos of the current patient's wound, statistics on how they feel (like temperature, number of days since surgery, etc), and their survey results (or how they recorded their pain).
shows graphical data overtime on each trait of their wound's healing and development.
Critique on Initial Wireframes
These wireframes created the scaffolding necessary for creating the visual language and the eventual deliverable. The toggle button at the top allows the user to easily click between their photos and their survey, while still remaining entirely scalable.
I wanted the app to feel friendly and calm, as the internal material isn't so friendly, and felt that the current yellow-green doesn't totally represent that. Instead, I use a light blue-green accent throughout.
In order for the application to feel easy to use and familiar, I decided to use some of the UI and typefaces already associated with iOS applications (like the on/off switch at the top).
FAMILIAR UI PIECES
Here are the primary screens necessary (in the original ideated goals) for getting access to their wound photos, getting access to their survey results, and emailing/contacting their healthcare practioner. Check out the video at the top of the page for a full walkthrough.
mPOWEr is a mobile post-operative wound evaluator; a patient-centered app for tracking surgical wounds at home. During the summer of 2015, I worked at the UW-led research project and in the winter of 2016, worked in a class project to iterate on the existing application.
The mobile post-operative wound evaluator has an existing application, but the user is forced to make too many decisions, coupled with those decisions not being immediately intuitive (like language that is only familiar to healthcare practitioners). The end-to-end flow has too many steps, and the homepage is a menu, rather than your most current results- something most users would want.
A revised application that allows users to rate their surgical pain and symptoms on a scale that feels contextual to their experiences, with a short end-to-end flow that feels visually familiar.
In the ideation phase, it became clear that the patient, or the primary user, has a few actions necessary for their ultimate goals. These actions are getting access to their wound photos, getting access to their survey results, and emailing/contacting their healthcare practioner.
With these goals, I then decided the application show a few traits within these actions:
- familiarity (no jargon, no unfamiliar visuals)
gives the user the ability to sort through data on previous days. This screen would be accessible via the hamburger menu in the top right corner of the homepage.
gives the user the ability to contact their doctor in the case that the wound becomes progressively more infected. This screen would be accessible via the mail button in the top left corner of the homepage.
After the first round of wireframes, it was clear that my solution still was not solving some of the major problems.
In talking with a few peers, I realized that the homepage should have fewer options- it should be immediately obvious how the patient is doing that day.
Similarly, I realized how the Overtime screen was ultimately unnecessary, as the patient actually using the application would have no real understanding of what exactly the graph(s) suggested.
After the visual design phase was completed, I used Origami within Quartz Composer to make the UI walkthrough seen in the top video.