MentorConnect

A structured mentorship platform connecting students with industry professionals.

MentorConnect was designed to make professional mentorship easier to discover, easier to manage, and more meaningful over time. Instead of treating mentorship as a one-off introduction or coffee chat, the platform creates a structured relationship with discovery, requests, messaging, scheduling, and feedback built into the same experience.

01 Designing Around Three Different Users

The first challenge was understanding that MentorConnect was not one product for one type of user. Students, mentors, and administrators all interact with the platform differently.

Students need to discover relevant mentors, understand their experience, request mentorship, communicate, and book sessions.

Mentors need more control. They need to manage their availability, review incoming requests, communicate with students, and keep track of existing relationships.

Administrators need a wider view of the platform, including user management, reporting, and category organisation.

This led to a role-aware product architecture. Navigation, dashboards, available actions, and content change according to the user’s role, so each person sees the tools they actually need.

02 Making Mentorship a Process, Not Just a Connection

A major product decision was to avoid treating mentorship as simply matching two people together.

The experience follows a deliberate progression:

Discover → Request → Connect → Message → Schedule → Review

A student first discovers a mentor and sends a mentorship request. The mentor can accept or decline before any direct relationship is created. Once accepted, messaging and session scheduling become available.

This gives mentors control while giving students a clear understanding of where they are in the relationship.

Reviews then complete the loop. Feedback contributes to a mentor’s public rating, giving future students another layer of information when making their decision.

03 Designing the Onboarding Experience

Mentorship depends heavily on context. A student’s interests, goals, and preferred areas of guidance all influence which mentors are relevant.

Rather than asking for everything on one long form, we designed onboarding as three progressive steps:

Role selection → Profile details → Interests and goals

Each stage introduces only the information needed at that point. The result is a shorter, more focused onboarding experience while still collecting enough context to personalise the platform.

04 A Visual System Built for Focus

The visual direction deliberately moved away from the bright, gamified language often associated with education platforms.

We used a dark grey palette with restrained glassmorphism, thin typography, sharp edges, and generous negative space.

The interface uses blur and translucent surfaces selectively rather than turning every element into a floating glass card. The intention was to create a calm environment where conversations, profiles, and decisions remain the focus.

The visual system was also designed to scale as the product grew. New areas such as messaging, sessions, and reviews could be introduced without creating a separate visual language for each feature.

05 Information Architecture Based on the User Journey

The product structure follows the actual lifecycle of mentorship rather than organising features around technical functionality.

Discover Mentors leads to a Mentor Profile, which leads to Request Mentorship. Once a relationship exists, users move into My Mentorships, Messages, and Sessions. Reviews sit at the end of that journey.

Administrative tools are kept separate from the core experience, with dedicated areas for users, reports, and categories.

This separation keeps the student and mentor experiences focused while giving administrators the oversight they need.

06 Designing for Role-Aware Experiences

The platform’s role model became part of the UX rather than something hidden in the backend.

A student should not have to navigate through mentor management tools. A mentor should not see administrative controls. An administrator needs access to information and actions that would be inappropriate for other users.

The interface therefore responds to user_type, changing navigation and available actions accordingly.

This creates a simpler experience for everyone while also establishing a clearer boundary between responsibilities.

07 Iterating as the Product Grew

As new functionality was introduced, we treated consistency as part of the design process.

Messaging, sessions, reviews, and mentorship requests were refined to work within the original visual system rather than becoming isolated features.

We also treated functional bugs as design problems when they affected the user’s journey. For example, broken navigation between requests and messages was not simply a technical issue. It interrupted the relationship flow the product was designed around.

Fixing those connections was therefore part of completing the experience.

08 The Result

MentorConnect became a cohesive mentorship platform where the complete relationship lifecycle can happen in one place.

Students can discover and connect with professionals. Mentors can control who they engage with and manage their availability. Administrators have the oversight needed to maintain the platform.

More importantly, the product gives mentorship a structure. Discovery leads to a request, a request leads to a relationship, and that relationship leads to ongoing communication, scheduled sessions, and feedback.

The result is a product that treats mentorship as an ongoing experience rather than a single introduction.

Designed and engineered by Evuve.