Sophia - a health and well being portal


Roles: User Research, UX/UI Design, Development
Tools: Figma, Optimal Workshop, Usability Hub, Miro
Client: CareerFoundry UX Project
Team: Solo (designer, researcher)
Timeline of One Year


The goal of this project was to create a well being portal for busy working professionals. A centralised hub for accessing verified health resources, practising mindfulness, and tracking mood through daily journal entries, the purpose of Sophia is to encourage a more holistic approach to health.

The portal was developed through a series of:

  • competitive analysis of existing products in this space
  • user interviews which helped to define personas, user journeys, flows and information architecture
  • a round of prototyping and usability testing
  • development of an early visual design system and mockup

This project allowed for the creation of an early mockup, but in a real life setting it would require more rounds of usability testing and iteration of the design to ensure all business requirements were met and that the product meets all user needs.

Project overview

To keep on top of our forever changing and ever-busy lives, many young professionals now look to various health apps to track their well being. As well as looking at their physical health, mental and emotional wellness is becoming an increasing point of concern for many individuals who struggle to balance work with life.

Through this CareerFoundry project, we set out to discover problems that these users were facing, what their needs were, and understand goals they had in improving their overall well being through the development of an accessible and responsive health portal. Sophia was designed as a tool and platform that would grow and change with the user, allowing users to journal, learn and meditate all in one convenient location.

Exploring the problem

Before anything, we needed to better understand users’ potential problems and frustrations. From this, we would be able to start thinking about a clearly defined Problem Statement that would define the design and scope of Sophia.

Possible Problems

  • Users feel unmotivated and uninspired to track well being and mood
  • Access to quality educational resources is hard to find and verify
  • Health, particularly mental health, can be very personal so putting it into writing on a platform can bring anxiety and worry around privacy + security
  • Journalling takes time, and could be seen as a chore to complete rather than something reflective and meditative
  • A lack of free time in the day to work on yourself through an app/portal

Possible Solutions

  • A way of incentivising tracking well being and mood, either through gamification methods within the app or a financial angle (such as receiving a discount for health insurance should the user reach a certain stage)
  • Integrating a catalog of vetted education resources backed by industry bodies, as well as guest appearances/authoring from members of the medical community
  • Design app and portal to be secure from the start, with all user data encrypted (AES-256, Curve25519 or similar) and nothing shared without their explicit permission, and an option to export data off of the app freely
  • Integrate journal function to be something that can be embedded or used like a widget, so that a small popup prompt is all it takes for a user to write something down. Could also allow users to record journals using voice-to-text to help with uptake.
  • Have different timeframes so that users can journal for as little as 5 minutes a day, and can choose to write more if they wish. To help them get started, journals could begin with some kind of prompt

"Young working professionals need a way to balance life/work commitments because of their increasingly busy lifestyles.

We will know this to be true when we see at least a 15% reduction in the number of work-related burnout and sick leave, and a 20% increase in net productivity for those using Sophia within a workplace setting.

For individuals, we will know this to be true when we see at least a 20% increase in user-reported happiness after having used the app consistently for two weeks."

Double Diamond design process.

Design Process - Double Diamond

Throughout this project, we followed the Double Diamond design approach to structure the design process and create a solution that would be useful for users in the development of Sophia.

  1. Competitive Analysis
  2. User Interviews
  3. User Personas, Flows, and Journey Maps
  4. Information Architecture
  5. Prototyping and User Testing
  6. Visual Design
  7. Refined Mockup and Prototype
  8. Reflections

Competitive Analysis

In order to understand the current scope of the health and well being market, we analysed and created SWOT profiles on four competitor products.

A competitive analysis of different products on the market.

From these SWOT profiles, we found that competitors such as Headspace and Calm were most successful due to their branding and polished end user experience. However, the subscription cost is comparatively high compared to other rival products.

User Interviews

To gain a greater understanding of the above problems, we conducted user interviews to obtain data. These interviews meant we could better understand our target audience and their needs.

In these interviews, the key objective was to understand what was important for participants and what they looked for in a product such as Sophia.


Albert (26) - full-time university student
Sally (23) - part-time barista, full-time university student
Rick (23) - full-time QA engineer and software developer

A combined affinity map from user interview responses.
A combined affinity map from user interview responses

Some key findings from these interviews were:

  • The importance of free time and structured time

  • Having an online-first approach

  • Quality user experience over everything

  • Looking at a holistic approach to health that encompasses everything related to physical and mental well being

User Personas

With a greater understanding of users’ frustrations, goals, and needs, user personas could be created to help refine who Sophia is for. Three personas and corresponding user journeys and flows were created based on the data collected.

As we move further along in the design process, these personas can help serve as touch points to refer back to, ensuring that development is kept to meet the needs of the users and only necessary features are included.


Alan is a full-time university student studying a Bachelor of Arts at the University of Auckland.

Him and his girlfriend both try to maintain a healthy balanced lifestyle through regular exercise and good nutrition, but have struggled with keeping a social life in balance with university.

Being a full-time student with little money, Alan rarely seeks paid healthcare services and will look up most answers online.

Alan user persona


Waiching is a recent university graduate working as a full-time software developer for a local startup in Christchurch.

She is a highly driven individual who is always looking for ways of improving herself, both for her ability to work and personal well being as well.

With performance reviews coming up soon, Waiching wants to be in the best state of productivity and performance possible.

Waiching user persona


Jill is a full-time CFO at an engineering firm. She has recently gotten engaged with her long-time boyfriend and wants to work on her overall well being before the wedding.

Long hours and demands of her job have meant that Jill’s mental health has struggled over the past few years, and with the help of her fiancée she wants to try get this back on track.

Jill user persona

User Journeys

User journeys for Waiching and Jill as an example

When creating user journeys, it was important to think about the state of mind of our personas. There might be times where our users are tired, frustrated and stressed from the outset due to their busy lifestyles, and are going to Sophia to find some sense of calm. This means that it is especially important that pain points are reduced, and that their journey to complete a task is as smooth as possible.

User Flows

After discovering the main features of Sophia, user flows were created to understand the steps our personas would follow to reach their goals.

User flow for accessing saved materials on Sophia.
Saving materials on Sophia
User flow for listening to guided meditations on Sophia.
Listening to a guided meditation on Sophia

Information Architecture

The structure of Sophia was defined and improved through a closed card sort, facilitated through Optimal Workshop.

The sort consisted of 19 cards in total for participants to group into 7 categories. A total of 5 people completed the exercise, with all participants based in New Zealand from my target audience.

Participants strongly agreed on the placement of Library cards, with only a few outliers for “Listen later.”

SOS options were the most clear of all categories and universally agreed upon.

Daily Journal, Time Sheet and Modules categories had the most disagreement and spread, with little consesus on what cards belong here.

Findings of a closed card sort to define IA.
The results of this card sort helped to refine the sitemap and overall IA.

Completed sitemap and IA.

From the card sort exercise, it was clear that users prefer universal and commonly used words for describing features and menus.


With user flows defined, initial designs were created as low-fidelity paper wireframes.

Guided meditation mobile flow

Lo-fi meditation userflow.

These paper wireframes then led to the creation of mid-fidelity prototypes in Figma.

Mid-fi meditation userflow.

At this stage, the decision was made to utilise a design system across the whole of Sophia in order to bring greater consistency across the portal. After some consideration, the Polaris Design System by Shopify was chosen as a foundation and adapted for Sophia.

From the original information architecture, the ability to switch views (Calendar View, Kanban View, and Roadmap View) was abandoned in order to keep the design simple and matching with Polaris. Using and adapting existing systems makes development faster, and saves having to reinvent the wheel for every new project.

Hi-fi meditation userflow.

With a high-fidelity prototype up and running, it was time to test this new design through usability testing.

Usability Testing

Prior to conducting the tests, a plan and script was written to ensure a consistent testing process between the different users. Participants were recruited through personal and professional contacts.

The testing was moderated, taking place over a week from April 30th to May 6, 2022. Two tests were taken remotely via Google Meet, with the remaining four done in-person at their place of residence.

All responses were gathered and collated into a Rainbow Spreadsheet, which can be accessed here.

Participants appreciated the effort taken to meet them in-person at places that were most comfortable for them. In turn, they were more willing to take their time and give indepth feedback during testing. In future rounds of usability testing, we will continue to attempt to run all tests in the environment that is most comfortable and convenient for the participant.

Based on the responses and feedback, six key issues were identified and ranked according to the Nielsen Scale.

  • Issue 1: Unable to delete past journal entries (High Severity)
    Evidence: 2 participants noted a lack of delete option upon creating a journal entry
    Suggested change: Design and implement a delete button

  • Issue 2: Lack of colour and illustrations make the portal feel cold (Low Severity)
    Evidence: 4 participants remarked on the lack of colour and illustrations in Sophia, making it feel “cold” and “clinical” particularly in the Mindfulness Center
    Suggested change: Begin adding colour accents and illustrations throughout Sophia

  • Issue 3: Lack of progress display and personalisation on Dashboard (Medium Severity)
    Evidence: 2 participants commented on adding a section in the Dashboard to show different metrics and user progress on Sophia
    Suggested change: Design and implement a progress section at the top of the Dashboard

  • Issue 4: Lack of recommendations for users (Low Severity)
    Evidence: 2 participants suggested that having a recommended section would help personalise the Portal and support new users who weren’t sure what they were looking for
    Suggested change: Design and implement a recommendations section for users, which could be algorithmically generated and personalised

  • Issue 5: Users struggle to find music on Sophia (Medium Severity)
    Evidence: One participant had great difficulty in finding music within the Mindfulness Center, having to look through screens multiple times
    Suggested change: Either clearly label music within the Mindfulness Center, or implement a standalone screen/area for this

  • Issue 6: Lack of descriptions of what each screen was for (Medium Severity)
    Evidence: 2 participants noted that it would be nice to include a text description at the top of different screens that explain the purpose of it, specifically The Library
    Suggested change: Add description of The Library below main title, move to add this onto other screens as well for clarity

A visual list of all fixes implemented.
Issue 1 - A delete button was added as an option to all posts
A visual list of all fixes implemented.
Issue 2 & 3 - Areas such as quick toggle buttons have been highlighted for clarity, and progress metrics displayed on the Dashboard
A visual list of all fixes implemented.
Issue 4 - A horizontal row of recommended materials added to main Library screen
A visual list of all fixes implemented.
Issue 5 - Description updated to specify inclusion of music, as well the addition of a dedicated filter button
A visual list of all fixes implemented.
Issue 6 - A short text description added to all core screens such as the Library and Mindfulness Center

Visual Design

Screenshot of Sophia Design Language System.

To set guidelines for future iterations of Sophia, a style guide/design language system was created.

The guide establishes a set of design principles, patterns, and UI components that will be used to create consistent experiences across all platforms and future versions.

View the guide here

Refined Mockup and Prototype

Once Sophia’s visual design system was completed, a round of peer reviews and iterations were undertaking for further improvements

The result is Sophia’s most recent design, which reflects the insights and findings gained through the Design Thinking Process.

Making a quick journal entry.
Sophia allows for making a quick journal entry
Playing last meditation.
You can play back your last meditation easily
Accessing the Library.
There is a wealth of content available in The Library
Accessing the Mindfulness Center.
The Mindfulness Center contains everything related to mental wellness
Accessing journal entries.
Past journals are logged and support rich media content
Settings screen.
Extend Sophia with different integrations, and gain access to premium content through a paid membership

Link to Figma prototype


Over the past three to four months, the UI and structure of Sophia has changed dramatically. The look and feel of the app is vastly different from how it was when usabillity testing was last conducted, so it would be wise to organise another round of feedback and review.

Data from user research and usability testing has been, and will continue to be, critical to the continued improvement and success of this project. Breaking the development process down into smaller, iterative cycles has been hugely helpful in ensuring that this is the case.

As far as specific areas of improvement are concerned, a greater consideration of the business/monetisation around Sophia would be of great benefit. The current premium membership model feels tacked on and could be refined further. It is important to ensure that Sophia is commercially viable before it is released to the public.

For user testing, it would be useful to test on the same target demographic to see if Sophia is fulfilling its mission statement, and identify any gaps that need addressing. An approximate timeline for this would be:

  • conduct further competitor analysis, research monetisation options (1 - 2 days)
  • finish designing all screens (2 - 3 days)
  • conduct usability testing and A/B tests (1 - 2 weeks)
  • implement user feedback and raised issues (3 - 4 days)
  • follow up usability testing (1 week)
  • buffer time for wrapping up any further issues or concerns (2 - 3 days)

Next steps

In a real life setting many things could potentially go wrong with a project such as this. Here are some examples of what might happen and how I would approach those situations:

  1. Inappropriate content included

In an effort to meet short timeframes, inappropriate and/or low quality content could be included as part of the app’s library. This would lead to a degraded end user experience, where the result would be no different from searching online for resources and potentially receiving unverified, subpar material.

I would avoid this by ensuring that the inclusion of content onto the platform is always vetted by reputable industry experts, prioritising quality over quantity.

  1. A lack of stakeholder engagement

During the requirements gathering phase, if there is not a clear comms and engagement strategy to have all stakeholders on the same page, there is a danger of a stakeholder manifesting mid-project and bringing up something new that throws off all prior work.

I would avoid this by ensuring that all stakeholders are present during the initial planning phase, but also kept in constant contact so that they are up to date with how the project is progressing and checking all deliverables are on point.

  1. Skipping the research

In an effort to cut costs and time, user research can often be axed in favour of moving directly into designing and developing. Because research helps to de-risk design solutions, the danger of removing this is that there is no clear way of knowing users want this product, if they will use it, and if they will be able to use it.

In the case of Sophia, I would avoid this by arguing the importance of this as evidence to both justify as well as measure the effectiveness of the product, particularly in the case of the journalling feature, and make user research and testing central to the design process.