Expanding Upon a Research Platform Connecting Students with Faculty Research

Outcome

The 6-week project delivered a redesign and expansion of ResearchHub, a Purdue-specific research collaboration platform, addressing its lack of a design system and improving usability for Purdue students and staff.

Some features were requested directly by our client, Professor Reese of the statistics department. Others were built around communication and project maintenance, student-side needs surfaced through my own research.

Overview

ResearchHub is an AI-assisted platform that streamlines Purdue students’ ability to discover and contribute to research projects, while helping professors find and onboard the right students. Rather than replacing cold emails and departmental postings, it consolidates them into one system where both parties see the same information.

Prior work on the platform focused solely on delivering functionality: logins, postings, applications. It left a working base with no coherent design system and few of the features its users needed.

The Problem

Research opportunities at Purdue are plentiful but scattered across department pages, faculty sites, listings, and word-of-mouth, so students have no centralized place to discover projects.

Professors have no shared workspace to coordinate project workload, so there is no common view of responsibilities, blocked tasks, or items needing follow-up, and progression stalls.

My Role

I was the sole UI designer, later also Design Engineer, on a 6-person Purdue Stack team with 5 full-stack developers. I determined all UX and UI decisions and contributed front-end React.

I held weekly discussions with my teammates to keep conceptualized features aligned and feasible.

Researching

Auditing the Platform and Its Two User Groups

My teammates needed to begin development on schedule, so understanding the platform and its two user groups had to fit one quick sprint.

In a 1.5-week research sprint, I audited both roles end-to-end (student & professor) and ran 4 student interviews.

The Platform Audit

The core features worked, but the UI was visually basic and obviously AI-generated. I walked each role’s flow end-to-end, logging friction rather than bugs, and the issues clustered into three categories:

1. Redundancy & technical issuesDuplicate affordances on one page; some edits not saved.
2. Hinted-at, unfulfilled featuresProfiles, listings and communication existed in name only.
3. Design system components neededButtons, cards and navigation labels.

Understanding User Needs

Professor needs were expected from upcoming client meetings, so I interviewed 4 students on their research experience across:

• Discovering projects
• Applying
• Progress meeting logistics
• Research deliverables
• Current state views

Affinity diagramming clustered what they said into three themes:

See the affinity board

When Professor Reese’s schedule prevented an in-depth meeting, I based professor needs on his earlier feature requests and prioritized them by how often students would interact with each.

The Core Features Professor Reese Requested

1. Individual project workspaceDetails, team, progress, timeline and milestones in one place. The interface students return to most.
2. AI review testsVerify students read assigned documents. Met once per document.
3. Finalizing projectsClose a project and check who wants referral letters. Only triggers at the end.

Designing

From Existing Base to Handoff-Ready Prototypes

The design process ran in three stages:

• Identifying UI patterns from familiar platforms
• Refining UI around Purdue identity
• Wireframing for development handoff

Referencing UI Patterns from Familiar Platforms

Students frequently named the Microsoft suite, Outlook, and Gmail as the tools they already used with professors, so I referenced those same platforms when designing ResearchHub’s UI.

Their interaction patterns became the base for the platform’s components, modified to fit ResearchHub’s organization by project rather than by individual.

Refining UI Around Purdue Identity

I moved on to sketching features and screens to explore possibilities quickly, showing sketches to my teammates to check each page’s development plausibility while gathering outside feedback in parallel.

Shipping next semester was the priority, so I deliberately kept the design system work minimal and let the ship-critical features take precedence.

Instead I refined the existing UI and components to be more reminiscent of Purdue through color and type, reinforcing its identity as a Purdue research platform.

Prototyping for Developer Handoff

To keep development on schedule, I wireframed in Figma while discussing implementation plausibility with my teammates, gathering outside feedback on both feasibility and usability.

Because both student and professor flows had to be wireframed in the same window, I used Figma Make to keep shared pages consistent without re-drawing the same components across two flows.

The final prototype showed the redesign as connected flows covering real use cases:

• Students logging in to just update task progression
• Communication between students and professors
• Professors maintaining and organizing contents of each project

Project Content Maintenance

The project dashboard was designed to centralize a project’s content without overwhelming the viewer, segmenting it into five sections via left-side navigation. It began as Professor Reese’s request for a project-maintenance dashboard.

Key features:

• Left-side navigation splits content into five sections (Notifications, Students, Documents, Task Log, and Timeline) to avoid overwhelming the viewer.
• Each section serves both roles simultaneously, so professors manage the content while students engage with it in parallel.
• The Documents section includes AI-generated comprehension quizzes to verify students have read the assigned materials, addressing one of Professor Reese’s core-feature requests.

General Dashboard

The dashboard was designed to centralize a routine day’s needs, whether a student updating task progression or sending a message, or a professor assessing how their students are progressing.

Key features:

• Mini Project Dashboard that provides access to tasks and to other projects
• Buttons to access specific project dashboards and direct messages within one click.

Communication

The messages page was designed to provide organization for communication between professors, research assistants, and students, in a structure already familiar to them.

Key features:

• Standard file-attachment feature as the base affordance for familiarity to other platforms
• “Simplified Kanban or pin board” to track progression and links to external resources or tools also spares the development team from additional integrations into the platform.
• Two-level navigation from projects down to individuals similar to Microsoft Teams' organization classes down to specific channels.

Project Content Maintenance

The project dashboard was designed to centralize a project’s content without overwhelming the viewer, segmenting it into five sections via left-side navigation. It began as Professor Reese’s request for a project-maintenance dashboard.

Key features:

• Left-side navigation splits content into five sections (Notifications, Students, Documents, Task Log, and Timeline) to avoid overwhelming the viewer.
• Each section serves both roles simultaneously, so professors manage the content while students engage with it in parallel.
• The Documents section includes AI-generated comprehension quizzes to verify students have read the assigned materials, addressing one of Professor Reese’s core-feature requests.

General Dashboard

The dashboard was designed to centralize a routine day’s needs, whether a student updating task progression or sending a message, or a professor assessing how their students are progressing.

Key features:

• Mini Project Dashboard that provides access to tasks and to other projects
• Buttons to access specific project dashboards and direct messages within one click.

Implementing

Stepping In to Ship the Platform on Time

As the wireframes were finalized, I began contributing code, specifically front-end React. I took the more mundane, tedious parts so my code-savvier teammates could focus on the platform’s complex areas, keeping progression efficient by playing to our individual strengths.

I also had to expand my own designs as I moved onto new pages, accounting for feature reactivity across any browser size.

Takeaways

Design With the Cost of Building in Mind

Directly building my own ideas significantly modified how I factor in limitations. Sometimes I would code while thinking, half-annoyed, “Jeez, who is the designer who designed and requested all of these details”. Working as both designer and engineer emphasized the need to ideate as a development partner rather than an ideater.

From this project, I better understood that a design’s demands include the building cost, and that a designer who accounts for the cost is able to ensure a well-designed handoff would be fully utilized.

Adapting to Uneven User-Group Access

Due to needing conceptualization finalized in the project’s first weeks, I was unable to conduct user research on professors as in-depth as I did with students, since the two user groups offered very different levels of access. I had only one professor (our client) available and an entire campus of students readily available. As a result of the contrasting amount of specific user feedback, I prioritized the features Professor Reese had requested by how frequently students would interact with each, so the highest-student-impact professor-requested features would ship first.

From adapting to this obstacle, I now recognize that working with uneven user-group research requires sequencing the less-accessible group’s requests by how frequently the more-accessible group would interact with each, so I can prioritize the applicable ideas ahead of the impractical ones.