The HH OASIS Mobile is an On-the-Go Reference for Home Health Field Clinicians
HH OASIS Mobile App is a companion tool to Decision Health's Home Health Coding Center SaaS tool.
I was responsible for creating a mobile user interface for iOS and Android with reference to high level requirements documentation. I also created further assets and branding material for the length of the project.
UI, UX, Mobile App Branding, Email Design, Landing Page Design
Sketch, Symplii, Invision, Illustrator
Pre-Production Customer Feedback,
Live Customer Alpha Testing, Invision
The HH OASIS mobile app was intended to meet the needs of nurses on the go. Specifically, Home Health nurses that are required to submit reports measuring home health care quality. What is an OASIS code? Well, to put it better than I can:
"The instrument/data collection tool used to collect and report performance data by home health agencies is called the Outcome and Assessment Information Set (OASIS)."
- https://www.cms.gov/Medicare/Quality-Initiatives-Patient-Assessment-Instruments/HomeHealthQualityInits/index.html
Since the data set these nurses are collecting is used to measure the quality of patient care, to fulfill insurance reimbursement, and to ensure many other Medicare/Medicaid standards, the information itself was important for the nurses to be accurate with. However, the M-Items themselves can be quite complex, and contain extremely similar codes, with the most subtle of differences.
This sort of complexity begged the need of a way for nurses to reference something more than a guidebook, or even more than clunky, outdated (quite literally without new code updates) websites.
Decision Health's team did a LARGE amount of work preparing scope and high level documentation very early on in the project, way before I was brought on to help. The purpose of their original documentation was to seek approval from stakeholders, while also outlining the necessary steps, estimated budget, and time frame for the project moving forward.
Once the project was approved, further documentation was created to describe each screen as well as the current user flow for the website. Since they currently had a web-based tool available to 4,375 users, they had a significant brand-standard that their users were familiar with, as well as an expected experience while using the product.
Using all the information available, we had had a launching point for me to get involved at. I poured through the entirety of the documentation and met with the team to describe the project, walk through interactions, and to talk through potential problems that I could see us running into, especially since the information we were presenting was so dense.
A significant amount of the beginning stages of user testing for this project was completed by the Decision Health team itself, and was subsequently included within the documentation for the project. With the given feedback (and data from analytics), we were able to come to quite a few conclusions for our current users. Some of the initial points made made it easy to develop our User Stories:
I need to access specific codes, and see their details.
I want to access information quickly.
I want to use one hand when accessing information.
I want to search from every page.
I want to see neighboring codes, because they are related.
I've always enjoyed the symbolism of the skeleton for wireframing. There's something about it that speaks to the rigid, structural, and clean aesthetic of a fresh wireframe.
With these user stories in mind, as well as heavy documentation for how the web app functioned (and how the mobile app should "ideally" function), I was able to lay out basic wireframes. In most cases, the wireframes allow the team to discuss possibilities, user flows, interactions, and features, all without being distracted by design elements. So I created wireframes of the basic pillar pages before moving forward with many details.
The Decision Health team was fortunate enough to have a small handful of volunteers that were current customers and quite familiar with the web experience. Using this small group, and understanding going in that it would be a very small sample size, we made use of the opportunity to get as much feedback as we could.
I made 2 clickable prototypes using InVision's prototyping software, and linked up a few intended pathways through the app. The users were given a way to access both versions, with alternative navigations and home page layouts, so that we could gauge what versions were easier to read and more convenient to navigate.
The team as a whole, helped developed a list of a few simple questions for the user to be asked after using the prototype of the app. They were:
"Which home screen feels more comfortable to use?"
"How would you get to guidance for M1860?"
"What does Browse and Favorites mean to you?"
"How would you get from M1860 to M1870?"
"Which navigation format feels more comfortable to use?"
So after our second round of testing (in this case, our Alpha Testing phase), we received significant feedback from observing several users work through the app with a fixed questionnaire. Among the general feedback that the app absolutely would be useful for them in the field, we received some common issues:
• Screen feels very small to read a lot of text on
• Top and bottom navigation needed more emphasis
• Overall navigation is slightly confusing
After the Alpha Test, we had to actually create actionable solutions to the problems the users presented us. Luckily, the issues from testing were already the same issues we had on our radar, mostly, navigation woes.
We still found it somewhat necessary to be able to quickly navigate in several ways throughout the app, but we were very hesitant to implement actions such as swipes and sliding menus without a way to inform the user intelligently. The Mitems were especially requested from users to be able to swipe between, since they tended to use a few similar ones in a row. This, being information we didn't understand before, was certainly something we added as small header bar up top.
With every new product, comes a product launch! Or in this case, a launch to acquire new users from the added functionality we're bringing to the previously available product, and a launch to excite current users with new features!
Sometimes, in order to figure out if your marketing campaigns are working, the easiest way to gather fresh, unadulterated data is to create a fresh, new place for users to land!
Enter: The Landing Page.
With direction from Marketing, Sales, and Editorial, I was responsible for designing a simple, 1-page website for new (and probably old too) users to land from a few different sources. The intention was to bring them in from an email campaign, banner ad campaigns, and cross-product marketing attempts.
Ideally, then the user lands on this page, we're pushing the CTA (Call-To-Action) to be signing up for a demo, or buying the product. The implementation doesn't quite do the original design justice, but at least there's an opportunity for users to land somewhere specific, on-brand, and comfortable, allowing them to make whatever decision they'd like with confidence.
Marketing was interested in forming an email campaign to hype the launch of the app to all of the web users, as well as any past users that may have lapsed. I was tasked with mocking up some simple designs with copy I was provided.
Essentials to Success:
• Get the user's attention quick
• Quick/relatable content
• 1
• Subtle branding
• Above the fold matters!
Lessons Learned:
• Build simple designs
• Everything is basically a box
• Images are a LUXURY
• Most people won't even scroll
Currently, it's hard to say.
I have my own reservations about what still could be done to improve the product. But it's extremely important not to add features and content to a product just hoping it gets better. Without substantial research, feedback, or really data of any kind, adding features doesn't do much other than waste precious design and development time while taking shots in the dark.
We still haven't had enough time to accumulate significant data on the project, especially since we did a launch on iOS, followed by an Android launch some time later. However, given a bit more time we should be able to see a healthy amount of analytics from the Email/Banner Ad campaigns, Landing Page, and the Apple and Google Play Store listings. Using that information, I believe we can create a strong post-mortem document describing the attempts made and the failures or successes of the mobile app launch.
We are due for a round of feedback from users soon, and should be able to get a proper understanding of how useful the app is in the real world, what we can can do to fix bugs, and what tweaks would make the experience even more enjoyable, and overall, more useful.
The best lesson to be learned from this app?
Pre-Project documentation makes the process 100x smoother and...
Healthcare apps with large databases don't have to be a scary endeavor!