I-Care Platform

Lead Product Designer.Val Mercenaro

Lead Developer.Andrea Carta

Software Engineer.Andrea Introini

Developer.Benito Massidda

DESIGN SPRINT
DESIGN THINKING
UI DESIGN
UX DESIGN
SKETCH & PROTOTYPE
WEB DESIGN
USABILITY REVIEW
SCRUM
INFORMATION ARCHITECTURE
USER RESEARCH

.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, simplification 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”.

AFTER - New Home Version

I-Care welcome screen after redesigning

BEFORE - Home version (obsolete)

I-Care welcome screen before redesigning

4
5

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

PHASE 3

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

The first design challenge (creating an immediate connection between the end user and the I-Care Totem, and making the checkup booking flow fast and intuitive for the pharmacist) has been solved and is now in the testing and iteration phase.

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

f

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).