Mind Support - Architecural Designing an App from scratch

UI & UX Design · Figma · UML Architecture

Most student projects stop at the wireframe stage. Mind Support started with structure first: class diagrams, entity relationship schemas, sequence flows, and use case matrices. After that, it was shaped into an interface designed to feel calm and approachable for someone having a difficult day. This is the full case study of a mental health companion app designed from first principles.

There is no implementation here. This is pure UI/UX design: a Figma prototype supported by detailed software engineering documentation. It is the kind of project that shows you understand the system before you start polishing screens.

One in four. Then a blank screen.

Depression and anxiety are not rare cases. They affect a large number of people, yet many digital tools for recovery still feel cold, clinical, and detached from real life. Mind Support was designed with a simple goal: give users a straightforward and non-threatening way to track their mood over time, spot early warning signs before things get worse, and reach support resources without the friction of a hospital-style portal.

The target users were clear: people living with depression or anxiety. That meant the design constraints were clear too. Every navigation choice, colour decision, and piece of copy had to work for someone on a bad day, not just someone feeling fine.

Responsive. In a real sense.

There are already plenty of mood-tracking apps. What makes this concept different is the adaptive layer: an integrated AI language model that learns from the user's patterns over time and offers more contextual support. Instead of showing a generic quote each day, it could respond based on that person's history. If it detects a negative trend, it could suggest a calmer colour mode, surface a playlist, recommend a meditation prompt, or prompt the user to book time with a linked therapist.

That is the long-term direction. Version 1.0 focuses on the foundations: the logging system, the home experience, and the authentication flows that any future adaptive layer would rely on.

Five slides before the detail.

Before getting into the architecture, here is the short introductory presentation that pitched the main concept, the UX philosophy, and the compliance strategy in five pages.

Five stages. No shortcuts.

The design followed a structured process. That mattered even more in a team setting, where unclear assumptions can quietly cause problems later. Each stage produced clear deliverables before the next one began.

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

The point where the design proves it understands the system.

This is the part that turns the work from a mood board into an engineering artefact. Before any high-fidelity screen was created, the system was documented at architectural level. What follows is a breakdown of that structure.

Overall System Behaviour

The top-level system diagram maps each actor: User, Therapist, Admin, and the System. It shows how they interact with the authentication components such as Login, Register, and Forgot Password, as well as the Navigation System, Ticket System, and Mood Log. It also makes clear how a therapist links to a user, how the admin generates compliance reports, and how the system creates or removes tickets in response to user activity.

User Personas & Role System

Three distinct user personas were defined, each with its own access level and interaction pattern.

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 detailed of the two. It models eleven classes, including Authentication, RegistrationManager, LoginManager, PasswordResetManager, TokenManager, SecurityAudit, NotificationService, SocialMediaAuth, and the SocialProvider interface. Method signatures, return types, and relationships are all specified clearly.

The Home Page class diagram breaks the screen into its component model. An abstract Component base class is extended by QuoteComponent, PlanComponent, and NavigationComponent. These are managed by HomePageService and rendered by HomePage using a populated User object.

Entity Relationship Diagrams

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

Sequence Diagrams

Two sequence diagrams trace the main user flows in detail. The authentication sequence covers the full login and registration path, including request login, user validation, credential encryption, result handling, 2FA dispatch, code entry, and successful login. It also includes the reset password route. The home page sequence shows what happens after authentication, including session validation, retrieval of the current day's quote, and component rendering back to the client.

Use Case Diagrams

Use case diagrams were created for both the Home Page and the Login/Register system. The Home Page use case captures five actions available to authenticated roles: log mood, display or activate link components, view username, view plan upgrade options, and display menu. The authentication use case covers login, registration, credential storage, social media authentication, and account creation across the User, Therapist, and Administrator boundaries.

GDPR was built in from the start.

Mental health data is some of the most sensitive data a system can hold. The compliance strategy in this project was designed alongside the features, not added later. For a university project, that depth is worth highlighting.

Area	Implementation
Data in transit	TLS encryption across all client to server communication
Data at rest	AES encryption and cloud-based storage with recognised security certifications
Authentication	Secure credential hashing, role-based access control, and multi-factor authentication for sensitive actions
User rights	Full access to personal data, modification and deletion rights, and explicit consent mechanisms
Audit trail	Security log table recording login attempts, IP addresses, and device information to support compliance reporting
Testing	Regular penetration testing, vulnerability assessment, and incident response planning
Legal framework	GDPR, Data Protection Act 2018, and BCS Codes of Conduct

The privacy model also enforces one key boundary by design: the Administrator role can manage accounts and generate compliance reports, but cannot view personal mood data. That separation is part of the structure itself, not just a written policy.

Every tap should have a reason.

The interface uses a swipe-based navigation model inspired by iPhone gesture patterns. The main call to action, "Log Your Day", sits at the bottom of the screen as a swipeable panel rather than a standard button. That makes the flow feel smoother and can reduce cognitive load for users who may already be dealing with stress or overstimulation.

This was also noted as useful for users with ADHD. It reduces decision points and keeps the screen cleaner at the moment of action. The same gesture idea appears on the Login and Register pages, where an upward swipe confirms the action without needing an extra submit button.

The colour system uses a warm orange against softer neutrals. That choice was intentional. It avoids the cold blue-grey palette common in health apps and creates a tone that feels more encouraging than clinical.

Key Goals

• Calm colour scheme that supports a positive emotional response
• Secure login with swipe confirmation and no separate submit button
• Simple navigation through consistent gesture patterns
• Mood logging reachable in a single action from any screen
• Offline save capability for low-connectivity situations
• Statistics tools and mood history shown in graphical format
• Health consultations and community chat for peer support

From wireframe to final prototype.

Each screen moved through the full design pipeline, from use case to wireframe to high-fidelity final version. The login screen includes an animated logo, social media authentication, and a fireworks animation after successful login as a small reward for completing the entry step. The home screen shows the user's name, daily quote, subscription plan status, and a navigation panel accessed through a single menu button.

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

The full record.

The complete presentation deck covers every stage of the design process, including the UML diagrams, MoSCoW requirements, persona breakdown, user stories, and the progression from wireframes to final designs. If you want to see how each design choice was supported from a technical and legal point of view, it is all there.

A foundation, not the final version.

Version 1.0 establishes the core structure: screens, flows, data model, and security approach. The next step is what would make it stand out from many other mood-tracking apps: an AI voice assistant layer designed to support people who struggle to form relationships, hold natural conversation, and respond to worsening patterns before the user fully notices them.

The architecture was planned to support that future layer from the beginning. The NotificationService, the MOOD_LOG schema, and the therapist role all exist so that the intelligence layer can be added without forcing a full redesign.