Google Design Exercise

The problem statement:
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.
Overall Process:
Initial thoughts
Problem space research
Comp. Analysis
User interviews
(friends/professionals)
High-fidelity interactive prototyping
User testing
Wireframing
Feature definition
Brainstorming... Musings...

Perhaps because of my background in architecture, I was very intrigued by this problem because there's a spatial element involved to reporting problems within a campus. I started brainstorming questions to ask students about their motivations, frustrations, etc. during a reporting process.

My most imperative question:

Beyond simply wanting something fixed, what motivates students to report a problem and how do I design around encouraging that motivation?

A secondary question:

What type of information and information format is most useful to the facilities department at Berkeley?

Problem space research + Competitive analysis

Before I get to user interviews, I want to understand the problem space and how maintenance requests are submitted in general. What types of problems are reported in campus environments and how are they usually submitted? I conducted a brief competitive analysis to see what kinds of information maintenance teams on different campus collect when a report is submitted. I looked at Berkeley (my school), Stanford, Cornell, University of South Carolina, University of Nebraska Lincoln, etc.

Common Components of an Average Maintenance Request

Problem description + photo

Contact information

Location description

Categorization of Problem

Potential Design Implications

Find some way to clearly mark or identify problem

Collect student information (perhaps automatically if logged in?)

Find a way to clearly identify the location of the problem (maybe a dropdown of locations or potentially a map view feature)

Present category types to user

Distinction between Emergency vs Normal Work

Provide a way to input urgency level

Berkeley's Confusing System

So Berkeley was a bit of a wild card in terms of facilities reporting design. Compared to the other schools, Berkeley had what seemed to be two separate places to input a work order - neither of which was easy to locate. The path to discovering these maintenance request forms was convoluted. When I asked a couple of friends to attempt to find them, they gave up and resorted to Google which led to the forms faster. 

The image on the left is a screenshot of the Facilities Services home page. Yeah, I know, it's a really small image but trust me when I say that it is NOT clear for me or for others as to how to submit a maintenance request.

FINALLY when you find the place to put in a work request the "form" is actually an email address. There's no instructions on what kind of information to provide.

Method 1: Filing an email for general campus maintenance

Again, same deal. No easy way to find where to submit a maintenance request - which makes sense on the housing page because there are a lot of other priorities they might want to emphasize on their home page. The lack of clear direction doesn't make as much sense on the "Facilities" page from before, though.

We only found the "housing" maintenance request form because Google took us there...

We found this form for Berkeley students to submit a maintenance request for their specific housing units.

Method 2: Maintenance Request through Housing Department

So, okay, it's a bit of a mess and there are severe discover-ability issues. But it's highly intriguing to me that Berkeley decided to distinguish maintenance request forms for facilities that personally affect students from "general" campus requests. Is there some rationale behind this?

User Interviews
The Facilities Department at Berkeley

I tried to calling the Facilities department on two separate occasions and ended up emailing them with my questions - but I couldn't get a hold of anyone! I considered calling other campus departments but I felt that the competitive analysis of several schools gave me a "good-enough" proxy for determining what type of information the maintenance department might generally need. If I had longer I'd try getting some actual people to talk to.

Three Students and Their Experiences

Since I'm designing an experience FOR students I focused my efforts more on getting a hold of students to interview. I screened for students that had reported or considered reporting a maintenance issue in the past. The interviews were semi-structured with fairly broad questions. One thing became very clear:

There is a clear difference in how students feel about reporting a maintenance issue that directly affects them (leaking window in their dorm unit, creaky bed frame, wobbly door knob) versus a general campus issue (broken faucet in a campus bathroom).

Here's a comparison chart of just how different their opinions are on these two types of maintenance requests:

When it comes to general campus maintenance issues...

When it comes to problems that directly affect the student...

The inconvenience of submitting the report often outweighs the desire to help improve the campus

Students are much more patient about bad/convoluted maintenance request forms because the issue is important enough

Students don't know who to talk to in order to fix the issue

Students will search multiple ways to get the issue resolved

Even though they might care, students generally assume that the problem is already known and that someone else has already reported it

They assume responsibility for reporting the problem

Students don't care about knowing the status of the request and definitely don't want to be contacted later

Students want to track the status of the request and are careful to provide accurate contact info.

These differences suggested that there might need to be two tailored design solutions for these two types of situations. It became pretty clear that even if the UX for filing housing maintenance reports at Berkeley isn't great, students didn't mind very much because they are willing to put up with a less-than-stellar experience as long as they feel their issue will be resolved. If I wanted to focus on that experience, I would focus on making sure that the student feels confident that their issue was received and to better display the status of their request.

However, since the problem statement was to design an experience to help students report the issues for ANY facilities, I wanted to tackle the problem of facilitating reports about general campus facilities since right now, the existing system more or less 'works' for students who report housing issues.

It is currently more critical to design an alluring, easy user experience for general campus maintenance request submissions than it is for housing/student-specific maintenance request forms

How do we balance students' intrinsic desire to help improve the campus with their averse attitude towards inconvenience?

Design Constraints from User Interviews

01

Inconvenience should be minimized, speed and ease should be maximized

02

Avoid requiring a lot of effort to find out where to report issue and make it clear that the issue has or has not already been reported

03

Some students want to document the issue in a way that they believe will help maintenance clearly identify the problem - as long as it doesn't take a lot of effort

04

Don't require personal information when reporting these kinds of issues

Super Simple Personas

I don't feel that my time speaking to the three students was enough to develop truly deep and rich personas - but for the purposes of building empathy I've crafted these two VERY simple personas.

Paper Prototype
The Paper Low Fidelity Wireframes

Because the reporting forms are all accessible online, I figured I could try slightly redesigning the home page for the Berkeley Facilities page to make the form more easily accessible:

The Results

I tested these quick paper prototypes on my three friends I initially interviewed. The biggest finding is below:

The students felt that they would not go through the effort of finding and opening the form on their phone for a general campus issue.

They particularly pointed to the input fields. One student said that it's annoying typing a long description on her phone, and she definitely would not use her laptop to report a broken sink. Another said that it might be annoying to have to figure out how to specific the location.

The Physical Prototype
The Concept

I began to suspect that asking students to use their phone to navigate to a form was seen as too much effort for these types of general campus issues. I then began thinking of the low-effort satisfaction rating surveys seen at airports.

Ideation + Wireframing

Because this type of kiosk seemed to be successful at encouraging users to voice concerns about an airport (which you might argue has less personal connection than a campus to students), I figured a similar low-effort interaction might work here. I tried out different flows...

I also wanted to provide a low-effort way to identify the specific location of the problem in a fun, interactive way for those students who wanted to feel more involved in the identification of the problem

Storyboard

Anne visits the women's restroom to wash her hands

She is frustrated the sink is broken

She thinks "they probably know, but they should fix it"

She moves to another sink to finish washing her hands

As she finishes and is about to leave, she notices a sentiment poll

She indicates that something is wrong

Final Result

She indicates that it's water related

She figures they might need more info, so she places a tag on the sink that's broken

She leaves with a sense of having helped the campus

01

02

03

04

05

06

Although I didn't have time to thoroughly test this, the surface-level responses I got was that the participants felt that this method seemed fairly low effort and that they would be more likely to report problems through this system

Copyright © 2019, Julia Park

julia.park@berkeley.edu