I-Care Platform
Lead Product Designer.Val Mercenaro
Lead Developer.Andrea Carta
Software Engineer.Andrea Introini
Developer.Benito Massidda
.Introduction
Platform with proprietary algorithms for the creation of “wellbeing dashboards” for the end customer
To date about thirty checkups can be performed and it is integrated with a high number of devices interfaced thanks to IOT.
I-Care is the SAAS linked to Prevention Suite, the suite of integrated solutions combining hardware and software, scientific expertise, human resource management and logistics, designed around the needs of Life Science professionals working in the field of prevention, health and personal well-being.
My role
Lead product designer responsible for redesign, UX and content strategy
– I-Care SAAS platform UX (re)design
– Prevention Suite brand consolidation strategy
– Usability reviews
– Companion and utility apps (I-Care mobile experience)
– Backlog management and feature definition cycles
– Content strategy
– IT architecture of the checkup and platform service
PHASE 1
Identify USERS
Kickoff, product vision, brand and users discovery sessions
In the beginning, the proposed Prevention Suite solutions were in the area of btb and btbtc. One of my challenges was to create a system that also reached the end user (btc).
Primary user: btb
Groups of pharmacies, individual pharmacies, gyms, etc. (focus on rich integration with their erp and market leading devices)
Secondary user: btbtc
Pharmaceutical companies, product companies, device companies (focus on solution completeness and customisable carrier grade implementation)
Utenza interna: Internal users: btbtc
Professional operators (focus on the certified training course – academy – and on the concept of marketplace/uber of operators)
Kickoff meeting: user research and co-creation
During the first meetings with the team we extrapolated and discussed some of the questions and answers from the questionnaire sent out pre-kickoff. In this first phase we created together with the other stakeholders the first two user personas of reference.
Results of the HMW exercise (How Might We…)
At the end of the discovery phase, we brought the team together to discuss the findings of the research and leverage them to frame the main design challenges through a design thinking workshop (facilitated by me).
.User Stories e Job Stories
Once we had a clear idea of who uses the platform, we moved on to mapping how they might use it.
This helped us design the I-Care flow to be as fluid as possible and identify the key priorities on which to focus the design
For each need identified in the previous phase I then created an ideal scenario for each type of user and service.
Onboarding pharmacy
Stakeholders was concerned that pharmacists refused to complete their profiles themselves, resulting in continuous calls to support.
We tried to figure out what the real problem was with targeted experience scenarios, user stories and JBDs, until we mapped out a possible solution for the customer to test during the first release.
Customer creation workflow optimisation
Stakeholders was concerned about the problem of receiving too many requests for help from the pharmacist regarding the complexity of the customer creation flow.
From the different user stories and job stories we created a possible testable solution that would take the customer by the hand at every stage of the profile creation process.
Checkup activation
“As a pharmacist, I would like to initiate the customer checkup more easily, so that I don’t have to search for the checkup among the dozens offered by iCare…”
Thanks to this user story we have designed a checkup activation flow (of the day) that starts directly from the customer profile itself so that once the user profile has been created the pharmacist can immediately start the checkups of the day/required.
.Agile User Story Maps
With the user story map I then organised the user stories into a useful model to understand the specific functionalities for each of the proposed solutions, identified holes and omissions in the backlog, and planned the releases that would provide the most value to users and the business.
Miro’s user story map integrated to the Jira backlog
This user story map represents 4 types of actions with different granularity: activities (the reference event), tasks, functions and Jira sprint backlog (the more specific actions).
The activities and tasks are displayed horizontally at the top of the map, and the details (functions and backlog) are overlaid vertically below their respective tasks in order of priority.
PHASE 2
Defining the PROBLEM
How to create an immediate connection between the end user and the I-Care Totem, and make the checkup booking flow fast/intuitive for the pharmacist.
.Brainstorming e sketching
The sketching phase served us to explore potential solutions to design problems quickly.
During the pre-lockdown design, I often used this technique, especially the sketching exercises related to the design sprints (Crazy 8s).
Experience flow derived from How Might We Problems
Part of the HMW technique is to group its posts according to the type of problem they relate to. In this case, the problem led to various flow alternatives, including the one we see in this screenshot.
From general flow to detailed experience
For each of the steps of the previous flow we went through the details of the essential elements and then followed with the flow storyboard (picture below)
Reader’s note
The details of these draft screens are nothing more than “answers” to the following questions:
- What are the objectives of the user and the business when interacting with this screen?
- which of the design problems identified during the definition phase am I going to solve?
- what are the main tasks that users have to perform when they arrive on the page?
- exactly how can the content be organised to support these objectives?
- what should the user see first when they arrive at the page?
- What does the user expect to see in certain areas of the page?
The answers to the questions are organised on our whiteboard as a reference list.
For example, if one of the answers were to be “the user needs to search for a checkup”, I would write the answer and add alongside it an indication of which UI element would help the user achieve that goal (in this case it would be a search bar).
Booking flow storyboard
One of the first user flows created during the I-Care design. Each screen represents an action that our user will have to perform to reach the final “goal” of booking the checkup
.Scenario-based usability reviews
Having identified key experience scenarios for the I-Care user also gave us the opportunity to carry out a usability review based on critical paths (user experience flows crucial to the success of the system itself).
By defining each scenario we traced the steps our user will (probably) take to reach his goal. Here are some of the considerations that have been made at the level of usability for “I-Care Home”.
The home page (like the rest of the platform) did not provide a clear snapshot or overview of the content, features and functionality available
The I-Care platform was ineffective in directing and channelling users to the desired information and tasks
Users could not easily undo, go back, change or cancel actions; there was also no possibility to confirm an action before proceeding
Complex modules and processes were not divided into easily understandable steps and sections
Failure to provide timely and appropriate feedback
Frequently used functionalities were not easily available (e.g. they were not accessible from the homepage) and poorly supported (e.g. shortcuts were not provided)
There was no possibility of searching for the desired checkups (even by symptom area)
CTAs were unclear, poorly labelled and did not appear clickable
Lack of help and instructions (e.g. info-boxes with examples, information needed to fill in forms, etc.)
Users were not able to recover easily (i.e. had to start over) in case of errors
Design and PROTOTYPING
Definition of layout and content strategy, functionality and adaptation to devices
.Wireframing
Our 1st interaction flow (FA1), after being discussed and tested, is transformed into wireframes so that we can start the digital design of this specific testable solution.
Wireframes del flusso di booking
Una volta sketchate le possibili soluzioni siamo passati alla struttura digitale della platform, prima versione indirizzata al layout, navigazione e funzionalità. In questa foto abbiamo uno dei flussi legati ad uno specifico scenario esperienza dell’utente non loggato.
.Prevention Suite design system
PS Design System is a design language that provides a common framework (between designers and developers) for building interfaces within the Prevention Suite ecosystem of products / services (e.g. I-Care). It is a guide to the fundamentals, components, templates and use cases that provides consistency to these products and ultimately provides a satisfying and unified experience to its users.
UI Shell / Layout
At this stage of the design process I created a style guide for the developers and then turned it into a design system.
Not only did this improve the designer-developer collaboration, but it made the platform more consistent and homogeneous.
Reader’s note
The I-Care platform was designed for vertical totems (1080×1920 px) and horizontal totems (1920×1080). During the last design period there was a need to expand for some specific viewports (MacBook 1270×780 and 1440×990 ), so the layout indications have been inserted also for the new type screens
Prototyped “task based” flows
Booking flow checkup prototype FA1
This is one of the first flows to be tested by I-Care. There are multiple interaction paths through these artboards but in this example we have assumed a scenario where:
Reference Hypothesis
1. User wants a solution for symptoms caused by “Stress and fatigue”.
2. Will choose the correct symptom area and trust the recommended checkup after reading the information page
3. Choose the first event in the schedule, the right time and enter your customer details.
4. In this scenario you will not be paid for the event, so you will go directly to the data confirmation and SMS reception.
User task to be tested
User with problems of stress and fatigue book checkup related to his symptom area
Pharmacist account configuration flow type FB1
Task-based workflow that starts with the pharmacist login, goes through the addition of essential data collected with the wizard and closes the configuration by allowing the pharmacist to immediately go on to add the “customer profile”
Reference hypothesis
1. User already has account logins
2. Will choose to configure from the wizard encouraged by the progress bar
User task to test
User “pharmacist” must configure the general administrative account for his pharmacy (without contacting support!).
.Other “task based” experience flows
Body Checkup FC2 flow prototype
Flow related to I-Care checkups (in this case Body Check). All checkups have a structure that changes according to the type of questions, steps, substeps, need to give instructions, etc.
Reference Hypothesis
1. User has already configured the checkup navigation settings
2. Left checked the option that automates the scrolling of questions without the need to click “NEXT”.
User task to be tested
User must move from one step of the checkup to another without being overwhelmed by the many sub-steps
Results
.Conclusions post release vs 1
Thanks to Figma, I created a high-fidelity prototype of the solutions to be tested, and together with the team we were able to involve all the actors involved in the project from the outset. This also allowed us to identify and solve usability problems that had not been evident in the previous phases.
New I-Care is being launched on the international market
User profile configuration can now be managed autonomously
Companion apps available for download from stores
End users can book themselves independently
Thousands of I-Care activations booked in Italy and Spain
Most internal I-Care processes have been automated
.Next steps
While the user testing and iteration phase is going on, we and the team are planning the new backlog for the next sprints in which all the critical flows for an optimal user experience will be implemented as we go along (using the same method as above).