Campus Plus
Google Design Exercise
Design Brief
Your school wants to improve the upkeep of campus facilities by creating a new system for reporting any facilities that may need maintenance or repair. Design an experience that allows students to report building or equipment issues on campus. Consider the process of those filing the report and of those receiving and taking action on the issues.
Deliverable
A system for reporting any facilities that may need maintenance or repair
Duration
1 Week
My Role
Research
UX Design
UI Design
Design Process
I had only 1 week to complete the design exercise so I decided to follow the model of design sprint to make most of my time. I started by understanding the context. I identified problem areas within the existing system. Then I went on to ideate what all can be done to solve these problems. From a pool of solutions I selected few that were most effective. Then I moved to the phase of prototyping. First I created low fidelity wireframes followed by high fidelity design.
Understanding Context
First I had to understand how maintenance or repair issues are handled in colleges. I got my hands on policy statements of few colleges about maintenance and repair service. This is a topic of concern in educational institutes as smoothly running environment is important for learning.
While reading about maintenance management I came to know there are three types of maintenances:
Routine maintenance (Planned in advance)
Preventive maintenance (Planned in advance)
Corrective maintenance
Issues falling under corrective maintenance can occur unexpectedly at any time. It is difficult for maintenance team to identify campus wide issues right away. Here, student community can help maintenance dept. by reporting any issue they come across.
Since the maintenance department can improve its performance with the active involvement of students, I need to come up with a solution that
Enable students to report any issue with ease
Enables maintenance dept. to organise and resolve all the reported issues
These two points became the high level goals. They acted like anchor points throughout the design process. Every time, I had to make any decision I turned to these for direction.
Who is the user?
My college, National Institute of Design (Bangalore) is a small college with a one acre campus and total of 150 students. The maintenance department in NID is a team of two people. To understand more about users, I conducted survey and user interviews within the college.
Results from the user survey
It showed that almost 3/4th of the students have never reported any issue, but when I talked to students one on one while taking user interviews, everyone said they had come across issues. It is just that they never reported about it. This response from majority of students made me curious. To dig deeper, I used the technique of ‘5 Whys’ and probed students further why they didn’t report it to maintenance department. I got some pretty interesting insights. It allowed me to go deep and get to the underlying problems.
Why students don’t report issues?
As mentioned in the diagram, there are multiple reasons why students think even if they report an issue, it won’t get resolved. I also talked to students who have reported issues in the past. I found out that even if students want to report an issue, the process is not very considerate about them.
To figure out what are the other challenges in the existing system I decided to make a brief journey map. It covers how students report issues right now and how maintenance department attends to them.
Brief Journey Map
Problems faced by students:
Student has to visit maintenance department to report an issue. This is inconvenient because if admin isn’t available they either have to wait or go again.
When a student reports an issue in person, he/she feels like a bearer of bad news. Some students also said that the interaction between admin and them felt a bit investigatory.
Once the issue is reported, student is not notified about what action is being taken. Sometimes student follow up with the admin but other times they just keep wondering if the issue is being resolved or not.
If admin says he can’t take any action because of budget constraint or any other reason, there is nothing a student can do.
Problems faced by maintenance admin:
Being a small department managing all the issues coming their way is an overwhelming task for them.
Everyone who reports an issue wants to see their issue getting solved as soon as possible. In some cases, admin have to get permissions and budget approval from higher authority. Students are not aware of all the things admin have to take care of and expect instant results.
Admin prioritises the issues depending on their urgency. While doing so low priority issues get moved down on a task list and tend to get delayed or ignored.
It is difficult to keep track of all the requests without a centralised system.
HMW Questions
After learning about problems faced by students and admin of maintenance department, I decided to turn these problems into opportunities. To do so I condensed the problems in a form of HMW questions.
HMW Questions
After writing HMW questions, I selected three questions that I wanted to focus on.
HMW encourage students to report maintenance related issues?
HMW help maintenance dept. to manage the raised issues?
HMW allow students to appeal for the requests denied by the admin?
Then I started brainstorming solutions to solve these problems.
Finding Solution
Before jumping into sketching, I took a step back and started thinking if I want to make a mobile based application or a web based application. Generally speaking, mobile apps are more popular than web apps but I had to consider the problem I was solving before making a decision.
After some research and thinking, I came to a conclusion. A system that is going to be used by students to report maintenance issues should be web based. Primary reason is all students will not install a mobile application that is not going to be used by them on a daily basis or even weekly basis. On the other hand, web application doesn’t need to be installed and can be viewed on variety of devices. After deciding that it is going to be a web based solution, I pulled out papers and pencils and started sketching my ideas.
Ideation Through Sketching
Storyboard
To understand how these ideas will come together in a solution, I visualised two user scenarios. First one is where a request raised by student. It is accepted by the admin and issue is resolved. In the second scenario, request raised by student is declined by the admin then the same request is re-raised with the support of multiple students.
1st User Scenario : A request raised by student is accepted by the admin
2nd User Scenario : A request raised by student is declined by the admin
User Flow
After storyboarding, I got a clear idea about the user flow and what features to be included. To illustrate it in an organised way, I created user flow diagram with low fidelity wireframes.
Low Fidelity Prototype
Log In
It’s a standard log in page. On the left it shows the name of the portal and tagline. I came up with a name ‘Campus Plus’ as the portal is all about upkeep of the campus. The tagline ‘We will fix it”, gives a sense that maintenance department is proactive in their work. Students can log into the portal using their college email ID and password.
Home Page
After logging in, student will come to home page. Main objective of the portal is to allow students to report an issue. Therefore the layout is kept very minimal putting emphasis on the task of raising a request. Page shows two ways of reporting an issue. First and a common one is by clicking on a button to raise a request. Second one is meant for emergency cases. Students are advised to give a call on a mentioned number. Navigation bar on the left shows options like past requests, appreciations and contact. Top right corner has message, notification and profile of the student.
Raising Request
Once student clicks on the ‘Raise a request’ button, he will be directed to this page to fill a form. The form has only 4 required fields to fill and yet admin can get enough information about the issue.
First question is to select the category of the issue. Category can be plumbing or electrical or cleaning etc. Though knowing the category of a request is not a must for an individual request, it can help admin sort multiple requests into groups. Then student has to enter location of the issue followed by subject of the issue and brief description. Student can choose to upload a photograph but it’s optional.
Receiving Request
Admin will receive all the requests in his inbox. Each request has a thumbnail on a left. In most UIs it’s a profile picture of the sender, but here it is an icon showing the category of the issue as sender is secondary in this context. There are three buttons at the bottom of the message. This will allow admin to take an immediate action on the issue. If the request is ambiguous in any way, admin can message back to the student using reply.
Creating a Task
If admin accepts the request, a vertical block will appear on the right side of the screen. Here, admin will assign priority to the task. It can be high, medium or low. Next he will assign a technician for the job. He will get suggestions of technicians from the database. Lastly he will pick a due date and create a task. As soon as task is created student will be notified about the status of his request. This task flow will make sure, that no request will be lying in the inbox waiting to get resolved.
Task Manager
Admin has to manage many requests at a time, so the task manager will help him track all the requests. All the requests will be shown in a tabular format. Each row will be dedicated to one request. It will show request no., subject of the request, category, location, priority, current status, assignee and time to resolve. Admin can filter the requests based on category, location, priority and status of the request. This way admin can see what’s happening with different requests at a glance.
Prototyping
After low fidelity wireframing, I moved to high fidelity design. To decide the look and feel, I turned to photographs of maintenance work and my college campus. Though the maintenance work is grungy, it strives for clean, smooth running campus. I want users to get that smooth running feel on the portal.
UI Design
Prototype Video