Designed with care in mind
Our Role
Product Strategy Design Leadership Product Design UX / UI / Visual Design User Research Prototyping
Platform
Web
Project Phases
Concept Development Design Development Prototyping Pilot / MVP Ongoing Optimisation
The Design Brief
Careteam is a care coordination platform based around the creation and management of integrated patient care plans. The goal is to provide a single place for the patient, caregivers and the entire healthcare team to have a real-time, 360 degree view of the patient’s care plan including who is on the team, upcoming appointments, and the instructions needed for a person’s care from home to hospital to community. The app was in its early states and required a UX audit, redesign and a comprehensive design strategy for the future phases of development.Our Role
Codename was brought on board to audit the early-stage application, identify usability user experience issues and develop a vision for what the application could be moving forward. In other words we provided the product leadership that included strategy, ux design and visual design and then we took on the project management role to oversee the team to execute the vision.The Design Challenge
We focused initially on two main challenges that grew from the same root cause.A “kitchen sink” app
This was an early stage product that had been largely feature driven. That means that the growth of the application was based on “adding on” features as opposed to having a holistic view of the user experience. This is fairly typical in engineering lead projects where there are a complex set of features required to differentiate from the competition. In this case “doing it all” was a key meta-feature. We needed to bring a new perspective to the process to simplify the layers of features.Different users with very different needs
By their nature medical applications that are user-facing for both practitioners and patients have users working in very different contexts, and the users have very different levels of understanding of the information. The application as we found it treated the display of the information the same for both practitioners (who have a professional level of understanding of the information) and the patients (who have varying levels of understanding, and have emotional reactions to the very personal and life-changing nature of the content).
Working With Product Design Horizons
Startup projects require product leaders to work on multiple horizons: what has to be done now, what’s next and what has to be true for the long-term vision to become a reality. Ideally they all align, and the execution of the horizons is sequential.
In the case where you are working with startups that are feature driven (where crunching through a backlog of features is the main measured metric), there is a tendency to focus only on the first horizon. Our challenge was working with the engineers to “change the tires while driving on the highway” and still design for a future state that better positions the product for the future. We needed to split our focus between shipping features and redesigning the application to fix some of the fundamental underlying issues, and then move towards a more user-centred design approach on a structural level.
Visual Design Improvement as a First Step
Our first step was to make visual improvements to take the current layouts and make them more readable. Even if we weren’t addressing the underlying issues we could improve the experience through creating a new style guide and implementing some basic design concepts. We focused on two main things: spacing and hierarchy.
Providing enough space around content supersedes any worries about scroll depth. Things that belong together are grouped together with enough space between groups of objects to make clear zones of similar content or functionality.
We made changes to improve the visual hierarchy in terms of font size, weight and colour to make it easier to scan for primary elements. We reduced the number of secondary elements and suppressed less important content to tertiary or body elements.
Things that needed to be addressed
Issues with the navigation: including the inconsistency of the main navigation a lack of sub-navigation;
Poor visual contrast: including poor font selection and spacing, a lack of visual prioritisation and a lack of colour variations.
Inconsistency of user actions: including a mix of interface patterns that behaved in unexpected ways and duplicate actions that performed the same task (an example was adding content to an action plan was done in multiple ways);
Inconsistency of data display: including content and navigation elements place in areas not typically expected or the same content rendered differently in different contexts so as to be unrecognisable from one context to the next;
Over-segregation of functionality and content: this forces users to go to a very specific, hard to find place to complete an action / task or locate a specific document;
Duplication of data and content: there were different screens that presented essentially the same content, which made it hard for users to remember where content was to be found.
User-Centred Health Care Application Design
We applied several more principles to focus the application development on the user experience side. Here are some things we considered:Simplicity
The primary personality we want to instil in the app is technical and visual simplicity. That means removing extra bounding boxes, layers, shadows that divert attention from the content.
Patterns
The navigation, page layout and interactions should all be based on existing, well established patterns. Deviating from those patterns can be done only with good reason and only if applied consistently throughout the application.
Consistency and Modularity
We will rebuild the front end using the concept of “Atomic Design” to allow components to be reused consistently across the application.
Error Avoidance
The best way to deal with errors is to avoid them. We will focus on avoiding errors before they occur with good instructions, clear expectations for the user.
Disaster Avoidance
Any action that is unrecoverable requires a confirmation check to execute the action. For example “Are you sure you want to delete X? This action cannot be undone.”
Managing Empty States
Empty states should be clearly communicated when they can’t be hidden. In the case where empty states require user action, a clear prompt to that action and the ability to perform the task are required.
Breaking The Feature Driven Product Process
As noted above the risk in a feature driven approach is a piling on of features without a holistic view. You end up with kitchen sink applications that do a lot if the user can find their way to them.
Many of the issues discovered in the initial audit were caused by generations of versions of the application through its initial stages In this case there were many layered deficiencies in the application that make it difficult to use including some deep issues. This means they were not issues that existed on a single screen, but consistent issues in the way screens were arranged, connected to each other and flowed.Because this kind of problem is hard to isolate it requires a holistic view of the application, the contexts of use, and the humans that use the application.
Rob
Careteam