iProject – Advanced UX, Syracuse University

Problem statement

Syracuse students struggle to find faculty-led projects outside of the classroom. Information about current projects on campus, the faculty attached, and how to get involved, is scattered across websites. This limits students, who are often looking for work experience, and deprives professors the benefits of working with students.

Lean UX Process

Working with my teammates (a UX designer, project manager, and business advisor), we followed a Lean UX process of iterative design. Our group collaborated to create a Minimum Viable Product. For each design iteration, feedback was provided internally, designs were improved, and research was conducted to quickly develop a product that met user needs.

Step 1: Outcomes, Hypotheses, Assumptions

Outcomes

A brainstorming session was held to determine business and user outcomes. The problem statement was revisited. The solution was named iProject, a web application that would serve as a centralized location for students to view active faculty projects and apply for opportunities.

Persona

iProject was designed for two user groups: students and faculty. Students would use the application to search and apply for projects. Faculty would use the application to post projects and review applications from students. The scope was narrowed to focus exclusively on the student experience.

A proto-persona, Alice, was created to represent a typical user of iProject. Goals and obstacles were identified using assumptions about the user demographic. Later research was used to validate assumptions and evolve the persona.

Bio

Alice is a first-year graduate student in the Library and Information Science program at Syracuse University. She is looking forward to exploring the area and meeting other students. Alice is considering applying to PhD programs after graduation.

Age: 24

Occupation: Student

Location: Syracuse, NY

Monthly expenses: $2000

Goals

• Explore a career in academia
• Gain career experience for the job market or PhD programs
• Work with experienced faculty
• Meet other graduate studnts
• Explore interdisciplinary fields

Obstacles

• New to area
• No access to a car. Walks and takes public transportation
• Limited social support

Hypothesis table

Following the format outlined in Gothelf and Seiden's book Lean UX, a hypothesis table was created to connect the persona, business and user outcomes, and features for iProject.

Online survey

To confirm Syracuse students were interested in faculty projects, a survey was created using Google Forms. 16 graduate students, 2 undergraduates, and 1 PhD student responded.

The survey included built-in logic so students who had not participated in faculty projects were asked different questions than students who had worked with faculty. Each set of students answered questions using a 5-point Likert scale.

For students who had not worked with faculty, we wanted to learn why students had not participated and what barriers might exist.

Students' Reasons for Not Participating in Faculty Projects

Students' reasons for not working on faculty projects varied

Students' Experiences Working on Faculty Projects

Survey participants reported positive experiences working with faculty on projects

Students who had worked on faculty projects before were asked about their experience and if they would be interested in working with faculty again. The responses support our group's assumption that faculty projects are a positive experience for students.

Other survey findings:

• About 50% of students who worked on faculty projects learned about the projects through their professors and applied directly through them
• None of the students learned about faculty projects by performing a web search, indicating that students were either unsuccessful finding project information via a web search or that a search was not attempted

Step 2: Design It

Initial Prototype

Using the hypothesis table as a guide, a prototype was created. A group partner with experience in UX design created a fantastic prototype in Adobe XD. Each group member created a page using the original design as a guide. Designs were refined internally within our group prior to the focus group.

Focus Group

A focus group was held with six students to provide feedback on our prototype. At the end of the session, focus group participants completed a paper feedback form and answered questions about page navigation, aesthetic choices, and the process for submitting information.

Overall, participants responded positively and requested additional features:

• Filtering option by project type and category
• Display details about area of research for professors
• Faculty contact information and faculty profiles
• Duration of project (e.g., one semester)

Step 3: Create MVP

MVP (Minimum Viable Product)

With feedback from our focus group, we determined the minimum functionality needed for our project to be considered a success.

Our MVP, created in Adobe XD, included the functionality for students to seach for faculty projects and submit an application. (For this project, an MVP was defined as a clickable prototype that could be developed into a fully functional product. Actually creating the product was outside our project's scope.)

Feedback was provided from our classmates and professor. The MVP was further modified prior to the user testing sessions.

Step 4: Research and Learning

Initial User Testing Sessions

The first rounds of user testing were conducted with 3 participants in 40-minute 1:1 sessions. 2 participants were PhD students at Cornell University, 1 participant was a PhD student at Princeton. The participants were chosen because of their involvement in higher education and plans to enter academia. As non-Syracuse students, their outsider perspective showed how a student unfamiliar with Syracuse would use iProject.

Sessions began with a short interview about the participant's experience working with faculty. Sessions followed a "think-aloud" format and users provided feedback on the aesthetic look of the website and stated how they would expect to complete an action. Users were presented with two different options for one webpage and asked to state their preference.

Findings

Test participants commented on the simple navigability of the website and use of color. However, both shared negative aspects, like the use of white space on some pages and the use of the phrase "wish list" for saved jobs.

The participants also noted additional information that could be added, like salary and application deadlines.

Changes to MVP

Following these initial testing sessions, the MVP was redesigned with updated wording, white space, project timeline, and application requirements. As all participants preferred one prototype, the less popular page design was removed from the MVP. The MVP was also modified to include the ability to click between pages.

Final User Testing Sessions

Later sessions were conducted with 6 participants in 1:1 sessions lasting about 30 minutes. All participants were graduate students at Syracuse University.

Sessions followed think-aloud protocol. Participants completed two test scenarios:

1. Submit an application
2. Add a job to "Save for Later" list

Sessions were recorded using Morae and users were timed on how quickly and easily they completed tasks. Participants also provided general feedback on the prototype. After the think aloud session, participants completed a short survey about their experiences using the prototype.

Limits of Prototype

3 participants had difficulties completing the tasks due to limitations with the Adobe XD prototype. While the prototype was responsive and linked pages, it was not possible to enter text or view the details of every listed project.

An additional limitation of the prototype was that the prototype is not in a browser window, so people had trouble going back a page. Given that the back button is the most used button in browser windows, having a browser mockup would make a more realistic experience.

Analysis

Following user testing sessions, results were analyzed, and a list of potential improvements was made. While implementing the improvements was outside of the scope of the class project, the analysis may help develop future products.

Session Data

Participants completed Task 1 (submit an application) with a range of 21-120 seconds. Task 2 (add a job to "save for later" list) proved easier for participants and was completed in 9-31 seconds. Task 2 may have been completed more quickly because participants were more familiar with using the prototype.

Key Findings and Recommendations

Provide feedback when an application is successfully submitted.
This aligns with principles of good form design, providing positive user feedback upon form completion.

Add salary information.
This echoes early comments made by P1 and P3, indicating pay details is a desired feature.

Make some aspects of the website smaller.
The two columns on the "My Applications" page should be reduced to display more information. This will allow users to skim the website more easily without needed to switch pages.

Add faculty information.
A faculty page could be added so users can view all of the current projects for one professor.

Add an option to save an in-progress application.
Some participants stated they might not complete an application in one sitting and wanted the option to save and complete the application later.

Reflection

This was a fun project and I feel lucky to have been part of such a great team. Surveys, a focus group, and user testing sessions indicated students are likely to use a product like iProject to find and apply for faculty projects, and my hope is that our research goes beyond the classroom. Here are my takeaways:

1. Have a plan B. Our focus group was held during a Syracuse snowstorm. Not only did we have fewer participants than expected, but the participants who braved the storm understandably arrived at different times due to travel constraints. It was difficult to have a cohesive session and get clear feedback. With the benefit of hindsight, we should have rescheduled the session or held the session remotely.
2. Work as a team from different locations. Google Drive was a great tool for sharing data, user testing videos, and writing the final report. I've since used it for other projects as a project management tool.
3. Start small. Our initial prototype was stunning. However, had we started with a low-fidelity prototype, it would have been easier to incorporate feedback and would have saved time overall.
4. For later user testing sessions, make the experience as realistic as necessary to get beneficial data. Users tend to get confused if buttons don't work, fields can't be filled, or the prototype doesn't look like a website. In our case, it may have been beneficial to explain these constraints to our research participants before testing sesions.