Project Description
The goal of the project is to design an experience for students at Arizona State University to report on any facility that needs maintenance or repair to improve the upkeep of campus facilities. The scope of this project will cover the user side of the experience: students and staff who will be reporting, while taking into consideration the needs of the stakeholder "the facility admin."
Methods
Ethnographic research, Rapid prototyping, Heuristic Evaluation, Task Analysis, User persona, Competitive Analysis, User flow, Wireframes, Sketching, Brainstorming, White boarding
Project Team
Fully owned this project from research to final design, with interviews & feedback from actual users
Duration
1week
Tools Used
Figma, Adobe Illustrator, Photoshop
Research
I started by evaluating the existing channels available to students and staff to report an issue. For the students, surprisingly there were no formal channels to report a facility-related issue. Students seek help from the help-desk assistants (student workers) in facilities like gym, library and computer labs. For the other classroom-related issues they reached out to faculty and staff who were available in proximity. Few places like pantries and restrooms didn’t have any dedicated personnel to reach out. These locations heavily relied on scheduled maintenance to get things fixed. Learning this, I asked students to use the other channels available to them.
Understanding the user : Ethnographic research
To get a better understanding of the user and existing system, I walked around campus to get input from students. Participants were random volunteers who agreed to talk to me and a staff from my workplace.
Do you report facility issues? How do you report? (Students)
One of 5 users said that they will report issues and provided insight using one the three ways of doing that. First, on the back of student IDs are the information for the Live safe app and the helpline.
When asked to show how to use the Livesafe app, the student was unable to figure it out. The student said that even though he had the app installed, he had never used it before.
Finally, the user finished by saying that he would rather speak to a person like his faculty or staff.
How do you report facility issues? (Staff)
Following what the student user suggested, I asked the project coordinator in my department on how he reports an issue. Based on his response it can be classified as
- Formal channel: Through the university’s portal, he can raise a ticket or chat live for I.T. related issues and raise requests for facility issues using the form shown below.
- Informal channel: The coordinator said for recurring issues like ID access or housekeeping needs, he interacts with the same person who he is acquainted with through previous interactions so instead of raising a request he calls or e-mails the person directly to get things sorted. He also mentioned that he has some influence over how fast things get done since he is acquainted with them.
So, in a way he too preferred to talk to a person rather than filling out clumsy forms like the one below.
So, in a way he too preferred to talk to a person rather than filling out clumsy forms like the one below.
Understanding the needs of the user on the receiving end: Facility Admin
Moving on to the next option, I very hesitantly called the helpline because I assumed it was reserved for critical cases. After navigating through IVR for about a couple of minutes and waiting for another minute, I spoke with an operator who was kind enough to answer my questions and finally found some new information. First, all things that are reported as broken are inspected physically and attempted to fix by a university staff and if it is deemed not fixable a work order is raised to an on-call third party contractor who tries to fix it. Overall this takes about 1-2 weeks to fix if it is critical. Other issues take about a month and get fixed during the monthly visit. Second, I was able to get the facility admin's number and when I tried to reach him, no one answered the call. Two important things that the operator observed in general were:
Language barriers: People in a few cases didn’t explain the issue properly over a call leading to an oversight issue, example: a person reported a leak but it turned out to be a broken pipe that flooded an entire floor.
Duplicate issue: The university sends a Live-safe alert to students in cases like bee swarm sightings and sends e-mails for scheduled repairs, but students still raised issues leading to duplication of tickets. Resolving these duplicate tickets became a time-consuming task in itself.
Understanding the product ecosystem
After taking time to observe the user interaction in the current process, I sketched the whole process so that it's easy to visualize various touch-points in the whole process and understand the ecosystem in which the interface will be used.
User Personas
I decided to have two user personas, one for the student population in the university as it is so diverse with different needs and frustrations, and one persona for the facility admin.
Understanding how other products use Crowd-sourced reporting
Current challenges and potential solutions for reporting campus issues
No motivation for students to report issues
- Use incentives, leverage existing Sun devil rewards to give out points for using the interface.
- Use incentives, leverage existing Sun devil rewards to give out points for using the interface.
Lack of awareness on facility communication channels and how to use it
- Most students were unaware of the fact that helpline numbers are available behind ID cards. To ensure the interface doesn't meet the same fate, proper on-boarding and notification based interaction should be deployed.
- Most students were unaware of the fact that helpline numbers are available behind ID cards. To ensure the interface doesn't meet the same fate, proper on-boarding and notification based interaction should be deployed.
Solving the duplication problem
- By implementing location based suggestions, users can be prompted to check open tickets related to that particular location before they create a new one. Also, sending location based alerts can reduce the issue of ticket being raised in the first place. Student's class and lab schedule can be collected from Canvas app and it can be used to send them alerts on any potential problems before they even arrive in that locations.
- By implementing location based suggestions, users can be prompted to check open tickets related to that particular location before they create a new one. Also, sending location based alerts can reduce the issue of ticket being raised in the first place. Student's class and lab schedule can be collected from Canvas app and it can be used to send them alerts on any potential problems before they even arrive in that locations.
Multiple inputs to fix the language barrier
- Language can be a problem sometimes and collecting photos to compliment the request received might help overcome that barrier. Additionally, other students in the facility can be prompted to verify the issue and add additional details. Though the focus of this solution is for student users, non-teaching staff & faculty can be included to verify issues raised by students in their facilities.
Tedious procedure in filing report
- Students were not required to answer questions on their locations when raising issue through a staff or faculty but using helpline directly required them to know those information. Use location based suggestions, choose from list options rather than typing in data wherever possible. Also their email and contact information can be pulled from ASU app. One of the most confusing aspects for students was to figure out who the case should be assigned to, a better solution would be take location and keywords to auto-assign these to respective departments and the ones which are initially assigned wrongly can be re-assigned to correct departments by those handling the cases.
- Students were not required to answer questions on their locations when raising issue through a staff or faculty but using helpline directly required them to know those information. Use location based suggestions, choose from list options rather than typing in data wherever possible. Also their email and contact information can be pulled from ASU app. One of the most confusing aspects for students was to figure out who the case should be assigned to, a better solution would be take location and keywords to auto-assign these to respective departments and the ones which are initially assigned wrongly can be re-assigned to correct departments by those handling the cases.
Feedback channels
- Students who raise the issue themselves get a feedback and status of their requests, but those who file requests through faculty or staff have the disadvantage of not getting notified. Interface system should notify users of issue they raised and the ones they might be potentially affected by.
- Students who raise the issue themselves get a feedback and status of their requests, but those who file requests through faculty or staff have the disadvantage of not getting notified. Interface system should notify users of issue they raised and the ones they might be potentially affected by.
Multiple pathways to file report
- During the interviews and contextual inquiries one thing was very evident. Undergraduate students preferred talking and having natural conversations, but the adult audience and few people with autism whom I interviewed were more inclined to use the forms, even though the data collected were pretty much the same.
- During the interviews and contextual inquiries one thing was very evident. Undergraduate students preferred talking and having natural conversations, but the adult audience and few people with autism whom I interviewed were more inclined to use the forms, even though the data collected were pretty much the same.
Initial Sketch & Information hierarchy
The solution will have two parts. First, the main app interface that users can go to directly to fill out the details and submit the case. Second, an interactive chat bot that would extract details from the user and feed into the case dashboard system. This interactive chat bot extension can be deployed in existing apps students use like Canvas and ASU without a need to exit the app to raise issues. In both the user flows they get rewarded for interacting with the system. The flow also includes a mechanism to avoid duplication of cases.
Prototyping: Wireframes & User Flow
Based on the initial sketches I quickly blocked area on the screen for components in Illustrator and defined the user flow for the interface.
Color Palette
As the interface I am designing is for the university as suggested in the prompt, I chose to adhere to Arizona State University's brand guideline.
First Draft to Final Design
In order to get feedback on the structure of my case form, I quickly mocked up a submission form with required fields based on my initial sketch and took it to the user. A few pain-points I discovered were:
- "Building" & "Location": these terms had overlapping meaning and user got confused. My thought was that building would be the facility and location would be the exact area within that building but the users were clearly confused with that. Also, the combination of floor and room were too many in a few buildings which cannot be accommodated in a single "location" field.
- "Assign to" : When I gave users an imaginary scenario of ID access issue, most users expected it to be addressed by the I.T. or facilities department, but the university had a separate department for that. So I figured, keywords in description and location of the issue can be used to map out the department automatically using a predefined hierarchy.
-"Visibility" again was an ambiguous term and users said they won't be sharing their private information in most cases, so I redesigned that to a single radio button which enabled the user to make their requests private if they ever wanted it.
Some of the most common feedback was that it still felt like a paper form. So for my final design I used material design components to make it more interactive to user actions.
Initially some users were not sure why location, floor and room fields were at the top, when traditionally issue and description comes first. It was done so to avoid frustration for the user as well as the person receiving it.
When the user enters location details, the system prompts to check the existing open cases for that room. This way, all the user has to do was tap "+1" and add some more details to it if they like. Not having this prompt would result in duplicate cases. If the order of fields had issue and description first, we would have wasted some of the user's effort when the prompt gets them similar tickets.
When the user enters location details, the system prompts to check the existing open cases for that room. This way, all the user has to do was tap "+1" and add some more details to it if they like. Not having this prompt would result in duplicate cases. If the order of fields had issue and description first, we would have wasted some of the user's effort when the prompt gets them similar tickets.
Also, the idea was to limit the affordance of raising cases only when you are near a facility (something like geo-fence) which will be crucial to avoid students trying to raise issues for fun or just to earn pitchfork credits.
On-boarding screens for first use
Final Prototype
Interactive Chat Bot
I created a chat bot as the solution for my undergrad user persona. For this I took inspiration from google voice assistant. As I am designing for the university, I saw the opportunity to use the mascot "Sparky" the friendly Sun Devil as the face of the bot and used pitchfork credits for the rewards.
The idea is to deploy FAB (floating action buttons) on various apps already in use by students like ASU, Canvas and Sun Devil Rewards, as people might not be willing to use an app just to raise or report a facility/equipment issue.
Dashboard workflow
Displayed on the right is the interaction designed for faculty featuring a dashboard and form interface. It also demonstrates the interaction for fixing the duplicate issue.
Future Improvements
This version of the interface focused mainly on students and the ways to raise cases about facility and equipment, with some considerations on how to solve problems of people on the receiving end of the cases. Ideas I had in mind for potential future inclusion are,
- Including non-teaching staff and faculty in this process. Adding them to verify issues and implement verified tags.
Why? This is a student facing interface after all so there might be erroneous cases where the students raise issues to have fun or get pitchfork credits. Having some sort of moderation will keep those issues in check.
Why? This is a student facing interface after all so there might be erroneous cases where the students raise issues to have fun or get pitchfork credits. Having some sort of moderation will keep those issues in check.
- Including features to create cases when offline and upload them when users are back online.
Why? A few building have poor network coverage and in instances where WiFi is down, this could be a very helpful feature.
Why? A few building have poor network coverage and in instances where WiFi is down, this could be a very helpful feature.
-Trust score for students in the back-end, something similar to what ride sharing apps use. This can help reducing the impact of users notoriously raising false cases (to reduce false positive cases).
- There will be users who would still prefer talking to help-desk assistants. Introducing interactive kiosks near these help-desks can be effective. I would love to see if that would have an impact in facilities like the library and gym.
- In the computer lab facilities, users had to walk to the help-desk if there was any issue in their workstations. Having a localized reporting system where users can interface with local help-desk assistants could be helpful for trivial issues.
- A lot of the issue I.T. help-desk assistant gets are trivial issues. Testing the effect of having a knowledge base for these issues would be great.
