First, some exercises to get my head in the right space.
I usually fill out an opportunity canvas with the rest of the delivery team. I find that it's a good first step to get everyone on the same page.
Assumptions mapping is one of those exercises that I keep coming back to. It's a good way to prioritise time and effort for research, especially with projects where there are many unknowns.
Defining who we're building for
And of course, we can't start any project without first defining who we're making this for.
This is a good point to refer back to our assumptions map, and any questions we might have about the nature and context of our problem. Usually at the point, I would be working closely with a UX research specialist.
For most of our assumptions, these can be answered with user interviews. I prefer interviews on-site (where our users are, not where we are), so we can observe them in their own environments.
For quantitative measures, these are things that, if they do not yet exist, we want to start measuring ASAP to establish some baselines. Depending on how organised the building manager is in this case, we may also be able to establish some historical baselines from their record-keeping.
In the interest of time, I did not perform formal interviews. I did however ask my landlord (we live in a small, four-apartment building) how he dealt with maintenance, as well as a friend who had recently purchased an apartment.
The responses I got back were pretty casual, but that could be because of the relatively small sizes of apartment buildings. My landlord fixes things when he has time, and communicates via text, phone calls and email. There's not much method to the madness.
Here I've roughly mapped out example processes from the perspective of our three user groups.
Competitor analysis / Solutions today
Apart from generic planning tools such as JIRA, Zendesk, Trello, Airtable and Notion, there are no services for specifically maintenance issue reporting that stand out. (There are, however, plenty of overpriced property management software solutions.)
This doesn't mean that there should exist an issue-tracking tool specifically for maintenance requests, though. It's always important to consider whether a problem can be adequately solved by building nothing at all.
Their current solutions may include:
- Email/phone conversations and manual triaging and scheduling
- Form and spreadsheet
- Shared Trello board, or Airtable workspace, or similar
- A physical log book in a shared space
To make sure our solution is one worth using, I'll make a pro/cons list for our competitor solutions. Our proposed solution should aim to keep all the pros that current solutions provide, while bypassing the cons.
- People know how phones/emails/books work
- No set-up process
- Don't have to install Yet Another App
- It works
- Can't check things remotely
- Inefficient back-and-forth communications
- Need to bother someone to check status of issue
- Emails are stressful and calling people takes emotional energy
Web form + shared spreadsheet
- No set-up process
- Don't have to install Yet Another App
- Don't need to bother someone to check on status
- People generally know how a spreadsheet works
- Non-authenticated form opens up an attack vector for bad actors
- Form URLs need to be bookmarked — can't remember that
- Doesn't support images (you might need to take a photo of the issue)
- Requires vigilant upkeep by the building manager
- Spreadsheets are not the most user-friendly
- Privacy concerns
Shared workspace (Trello, Airtable, etc)
- Don't need to bother someone to check on status
- Access control comes with the service
- Generally pretty user-friendly
- Everyone needs to be using the same thing
- Need to decide on a service to use
- Some people will need to learn how to use a new app
- Yet Another App On My Phone
- Most likely will not fit with maintenance crew's workflow
- Privacy concerns
Requirements & constraints
From our research phase, we can infer that the following will be important to the success of our proposed solution:
- Needs to be easy to pick up / learn
- Needs to have some level of access control
- Needs to be able to calibrate expectations; i.e., know the status of an issue, know if someone has seen it, know when it's expected to be fixed
- Needs to be accessible across a number of devices
- Needs to conform as much as possible to existing workflows
As a resident in an apartment building,
I want to report issues with the building quickly and easily,
so that they can be fixed as soon as possible.
As someone who's just reported an issue,
I want to check up on the issue,
so that I know what to expect and when it might be fixed by.
Due to the time limitations of this design challenge, I will limit my focus on the experience for a single user group: residents.
On top of that, I will aim to constrain myself to the following:
- Minimal sign-up process. The act of reporting a maintenance issue is not a common occurrence, and when it is, is fairly urgent. I do not want a sign-up process to get in the way of reporting an issue.
- Minimal app contact. I want to enable issue reporting and resolutions with minimal process and mental energy around the reporting itself.
Furthermore, I have some initial thoughts around offering a Progressive Web App. People tend to be reluctant to install native apps, but are happy to visit a website in their browser. A PWA should give us the power of a native app, with the accessibility of a webpage.
However, PWAs come with their own technical constraints, especially on iOS:
App does not remember state between sessionsno longer the case
- No push notifications
- No access to Bluetooth, Touch ID, Face ID
- No background sync
- Service workers seem unreliable
(I'll design with iOS in mind for this design challenge, since it's the more restrictive of the two mobile operating systems.)
For this design challenge, I've prioritised features as follows:
- Report an issue
- Check status of reported issue
- Mark location of issue
- Mark issue as closed/done
- Ability to authenticate residents
- Post/view photo of issue
- Contact maintenance crew directly
- Urgency labels
- Issue triaging
- Building setup
- Maintenance crew view
- Any flows outside of resident flows
I'll aim to get done all of Musts and Shoulds, and won't worry too much about the Coulds and Won'ts.
Ideation & Sketching
In this phase I prefer pen and paper; please forgive my chicken-scratch handwriting!
Here, I start to think about how the resident can access the webapp. After flirting with the idea of QR codes, I went for a simple, short, memorable URL: [building name].[app name].com.
After brain-dumping some ideas down, I can start thinking about more specific flows for public and private space issues:
Here I wanted to take a quick aside to roughly think about the building manager's setup process. It's not a flow that I'll be focusing on for this design challenge, but I want to loosely address it just so I can confirm in my brain that my assumptions for the resident flows are realistic.
Some non-visual features I propose:
The app compares device location with location of building, and quietly flags reports as suspicious depending on how far from the building the device is. It can also automatically block reports coming from outside the city/town the building is in.Sufficient priming before asking for location permissions significantly slows down the "add an issue" flow. For this project I'll recommended releasing the first version without location checks, while monitoring the rate of false reports. I suspect this rate will be quite low, but if initial tests show it is high, we can then think about checking against location data.
- On visiting the webpage, the app creates a shadow account for the device, and can re-display relevant issues when they come back to the webpage/app.
- Shadow accounts can be "upgraded" to a full account when the user authenticates via their email.
- The maintenance crew's calendar is synced to the building, so we automatically suggest times upfront.
For larger applications, I prefer card sorting exercises with users to determine a good information architecture. For this app, however, I've only got three or four views I need to map out.
I've chosen the list of all issues as the homepage, with detail views and add a new issue as pages that can be spawned off of that. The "add a detail" view is a main action, so I'll put that in the middle of the bottom navigation (along with the issue list). Detail views of issues can be launched off the issue list view. I also want to introduce a view with a list of all updates — that can go in the bottom main nav too.
Reporting an issue
For our first user story, we need a lightweight process for residents to report both public and private maintenance issues.
First, the public flow:
Note here that the resident is free to report issues and even see status updates without installing the webpage as a progressive web app at all. We also don't prompt the resident to install the app until after they've finished their task, providing them with value first and making their experience as frictionless as possible.
The flow for issues in private areas is similar:
Here, we assume that the building manager's setup has provided us with a list of apartment numbers, as well as their corresponding resident names and email addresses. This information is kept secret by the app and is never revealed.
With this information, we can essentially create a passwordless login, by sending the last confirmation step to the resident's email address. Essentially, we're deferring authentication to the resident's email service.
I've implemented two security measures, both of which should be invisible to legitimate users. For a bad actor to successfully post a fake report, they will need to both know the resident's name and apartment number, as well as have access to that resident's email inbox. Accomplishing both is highly unlikely.
After the resident has confirmed their appointment via email, we can create an authenticated account and session inside our app. If their session is destroyed, we can reauthenticate them by sending another token to their email.
We've just introduced a two-factor* authenticated account with zero account creation flows, or passwords. Nice.* The matching name and apartment number is something you know; the access to your email account is something you have ;)
For our second user story, we need to provide ways to inform our resident on the status of their reports.
Public issues can be marked as resolved by the maintenance person who fixed it, or by other residents:
Private issues will need to be marked by the reporter. To do this, we can check in with them the next day:
Currently in iOS, push notifications from PWAs are not available yet. In that case, for the public issue, we would not inform the resident (they can always check the app/website if they want), and for the private issue, we can confirm the issue's resolution over email.
If the resident doesn't confirm their appointment via email, they'll see this:
And if all issues reported by that resident has been resolved, we default to the "report new issue" page:
Before we move on to hi-fidelity screens, I want to test that these flows are intuitive and make sense.
To do this, I linked up the above screens using the prototyping feature in Sketch, and displayed the screens on my phone using Sketch Mirror. I then asked my flatmates to pretend to report an issue. Here's what happened:
Notable comments include:
- "I was expecting to be able to zoom into the floorplan."
- "I wasn't sure if it was a website or an app? Is it like a bookmark?"
- "The app seems really passive, like it's not telling me what to do."
Usually I'd prefer to do a few more rounds testing with low-fidelity wireframe prototypes, and ideally with at least three people per prototype. In the interest of time, I'll move on to the next step.
Usually at the visual design stage I would work within a certain styleguide and brand guidelines, but since we have none here, I will randomly generate some things to work from.
Using a random photo and this accessible color palette generator, I generated the following palette from a random unsplash image:
I don't have time to curate a nice icon set, so I'll just use emoji for now 🤷
To simplify my life a little I'll design in the "app" view, since the PWA will be exactly the same, except with an additional browser chrome.
Taking on board some of the feedback from my quick tests, I wanted to reduce decision fatigue by breaking out each question into its own screen.
Here's a quick prototype of the public report flow:
I'll be honest — I'm not a huge fan of what I've come up with, visually. The colours are murky, the typeface seems plain. I'll give it one more shot — I'd like to see some more of that aqua blue pop out, as well as some more clear expectation setting around when issues are expected to be tended to.
To accurately show my process, this would be the point where I break down screens and components to aid in their development. Depending on who I'm working with, I might send annotated designs, CSS snippets, or simply sit next to the developers and walk them through it.
Due to the time constraints of this design challenge, I'll skip this step. You can see an example of how I prepare spec sheets here.
Even with our focus limited to the residents' flows, there are plenty of further considerations:
- Exceptions handling. What if the user is legitimate, but is the name fails to match, or their email on file is incorrect?
- What happens when the app labels public space as private or private space as public, due to the small floor plan and lack of precision?
- Are there any technical gotchas if the resident never installs the app?
- What happens if someone reports something that has already been reported? We want the app to be able to make guesses at merging potential duplicate issues, but how will a user confirm that? What will the UI look like?
- What happens if the issue has changed and the resident needs to update an issue?
- What if the scheduled time no longer suits, and the resident needs to contact maintenance to schedule another time?
Furthermore, there are the flows for our other two user groups that need to be considered.
- What would the account and building setup process for our building manager look like? How might we elicit rich information while making it easy for them to set up?
- What happens if the building gets a new manager? How will the authorities from one account be passed onto another? How might we do this in an easy but secure way?
- How might we prevent bad actors from accessing private resident information?
- How might the building manager update building and resident information? Can we get residents to aid in this information update?
- How might maintenance crew interface with this app? Would they want to interface with it at all, if they most likely already have other task management processes?
And outside of that,
- How might this app scale for super, super large apartment complexes?
- How might this app be applied to a community? A city? Could it be used for reporting issues such as broken water pipes, potholes, fallen power lines, etc?
The final product
Thanks for reading :)
That was a fun design challenge! Thanks for taking the time with me, I hope that was enjoyable for you, too. I'm looking forward to hearing what you think!