Cure Web App - Case Study
Provider Services (now Foundations Health Solutions) came to Aztek with the request of updating their long-term care management app.
Clients proprietary software called Cure is supposed to fulfill assignments specific for their business, and that is managing long-term healthcare facilities/buildings, patients and their insurance information. First iteration of the application was build in .NET with Bootstrap 3 as the front-end framework. We were supposed to follow that pattern in the redesign.
a) 2 types of active meetings, Daily and Weekly, with their own subcategories (depending on type of the user/patient)
b) 4 types of users: Super admin, IT admin, System admin and Basic (Core) user
c) Archived meetings as a special sub-group
In the everyday use, Core user is going to use the app the most. That is the user we focused the most attention when redesigning the app. In their everyday work core users are going to be focused on these areas:
• Is the patient assigned to one or more buildings
• View payer insurance info for their assigned buildings
• Manage patients for their assigned buildings
• Review residents for their assigned buildings
• Begin, view and edit meetings
As a Lead Designer and Front-end developer I designed components for:
• Daily and Weekly meeting pages
The first iteration of Cure application was built using Bootstrap 3 as a front end framework with about 1500 lines of custom styles. LESS was used as a preprocessor of choice. There was no style guide to follow, only business requirements.
Goals put in front of design were:
1.) Every type of the user currently logged in should have access to every part of the application from the dashboard, but the daily and weekly meeting sections should stand out the most and take up most of the screen.
2.) End user should be able to start daily or weekly meeting straight from the home dashboard. They should be able to pick a type of the meeting, building or choose current/meeting in progress if any. All actions should happen in 1 or 2 clicks.
3.) Action items related to the specific meeting should be easy to understand and interact. Since there are many different subsections, form fields and controls, it should be clear which fields and controls go together. Also there were some special requests about style of the check-boxes, fields and buttons.
Requirements put in front of front-end development were:
• Keep Bootstrap 3 as the underlying framework
• Convert LESS to SCSS
• Create a style guide made out of components that can be used throughout the app as needed
• Create custom form fields, controls and interactions
• All components and interactions should be IE friendly
Focusing on our core user, we kept division of the dashboard into the 3 main sections. To accommodate the aforementioned requests for visual clarity, we used a combination of background colors, typography and horizontal dividers to visually separate different groups. The first design iterations were heavy on interactions. Elements that were hidden would show as users would request them, which resulted in a clear, somewhat fancy dashboard. It also forced, however, our users to “work”, to dig inside the app to get things done, and it had some learning curve to it. Since application already had a depth and complexity as is, we decided to ditch that approach and create, maybe not as beautiful but ultimately functional dashboard.
Final result was the dashboard where user had mostly direct access to all types of meetings immediately from the home page. We made as many features as possible visible from the moment app would load. There was only one interaction that demanded 5 clicks: choosing an archived meeting on a specific date in a specific building. All other interactions took 1 to 3 clicks to start.
Navigation, the section that is going to be used by all 4 types of users, but not as often as meetings sections, was moved to the far left. We separated it visually with the dark blue color, and that layout is persistent throughout the app. It’s position is fixed and the icons are organized by the sequence of importance. We determined the importance by the number of users that are going to use the action button.
Sub-menus, notes, settings and other options on the buttons that are not links were handled by the Bootstrap ‘toggle’ events, which was a downgrade from the ‘on/off canvas’ transitions we developed first.
Custom components and microinteractions
...were a specific part of this project and a part I enjoyed working on the most. Client had a remark that users would overlook questions and form controls, such as check-boxes and radio buttons. One of the main requests was to make them stand out.
On the pages mostly filled with form fields and buttons it was easy to miss the less important ones, so missing some of them came to us as no surprise. Following client’s requests we came with a couple of different solutions. In the example below, we broke the form with the large headers containing check-boxes related with the switch labels, everything wrapped inside cards. If the patient is going to the physical therapy, clicking on the big switch label, changes the color of the label, message and color of the header. Check-boxes themselves are also stylized and hard to miss.
Once the daily or weekly meeting have been selected, we had to make two important choices: “How to make different subcategories of meetings accessible from their landing pages?” and also, “How to incorporate the different action items specific for type of the meeting on the page”.
As an answer on the first question, we decided to use tabs to switch between meeting subcategories. Since maximus number of tabs never exceed 5, solution worked well on the smaller screens as well.
With the action items, we kept the same general feel and functionality of the main navigation. The most important action was displayed first. All related parts of the application, such as patient listings, or option to add a patient or a meeting note, were accessible from here, but hidden behind the event. Idea was to encourage the user to finish working on a single patient at the time, to fill all mandatory fields and when all necessary data is in, to naturally continue to the next section of the meeting or to the next patient. Interactions used here were mostly made as a series of Bootstrap drop-downs, modals and pop-ups.
A fun project to work on, Cure became an application designed and built according to the client’s wishes. Initial feedback from the project owner and the very users was great, both functionality and design wise, and that is only thing that matters at the end of the day. In the retrospective I wish I have done some things differently: creating even more detailed, component based style guide with all possible feature combinations, being one of them. Or, creating my own icon set, set up as a svg sprite, being another.