Mind Support — Designing for Someone's Worst Tuesday

UI & UX Design · Figma · UML Architecture

Most student projects die at the wireframe stage. Mind Support grew a spine first — class diagrams, entity relationship schemas, sequence flows, use case matrices — then wrapped it all in an interface warm enough to hand to someone on a difficult day. This is the full case study of designing a mental health companion app from first principles.

No implementation. This is pure UI/UX design — a Figma prototype backed by rigorous software engineering documentation. The kind of project that shows you understand what you're designing before you put a single component on the canvas.

One in four. A blank screen.

Depression and anxiety are not edge cases. They are a significant, persistent reality for a large portion of the population — and yet the digital tools available to support recovery are frequently cold, clinical, and designed by people who have clearly never had a rough Tuesday. The goal with Mind Support was straightforward: give people a simple, non-threatening way to track and log their mood over time, catch the early warning signs of deterioration before they escalate, and connect them to support resources without the friction of a hospital portal.

The target users were clear — people actively managing depression or anxiety — and so the design constraints were equally clear. Every navigation decision, every colour choice, every piece of copy had to work for someone on their worst day, not their best one.

Responsive. Actually responsive.

There are dozens of mood-tracking apps. What separates this concept is the adaptive layer: an integrated AI language model that learns the user's patterns over time and provides genuinely contextual guidance — not a generic daily quote, but a suggested response calibrated to that specific person's history. When the model detects a downward trend, it surfaces relevant resources: a change to the colour scheme to reduce stimulation, a suggested playlist, a meditation prompt, or a direct prompt to book a session with a linked therapist.

That is the ambition. The v1.0 design focuses on the foundational scaffolding — the logging system, the home experience, the authentication flows — that any adaptive layer would sit on top of.

Five slides before the deep dive.

Before we get into the architecture, here is the brief introductory presentation that pitched the core concept — the problem, the UX philosophy, and the compliance strategy in five pages.

Five stages. No shortcuts.

The design followed a structured pipeline — a deliberate choice when working as part of a team where assumptions about scope can quietly derail the whole effort. Each stage produced concrete deliverables before the next began.

#	Stage	Deliverables
1	Proposition	Legal & ethical compliance brief, GDPR strategy, security measures, social impact assessment, BCS codes alignment
2	Requirements	Background research, MoSCoW requirements list, user personas
3	Documentation	Colour system, UML diagrams (class, sequence, ERD, use case), system behaviour diagram
4	Wireframes	Low-fidelity wireframes for all core pages with annotated solution breakdowns
5	Final Design	High-fidelity Figma prototype: all screens, states, error flows, animations

The bit where the design proves it knows what it's designing.

This is the section that separates a mood board from an engineering artefact. Before a single high-fidelity screen was produced, the system was fully documented at the architectural level. What follows is a breakdown of that documentation.

Overall System Behaviour

The top-level system diagram maps every actor — User, Therapist, Admin, and the System itself — against the modules they interact with: the authentication components (Login, Register, Forgot Password), the Navigation System, the Ticket System, and the Mood Log. The diagram makes explicit how a Therapist links to a user, how the Admin generates compliance reports, and how the system creates and deletes tickets autonomously in response to user actions.

User Personas & Role System

Three distinct user personas were defined, each with separate privilege levels and interaction patterns.

Class Diagrams

Two class diagrams were produced — one for the Home Page module and one for the full Authentication system. The authentication diagram is the more complex of the two, modelling eleven classes including Authentication, RegistrationManager, LoginManager, PasswordResetManager, TokenManager, SecurityAudit, NotificationService, SocialMediaAuth, and the SocialProvider interface. Every method signature, return type, and relationship is specified — composition, aggregation, and dependency clearly distinguished.

The Home Page class diagram decomposes the screen into its constituent component model: an abstract Component base class extended by QuoteComponent, PlanComponent, and NavigationComponent, all managed by HomePageService and rendered by HomePage against a hydrated User object.

Entity Relationship Diagrams

The database schema is documented in full across two ERDs. The authentication schema covers eight tables: USER, SESSION, SECURITY_LOG, RESET_TOKEN, AUTH_METHOD, VERIFICATION_CODE, and USER_ROLE — with all primary keys, foreign keys, and cardinalities defined. The Home Page ERD adds HOME_PAGE, COMPONENT, NAVIGATION_ITEM, MOOD_LOG, TICKET, QUOTE, and PLAN to the model.

Sequence Diagrams

Two sequence diagrams trace the critical user flows in detail. The authentication sequence walks through the full login and registration lifecycle — request login → validate user → encrypt credentials → operation result → 2FA code dispatch → code entry → login successful — including the parallel reset password path. The home page sequence maps the post-authentication data load: session validation, database fetch of the current day's quote, and component rendering back to the client.

Use Case Diagrams

Use case diagrams were produced for both the Home Page and the Login/Register system. The Home Page use case captures the five actions available to any authenticated role — Log the Mood, Display/Activate Link Components, View Username, View Plan Upgrade Options, and Display Menu — branching from a single "View Home Page" node. The authentication use case maps the full scope of login, registration, credential storage, social media auth, and account creation across the User/Therapist and Administrator actor boundaries.

GDPR was not an afterthought.

Mental health data is among the most sensitive a system can hold. The compliance strategy for this project was designed at the same time as the features, not bolted on afterwards — and for a university brief, the depth of that strategy is worth calling out explicitly.

Area	Implementation
Data in transit	TLS encryption across all client–server communication
Data at rest	AES encryption; cloud-based storage with recognised security certifications
Authentication	Secure credential hashing, role-based access control, multi-factor authentication on sensitive actions
User rights	Full access, modification, and deletion of personal data; explicit consent mechanisms
Audit trail	Security log table captures every login attempt, IP address, and device info; supports compliance reporting
Testing	Regular penetration testing, vulnerability assessments, real-time incident response planning
Legal framework	GDPR, Data Protection Act 2018, BCS Codes of Conduct

The privacy model enforces one important boundary by design: the Administrator role can manage accounts and generate compliance reports, but cannot view any user's personal mood data. That separation is structural, not policy.

Every tap should feel earned.

The interface uses a swipe-based navigation model modelled on iPhone's native gesture language. The primary call-to-action — "Log Your Day" — lives at the bottom of the screen as a swipeable panel, not a button. The friction of a tap is replaced by the fluency of a gesture, which meaningfully reduces cognitive load for users who may already be managing overstimulation.

This choice was specifically noted as beneficial for users with ADHD — it removes the decision-making overhead from task completion and reduces visual noise at the point of interaction. The same gesture logic applies to the Login and Register pages: a single upward swipe commits the action, keeping the screen clear of an additional submit button.

The colour system — a warm, energetic orange against softened neutrals — was chosen deliberately over the blue-grey clinical palette common to health apps. Orange is activating without being alarming, and it reinforces a tone of encouragement rather than monitoring.

Key Goals

• Calm colour scheme that promotes a positive emotional response
• Secure login with swipe confirmation — no dedicated submit button
• Ease in navigation via consistent gesture patterns throughout
• Mood logging reachable in a single action from any screen
• Offline save capability to support low-connectivity use cases
• Statistic tools and mood history in graphical format
• Health consultations and community chat for peer support

Wireframe to finished product.

Every screen went through the full pipeline — use case to wireframe to high-fidelity final design. The login screen features an animated logo load, social media authentication, and a fireworks animation on successful login (a small, considered reward for completing the barrier to entry). The home screen presents the user by name, surfaces their daily quote, subscription plan status, and a full navigation panel behind a single menu button.

Explore the full Figma prototype below. Every screen is clickable.

The receipts.

The complete presentation deck covers every stage of the design process — the full UML diagram suite, the requirements lists in MoSCoW format, the persona breakdown with user story sets, and the wireframe-to-final-design comparison for all pages. If you want to see exactly how a design decision was justified from a technical and legal standpoint, it is all in here.

A foundation, not a finish line.

Version 1.0 establishes the core scaffolding. The screens, the flows, the data model, the security posture. What comes after is the part that makes it genuinely different from the thirty other mood-tracking apps on the App Store: the AI voice assistant layer — a conversational interface designed to support people who struggle with forming relationships, capable of natural dialogue and adaptive enough to respond to deteriorating patterns before the user has consciously recognised them.

The architecture was designed to accommodate that layer from the start. The NotificationService, the MOOD_LOG schema, the therapist role — all of it exists so that when the intelligence layer is added, it slots in rather than forces a rewrite.