Community Issue Reporting

A great residential community (e.g. condominium, college dormitory, etc.) provides a variety of amenities and a dedicated staff responsible for its maintenance . But there isn’t always an easy way for community members to report problems to management so they can be resolved quickly.

Task

Design a system for a community of your choice, so members can report issues and track their resolutions. Show your process and how you arrived at your solution. Please include a sequence of high-fidelity mocks from your design solution.

Approach:

1. Explore the problem space - mindmap

2. Specify a real community

3. Interview students and janitor

4. Reveal pain points

5. Create a student profile

6. Create a user journey map

7. Create user stories

8. Derive features

9. Create service blueprint

10. Define MVP scope

11. Create flow diagram

12. Create wireframes

13. Create app name and visual design concept

14. Create sample set of hi-fidelity mockups

15. Test UI’s, flows and visual design

16. Improve features, flows, design and UIs based on Feedback

17. Show new and improved sample flow with hi-fidelity mockups

2. Community Specification

• I work in Karlsruhe, Germany, and since it’s a college town with around 50.000 students, I chose a student dormitory for my project.

• I picked the “Europahaus” dormitory, because it is international and has an array of amenities like a self-service laundry, a bike workshop, a photo laboratory and a music rehearsal space.

• The Europahaus features around 200 single rooms, 5-7 people share a kitchen and restroom.

• It seems to be a system complex enough to introduce an issue reporting app.

3. Student and Janitor Interviews

4. Support Flow Pain Points

1. Janitor availability was described as very insufficient by a great majority.

2. Important information handouts are available in German language only.

3. The parking situation near the dormitory is difficult, and it makes moving in an out a bad experience.

4. Since the janitor is hard to reach, there’s only little feedback about broken light bulbs and other common objects, which again leads to a dormitory experience that is not what it could be.

5. There’s no booking system in place for the music rehearsal space, the photo laboratory and the workshop, so there’s no support for scheduling events with friends.

5. Student Profile

In this chapter, I’ll introduce Rebecca: she’s a fictional student character that combines the traits and needs of the young people I’ve talked to. We’ll see the world through her eyes when depicting her journey and telling her (user) stories.

Rebecca Petry, 19

• She’s a young woman from the Netherlands, graduated from high school just recently and speaks English at a moderate level.

• Since she applied for an international study, it can be assumed that she is open minded and appreciates social contact and new experiences.

• She plays keyboard and guitar, and she enjoys jam sessions with friends as well.

• Always carries a smartphone, and she’s adept at using it.

• It’s likely that it’s an Android device, since it’s the most popular OS in Europe and not as expensive as an iPhone.

• She’s native to calendaring apps and scheduling processes, and she’s an active WhatsApp user.

6. User Journey Map

7. User Stories

These user stories are derived from interviews, pain points, my experience with support tools and processes (I used to be a support tool UX Designer for 6 years), the competitive research and my best guess about additional scenarios that might be valid for Rebecca.

1. As a student planning to live in the community, ...

1. … I’m required to schedule a check-in appointment with the janitor, so that I can receive the keys and get an introduction to the rules and features of the dormitory.

2. …I want to learn about the existence of this awesome new reporting app before day 1, so that I can use the app’s benefits even before moving in (e.g. making and appointment for the check-in).

3. …I want to be able use the maintenance access road when I move in, so that my transport can park close to my apartment and my move is as easy and quick as it can be.

   
   

2. As a student living in the community, ...

1. …I want to be able to report broken appliances, so that I can continue to use them.

2. …I want to be able to report an emergency (e.g. water leakage, lost keys etc), so that I can get help quick.

3. …I want to reserve the music rehearsal space or the bike workshop, so that I can plan a jam/repair session with friends.

4. …I want to be able to request specific services to help me with issues I have, so that I can continue with what I was doing.

5. …I want to be able to report empty consumables, so that I can continue to use the service soon.

6. …I want to be able to see if or when washing machines are free, so that I don’t need to waste time going there myself.

7. …I want to leave feedback about what I think could be improved in the community, so that I can improve the experience for us all and be a happier community member.

8. …I want to be able to direct my feedback to a higher instance (e.g. the site manager), so that I can address issues that can’t be taken care of by the crew on premise, e.g. suggesting new services or filing complaints about processes or crew members.

9. …I want to be notified when service outages or other general incidents come up, so that I can adjust my day accordingly.

   
   

3. As a student reporting an issue, ...

1. ...I want to be able to express the urgency of the issue, so that I can influence the priority in which it is addressed.

2. ...I want the issue reporting process to be simple and fast, so that I can save time and go on with my day as soon as possible.

3. I want to be able to switch to my or at least the English language in case I’m a foreign student, so that I can use the benefits of the app as well.

4. I want to be able to access the service from any device, so that my chance of being able to report issues or emergencies is as high as can be.

   
   

4. As a student having reported an issue, ...

1. ...I want to get feedback whether or not my issue will be taken care of, so that I know that I can lay this topic to rest for now and take care of something else.

2. ...I want to be able to track the status of the issue, so that I can reassure myself that it’s still being taken care of and check if delays occur.

3. …I want to be able to use a contact channel between me and the person assigned to the issue, so that I can give updates or re-schedule appointments, or so that I can be asked for additional details as well.

4. ...I want to know in which time frame the issue will be resolved, so that I can better plan ahead.

5. ...I want to get alerted in case the expected resolution is delayed, so that I can adjust my plans accordingly.

6. ...I want to get notified when the issue is resolved, so that I know when everything is back to normal.

7. ...I want to be able to influence the time when the issue is taken care of (e.g. when there’s a broken appliance in my apartment) so that I can prepare for the visit of the service personnel and find a time that is convenient for me, and I also might need to reschedule an already made appointment.

8. …I want to give feedback on my support experience, so that I can raise critique or praise the service and therefore confirm or improve the experience for me and my fellow students.

8. Deriving Features, Integrations and Action Items

In this chapter, I’m shaping the functional scope of the new app based on the user stories above.

Feature: Sign-Up

• Issue reporting, scheduling meetings, notifications and room reservations are much faster when the student is registered with the app - personal /room/location/permission/language data needs to be filled in only once. (Derived from 3.2)

• The service should be at least partially usable without registering. This makes the app helpful right away, especially in case of an emergency. (Derived from 2.2).

Feature: Issue Reporting

Primary Elements:

• In order to trigger a support action, students need to create a ticket by reporting an issue. This can be done willingly (e.g. by reporting an issue in the app, or it happens in the background, e.g. when calling an emergency contact or scanning a QR code.

• Each ticket serves as a container for the created artifacts from the support session, e.g. the ticket history, a chat protocol, photos, etc. (Derived from 4.2, 4.3)

• A regular ticket can contain the following information: ticket ID, reporter, an assignee, the student ID, room number, title, description, ticket status, issue type, timestamp, desired resolution time frame, a priority estimation, a chat, photos and QR code information. (Derived from 3.1, 4.4)

• The support crew prefers to receive sufficiently documented issues in text form, but is willing to accept direct calls in urgent cases. So, the app should support these scenarios.(Derived from 3.1)

• An emergency like a broken water pipe must be handled with top priority, resulting in a direct call with a 24/7 service instead of filling out a form. In parallel, the simplified location tracking ticket creation is ideal to 1) help service personnel confirm their target location and to 2) quickly file a support document that assists the reporting person during the process.(Derived from 2.2, 3.1, 3.2)

• When the currently set language is not spoken by the crew on premise, the app could offer a translation service inside of the chat area.
  

Secondary Elements:

• Because the janitor would like to promote to report issues in the public outside areas, a specific, simplified ticket creation process consisting of a photo and location information could create a ticket in the blink of an eye and removes the pain of filling in a form. (Derived from 2.4, 2.5, 2.7, 3.2)

• A ticket for public space issues can contain a ticket ID, photo, reporter, a tracked issue location, a description,

• Having an empty consumable refilled doesn’t need to be a cumbersome process: scanning a QR code with the app files a support ticket instantly, and no other actions need to be taken.(Derived from 2.5)

Feature: Issue Handling

• Once an issue is reported, the students need to be able to get back to it or other previous reports, so that they can check what their status is and access a communication channel with the assignee. So, a ticket overview needs to be introduced in the app

• Even though some students stay for many years, it’s not likely that a large amount support requests needs to be managed on the student’s side of things. Interviews suggested a rough ratio of about one issue per year. So, a simple overview without advanced sorting or filtering options should be just right for the initial draft. (Derived from 3.2)

Feature: Communication Channels & General Notifications

Primary Elements:

• Once a ticket is created, a ticket-specific communication channel between the student, the ticketing system and the assigned care taker needs to be established. (Derived from 4.1 - 4.8)

• This can be a chat section inside of the ticket entity (Derived from 4.2 - 4.7)

Secondary Elements:

• The ticketing system could also use push notifications in case ticket status changes take place, or in case the assignee needs more information. (Derived from 4.2 - 4.7)

• Push notifications could also forward catastrophe warnings from 3rd party services.(Derived from 2.9)

• Also, the student could choose to talk with the support chatbot in a more familiar environment like WhatsApp.(Derived from 3.2)

• Email communication should be used to address account verification, important notifications or information exchange between the student and the assignee.

Feature: Multi Language Support

Primary Elements:

• Since international courses are held in English, it can be assumed that every student should be able to handle an English version of the app. (Derived from 3.3)
  

Secondary Elements:

• Since this is an international dormitory, it’s most important to offer a solid set of languages to choose from. The more, the better - in case of an emergency, it’s all about efficient communication.(Derived from 3.3)

• When setting up the experience, the language selection can be a part of the account creation step, but in the logged out state, the language could be auto detected and changed manually in the settings (Derived from 3.2, 3.3)

• However, the crew on premise can speak only so much foreign languages. So, students with languages other than the officially supported ones should be able to use a translation service in a chat conversation that might be held in e.g. English.

Feature: Web-Based Version

• It’s an advantage in terms of availability when a service is accessible from any device, so a web-based service makes sense

• However, since every student carries a smartphone with them, and a native app has a more frictionless access to location tracking, camera, personal data and other apps relevant to the community (e.g. WhatsApp), a web-based version can be added at a later point of time.

Feature: Scheduling Assistant
Primary Elements:

• Integrate services like Calendly that allow for picking convenient consultation times on different topics . Provide predefined meeting topic sessions like check-in, check-out, gate key handover or a generic 5 minute talk. (Derived from stories 1.1, 1.3)
  

Secondary Elements:

• In another section of the app, use the same system to enable reservations for the music room or the bike repair shop (Derived from stories 2.3).

Feature: Laundry Utilization Status

• Since the laundry has smart machines already, an app could show their status and windows of opportunity, so that students don’t need to scout the laundry status by going there in person, sometimes in vain. (Derived from story 2.6)

Action Item: Promote the app before student moves in
Primary Elements:

• Each student receives a rental contract before moving in. Along with that paperwork, a dedicated promo for the app could be added.

• A simple URL / QR code on the promo paper allow for easy access to the app.
  

Secondary Elements:

• When registering for the support service, the app offers to connect to the user’s WhatsApp account, so that support requests or scheduling services can be used with the support chatbot of the Europahaus WhatsApp group.

• Idea: since the first thing that students might want to do with this app is to schedule a check-in appointment, the app could feature that option with a call to action when first used.

Integration: WhatsApp Support Chatbot

• Since every student is connected to the community via the Europahaus WhatsApp group, a support chatbot could be part of that group as well

• The support chatbot could offer services for scheduling or reporting an issue quickly. It’s also easy for community members to introduce the bot to newbies.

• This makes the service accessible within a very well known and highly frequented environment, without an extra app that needs to be downloaded or switched to.

9. Service Blueprint

This service blueprint helps to visualize the relationships between the different service components — people, props (physical or digital evidence), and processes — that are directly tied to touch points in our student’s journey.

10. MVP Scope

There’s a fixed deadline for submitting the exercise, and I need to focus on the essentials to complete the visualization phase in time. Like in real life, we’ll limit our ideas to form a basic set of features that offers a sufficient value proposition and then improve gradually.

Scheduling seems to be a secondary feature for an issue reporting app, but since the availability of the janitor service was a such a big issue, I think the automated scheduling functionality should be a part of the minimum viable product as well. This feature can also address the room booking pain points, which makes the app even more useful.

In scope for MVP

• Promote the app before student moves in (primary elements)

• App for Android and iOS (e.g. via single code base in Flutter)

• Ticket Management

• Ticket Creation (primary & secondary elements)

• Ticket Communication (primary elements)

• Emergency Issue Routing

• Scheduling Assistant (primary & secondary elements)

• English Version
  

Out of scope

• Promote the app before student moves in (secondary elements)

• Ticket Communication (secondary elements)

• Multi Language Support

• Laundry Utilization Status

• WhatsApp Support Chatbot Integration

• Web Version

• Service Feedback

11. Flow Chart

This chart reflects the MVP scope and helps to get a glimpse on the required interfaces, their hierarchies and interplay.

12. Wireframes

12.1 Sign-Up, Start Page and Emergency

• Sign up Flow

  Even if the user is not logged in, the emergency call option is still available.
  
  

• Start Page
  The start page offers quick access to the main features of the app.
  
  

• Emergency Call

  I categorized the 32 contacts on the emergency paper handout into four main sections for fast access.
  
  

• Additional Help in Case of Emergency
  Depending on the emergency type, a quick web link with hands-on help on the topic could be offered, e.g. a first aid instructions page.

12.2 Reporting an Apartment Issue & Accessing Issue Details

• Empty State

  Some words on what can be reported and what will happen then, as well as a call to action.
  
  

• Issue Type Selection

  The quickest way to report an issue depends on its type. Some type require more or different information than others. So, instead of offering one form that fits all, smaller, individual forms are presented that match the issue at hand.
  
  

• Issue Details

  The details of an issue are split into tow parts: the info contains the gathered issue data, while the chat & activity tab contains sent system messages and status updates in combination with a potential chat conversation between the student and the janitor. So, the janitor has an easy way to request more information, and the student can follow the issue history and ask questions or give updates to the janitor.

12.3 Reporting an Issue Outside of Buildings

Fast and Easy Outside Issue Reporting

Since it takes a while to describe what exactly broke in which place on the premise by typing a text on a smartphone keyboard, this new method of reporting has some advantages.

By taking a photo of the issue, a ticket with location information is automatically created - the students can then go on with what they were doing almost instantly.

This simplified approach to issue reporting requires very little effort, and it’s more likely that students will report issues in public places. This can result in a cleaner, better maintained environment and ultimately in happier community members.

12.4 Reporting Empty Consumables

Request a Refill by Scanning a QR Code

Instead of filling in issue forms, a simple scan can say say more than a thousand words and requires no user input at all.

The user scans a code that is shown in every consumable location right from the app, and the request is sent automatically.

12.4 Reporting Other Issues

• The “Other” option is for everything that doesn’t fit into the previous categories.

• A standard issue form is shown to describe and rate the problem.

12.5 Checking In

• By integrating a calendar scheduling assistant like calendly, the check-in procedure can be handled quite easily.

• The janitor just needs to define some time segments in his week for the offered services, and then, students can book them.

• The scheduling service automatically manages the calendar entries in the janitor’s calendar, sends confirmation emails to the students and provides .ics files if needed.

12.5 Reserving a Room

• The same scheduling service as for the check-in can be used here

• Just public rest periods need to be considered when offering time slots for the rehearsal space.

• Inside of the bookable rooms, some information about the app and needs to be displayed, and it needs to be mentioned that people with a booked time slot have priority for using the room.

12.6 Notifications

This area is used for

• General service outage alerts

• Smoke detector test announcements

• Local catastrophe warnings

13. App Name and Visual Design Concept

App Name

I liked the ambiguity of the term “What’s cracking?” when put into the context of a service for reporting broken things. So, “WhatsCrackin’ ” is a snappy name, and it’s also close to “WhatsApp”, which is the primary tool for communication amongst the students of the dormitory.

Visual Design Concept

• It’s a purely functional app like an email client or calendar, so information should come as straight and crisp as it can.

• The transition between the pages should be smooth and meaningful. Navigation can go from left to right, or objects could be dropped into the context of a follow up screen.

• A minimal reference to the app name can be established by introducing a slight, crack-like shape or color transition in the background. The “Crack” background should be very light and subtle, but still distinct enough to suggest an appealing notion.

• The app is used by young students, so a little pun here and there won’t hurt. Instead, a little lightheartedness can strengthen the bond with the app and makes it more likely that it is mentioned or even recommended to other community members. This results in more reports of issues in the public spaces, making the dormitory a better place to stay for the entire community.

• I’m using iconography to improve the reception of the offered choices. Having a nice twist with some of these icons can also be a subtle way to implement the above mentioned lightheartedness.

• Of course, text contrasts should conform to WCAG AA standards.

14. 1st Pass: High Fidelity Mockups

This is the result of a first set of iterations. It shows a sample flow for reporting an outside issue.

15. Paper Prototype Tests

• I spent a lunchbreak at the Europahaus main passage again, equipped with Amazon gift cards as an incentive

• I asked students to imagine a scenario in which support was needed (e.g. broken things, empty consumables) and then watched them go through the paper app

• Since the reporting flows worked with a simple forward navigation, students had no problems navigating the app

• So, their feedback referred more to individual screens and features:

  • Outside issue reporting: students would have liked to be able to enter additional text in case the photo was not sufficient enough to describe the problem

  • “Lost and found” could be an extra item, since package delivery was chaotic sometimes.

  • I also asked them about the visual design, and in general, they liked it and described it as “fresh, simple”, but also “neutral”, like in “meh”. One student said it could be more funny, e.g. a Comic Sans font could help to achieve that.

16. 2nd Pass: Visual Design Improvements

Iterative Design Exploration

I followed an indication that the design was too neutral and could use some spice. Although I wouldn’t use Comic Sans as recommended by a student, I still tried to make the design pop a bit more.

These screens show iterations on the initial design.

Final Design

I arrived at a version that works with a high contrast UI and truncated visuals to create more visual tension.
I also refined the motion design to create a fluid and dynamic impression.

End of Case Study