Product type

Web App

Timeline

Jan 2022 - present 

Software

Figma

Project Introduction

An Average 65% of employees in the UK had work-related pain and pain levels as 3.6/10. We had developed VItrue VIDA to assess posture, pain, ways of working, and ergonomic risks.

To accommodate end users' needs, a personalised program would help them to do quick exercises regularly to stay away from workplace-related aches and pains. It is called 'Pain Coach'.

From our user retention funnel data, a low percentage of end-users actively and effectively engaged with pain relief recommendations. 

Pain relief is a long routine process and requires commitment and effort. We found there were two main reasons that users felt it hard to engage in the pain relief process.

• Users were less motivated because they couldn't see instant gratification or rewards for pain relief.

• Users feel difficult to engage because they only feel improvement after a long term routine.

In the project earlier, I already produced a persona for the end user. It is time to revisit and adjust it based on new interviews and research. Reviewing the persona with team members, helps everyone focus on the real problem at hand. Discussing a product or project from the perspective of a persona shifts the focus of a conversation from ‘my opinion is better and matters more’ to ‘what works better and matters more for the persona’. 

Good design, especially for complex systems, demands that different disciplines bring their point of view to the matter. Vitrue products were developed deeply from clinical roots. Therefore,  a multi-disciplinary design workshop including clinical lead, product owner and customer success manager is a great way to start. The main workshop structure is,

Step 1: Identify the problems and user scenarios

Step 2: Go deeper to the problems 

Step 3: Ideas and possible solutions on sticky notes and group them

Step 4:  Discuss the Limitations 

All the feedback is gathered and arranged in the clear sections which may be the abstract sections/features of the product. After discussing the impact and feasibility with the team. Each topic group ( autonomy, competence, relatedness)  represents a clear idea of which features could be prioritised in the design process. 

Doing this activity helped me to get a clear view of what is important to the user while satisfying business goals and tech requirements (features with a golden star).

During this phase, I merged the prioritized features collected in the earlier stages into user journey map. My goal was to learn about the essence of what exactly the users were expecting, what kind of pain points they would experience through the whole process, and their main usage paths, along with business objectives. Being able to see the whole picture helped me to create a detailed step-by-step product experience that would satisfy the needs of both the users and the business in the best possible way. 

This user flow was made to establish the right order for the essential user scenarios that have been determined in the earlier phases. It helps to design and adapt the actions that users have to take in order to achieve their goals in every task. With the help of user flow, I was able to build the whole inner logic of the service by thinking about all of the functional demands of the application and started wireframing at the same time.

By taking the most impactful and least effort-required features, I started sketching some ideas. I designed several card components for each feature and tried different combinations of components to fit into the dashboard structure. I did several rounds of guerilla testing to observe users' reactions to different sketch options and questioned their preference.

During the design review of the lo-fi wireframe with the team and stakeholders, I brought the design and testing insights to discuss the proposal for hi-fi wireframing.

Based on different user behaviour and scenarios, I developed a full set of interface design options according to different user behaviour and scenarios. For example, 'my stats' card varies if the user chooses different goal-setting and the pain level info was based on the user's assessment.

A/B testing

Phase 1 provides the core function flow, conducting exercise video and providing feedback. In phase 2, I would like to combine more components, such as timeline, roadmap and progress statistics, in order to form a better routine.

These new features bring about numerous dilemmas: which one leads the whole flow? What components have more impact? What call-to-action copy converts more? So I developed two design versions of a variable, and formulated a solid hypothesis to test with a group of participants.

A/B testing doesn't mean I have to go for one of two options, but it allows me to construct hypotheses and to learn why certain elements of their experiences impact user behaviour. 

I made test summary slides to share the key insights and how they impact our design development with the whole team.

4/5 preferred a roadmap-based dashboard, and they thought it was a clear journey representing logical steps, and it was less ambiguous by giving a big picture.

3/5 would like to change their goal and update their pain level information.

The most useful components are goal(targeted area), pain level and progress.