MSU People Finder App

Problem

The current MSU People Finder site provided students the ability to search for information on faculty, staff, students, and retirees for information such as addresses, email, and phone number. Even though its intended purpose does its job, the use is limited. Once a student finds someone, they can only take limited action. Students can receive information such as email, but communication and action will happen somewhere else, and students or faculty might even have some of their information limited on the site.  The redesigned application needed to have not only the same information, more customized and find-able, but actionable on the information provided.

Methods

To make the application a little more useful to students and faculty at Michigan State, I quickly collected information on MSU’s resources that could be combined or created with the new People Finder App. A lot of times, I noticed that students often get information from the site to contact professors about meetings, or even find their office. Once I found these two spaces that could fit into the design, I rapidly created wireframes, received feedback from my peers and stakeholders, and then iterated my designs to flesh more of the process out.

I created the application so that students or faculty using the site could easily access information about their peers, add them as contacts, and look up information, such as office placement on a blueprint, and set up meetings with the people they are contacts with.

IMG_2149

Iteration

After my paper wireframes were completed, I created a paper prototype of my application to test. The paper prototype was created so that it could fit into a participant’s hand, like a regular phone, and the screens, with specifically colored buttons and text (green for links, purple for user-submitted information, etc.), and changing paper screens so that I could evaluate the architecture and the overall flow of the application.

IMG_2144

video-paper-prototyping

I tested the screens on multiple people, and received very useful feedback on the entirely of the screens. For example, I found that:

  • The search vs. find people label threw participants off.
  • Placing an emphasis on using the app to find an office or set up a meeting would help people find value.
  • Add vs. Save was not useful/confusing.
  • The plus sign during people search didn’t make a lot of sense there.
  • Having the same profile page with additional information (such as the ability to set up a meeting) would make more sense.
  • Users should be able to customize who can see what type of information.
  • Emphasize meetings/directions instead of just “contacts.”

Product

wirefranes-final-pplfinder-20

I added the feedback to its final form, which was an interactive prototype that allowed users to navigate between the application through the scenario, which was to:

  • Type in their professors’ name:
    • Hudson, B
  • Choose one of the professors
  • View information on their office hours, their location, and contact information. There, they could set up a meeting.
  • They could choose time, location, and to add more context for the meeting.
  • Send the request and search for more contacts.

I completed more rounds of usability testing and added the feedback to the final product, which was created using Adobe Experience Design.

Learning Experiences

Throughout this experience, I was able to learn a lot about creating interactive technology for mobile and filling in the needs of users throughout one product, instead of a million little sites. As I created each iteration and version of the MSU People Finder app, I learned the importance of getting eyes on products early and often. Sometimes, people only show the final product to users, and don’t take the time to create a simpler version so that usability issues, the overall helpfulness of the app, and information architecture can be effectively evaluate. Then, when more eye-catching versions are made, the overall product is made to work best for the user.