This was my favorite project to work on. I thoroughly enjoyed having to look at both sides of the equation: the business needs as well as the user needs and doing my best to balance them out with human centric design.
It was also fun to look behind the scenes, and to understand from industry big wigs — the true motivations behind the app, it’s existence and it’s future roadmap. It’s not everyday that you get to speak to the makers of the app.
But the path to understand how the app had to be redesigned was not always clear-cut, we were often peppered with difficult decisions along the way. Our first difficult decision came on project day 1.
The clock is ticking
Project 3, Day 1: Our very first task involved deciding on an app to redesign. We were given 24 hours to think over our choice of app. Before the end of the day, my project team mates and I had narrowed it down to three choices.
iChangi — the Singapore Changi Airport app portal for flights information, shopping and dining.
PropertySRX — A property app used to help people locate property to buy, sell or rent.
OneService — a government run application created for residents to quickly report on estate issues and to help route cases efficiently to the respective government agency.
There was a natural attraction to work on OneService simply because of its premise. Here was an opportunity to redesign an app that was created to help make Singapore a better living place. It felt good to be part of something that would help my fellow countrymen have cleaner estates.
But hold on a minute, I haven’t heard of this app before!!
Would I be able to gather sufficient data points, let alone find enough research participants to support my findings? My confidence in choosing this app for redesign was dwindling down and fast.
My project mates and I discussed in length and decided this is our time to stretch ourselves, to face the unknown and if we make mistakes, we’ll learn along the way. At least, we could still depend on each other for support.
Research participants — where are you?
Project 3, Day 2: We began by brainstorming and sending out broadcasts to recruit users for our interviews. We stalked the social media sites of OneService, to see which of our friends had liked the OneService facebook page.
Luckily, in my medicore friendbase of 486 persons, there was one kind soul who was free to be interviewed that very day! (Unfortunately, no photos allowed as he was in uniform).
From my initial research interview, I had managed to gather feedback on what the app was being used for, what the participant likes or dislikes about the app. The kind soul also did a cognitive walkthrough of the app so that I could observe first hand how the participant interacts with the various features on the app.
Left screenshot: The horizontal scrolling was not user friendly, especially for those trying to log a case single handedly. This finding was repeated when we tested with older research participants.
Center screenshot: Research participants did not see usefulness of Location, Parking App and Transaction sections.
Right screenshot: It was mandatory for the participant to input a picture, when it wasn’t always convenient to do so. Our participant gave the example of noticing potholes along his cycling route, but he wasn’t able to stop and take a picture as he’s in the middle of traffic.
Here, this affinity map helps to explain it better. Collectively, between my project partners and I, we had interviewed and observed 6 participants (a mix of old and new app users) with age ranges from 28 to 72 years of age.
Zooming into the dislikes of the users and we could find some main pillars of frustration which could be further broken down into, Lack of purpose, Feedback loop, Reliability, Design and Categorization.
a) Lack of Purpose — Though the app had well meaning intentions to store all government apps in one place, this didn’t resonate well with research participants who were only looking for a place to lodge complaints and this made the user experience less enjoyable.
b) Feedback loop — users were keen to know that someone is working on their issue, and that they receive regular updates as well as a timeline on when this issue would be resolved. In the current app, it only mentions a few statuses with no estimated timeframes.
c) Reliability — the app was buggy, sometimes the main page would not load. The icons showing the categories were not always showing up, which was not professional.
d) Design — the main page of the app as one participant put it “the dashboard is user unfriendly and confusing” and another had described it as “the transact page is taking up too much space” highlighting the poor space optimization on the page.
e) Categorization — Users were not happy that the app didn’t offer enough flexibility in the categories. Often they would drill down into a sub-category only to be left feeling perplexed “you mean there’s no ‘others’ option?”
In discussion with my project mates and due to the limited time (2 weeks), we decided to focus our energies on fixing the Purpose, Categorization and Design issues.
Data, data everywhere.
Identifying the problem statement was a tough one.
We combed through our data sets and our participant quotes. There was one recurring theme: participants had questioned the addition of the parking app to OneService and could not relate to the connection between the two services, despite both being government apps.
“What is this app for? Is it for lodging issues or for parking?”
“Why does parking have to be added?”
“Why do I need to go through OneService to get to the parking, when that’s two clicks and I can go to Parking app directly?”
In line with our affinity mapping results on the lack of purpose, we identified our primary problem statement:
Users who use the OneService app to lodge estate-related complaints need to understand the main purpose of the app, so that they are more likely to use the app to make complaints.
We also wanted to address the issue of flexibility within the case categorization on the app. On closer inspection of the main categories, we noted the main categories were derived from the key agencies part of OneService. For example “Drinking Water” and “Sewers and Drains” fall within the remit of PUB (Public Utiities Board).
Through our research interviews, we had asked participants to freely explore the app and lodge a specific scenario such as “noisy coffeeshop”. We noted that many participants had difficulty completing the task as the main categories were a mix of states e.g. “Cleaniness”, places “HDB facilities”, or objects e.g. “Pests”.
Sometimes when a participant went further into a sub category, they were not provided a subsequent ‘others’ function which caused them to backtrack into the main categories and to reselect their case submission categories again.
Results from our Card Sort and Tree test further validated these points, that the existing app categorizations were not optimized to help reduce the user’s mental load in lodging issues. (e.g. For the case “Cockroaches in food establishments” had 3/11 participants park it under Cleanliness while 3/11 parked it under Pests, the remainder had created their own categories for it as they did not see any main category that fit well.)
Our secondary problem statement was formed:
Users like having control over how and what information should be included when submitting a case so that they can quickly submit their case.
Understanding the business
Over the course of the next few days, we also looked at the business goals holistically. Through our own connections, we manage to ask the people who worked on the app, their motivations and direction for the app’s future.
Our business related questions were:
- Why was this app created?
- What are the business objectives of the app?
- How are the cases allocated in the back end?
- What are the future plans for the app?
Through the responses received, we understood the app was created to remove the resident’s needs to know which agency to approach to resolve a particular estate issue. It also provided a “convenient platform” for residents to lodge issues.
The future plans of the app was to create a community platform with additional modules or government apps added to it.
Through our literature research, we also discovered the “fishball stick issue” which was the catalyst to kickstarting the OneService app. (Fishball stick issue refers to if a fishball stick fell to the ground, which government agency would look after it? Would it be Land Transport Authority, National Parks or National Environment Agency?)
The Balancing Act
Now that we knew the business motivations and we also had insights from our research participants, we needed a good way to help us identify which features of the app we wanted to keep, remove or evolve.
We used this prioritization grid and started mapping out existing features (in blue) as well as any new features (in yellow) suggested by participants. Each feature post its were moved around until we could convine ourselves exactly where they sat in the business vs user crosshair.
We prioritized based on features that will help resolve our two problem statements and made a border on those that would make it into our prototype design.
Redesign on the go
Armed with our problem statements, business goals and features prioritization we were ready to start paper prototyping! Our three design goals were:
- Make the purpose of the app clear and improve usability for ease of reporting.
- Encourage community interactions, to help raise awareness of the app.
- Reduce the learning curves to make the app accessible to all residents.
The home page was redesigned to maximize use of the white space by having each case represented by a card with no more than 4 cards on a single screen.
For case submission, the horizontal scroll was also removed and the vertical scroll added.
When it came to how many main categories or what should be our main categories, we took to the white board. Mustering what I could of my psychology days, I took a look at how a person would instinctively communicate about a problem.
We came up with three high level details that would provide the user sufficient flexibility to permutate and custom their case classification. These categories were also detailed enough to help with the case allocation to the respective agencies.
1st level — The high level thought of the issue (Animal, Place or Object only e.g. “Animals and Pests”).
2nd level — A more detailed What of the issue (e.g. “Bees and Hornets”)
3rd level — The state of the issue, this will have to do with a human being’s senses, it could be a smell, sound or feeling. (e.g. “Nuisance”)
My project mates and I agreed to workout the new categories and sub categories based on these three levels. At this point, we were pretty much working as One mind (pun intended!).
My One, Your One, who is One?
Using Figma (a collaborative web based prototyping tool), we converted our paper prototypes into digitized ones. We took our digitized prototypes to test with both the young (think 20s to 30s) and the old (think 50s and above). We quickly came to realize that the the less tech savvy approached screens very differently from those that are more tech savvy.
a) they were less likely to notice visual cues such as arrows or even guiding prompts (to help them familiarize with lodging a case)
b) they did not always know the local slang words like “Gahmen”
c) they don’t always recognize the common icons
These discoveries led us to iterate our design by:
a) having straight arrows and bigger fonts for guiding prompts
b) reducing the amount of slang used among the pages
c) labelling all icons.
In the above design, our goal was to integrate community interactions into the app. Interestingly when we tested with our research participants, Redesign 2 with colored icons was a welcome idea by the tech savvy research participants. In contrast, the less tech savvy participants found it jarring and confusing. The less tech savvy also could not make out the icons or labels as they were too small to see.
From this feedback, we again reiterated our designs, this time to show cases on cards, there was also a change to map view to retain some of the initial app features.
We also didn’t forget our business goals, where the future direction of the app was to include other government apps which transforms it into a one-stop community platform.
This feature was now neatly tucked away under a Government Apps icon which we have labelled clearly. During the usability testing, one user even mentioned “If there are multiple government apps clustered together, this makes more sense than having a stand alone parking app”.
Free Exploration and Usability Testing
We had two separate tests run: 1) to validate if the redesign helped to make the purpose of the app clearer and 2) to see if there was improved usability in the design.
For the first test, we used a free exploration and collected qualitative feedback from our research participants to describe back to us what they thought the purpose of the app was. All participants understood the app to be for lodging issues and the purpose was clear.
For our second test, research participants were give three specific scenarios to perform and at the end of the test, each participant provided their satisfaction ratings based on an emoji slider. We had requested for this emoji slider as it was easier for our participants to relate to, they just had to pull the slider till the emoji (frustrated, sad, neutral, happy or elated) matched their own feelings on the matter.
From the results, I’m happy to know that our redesign achieved our design goals. We had improved both the learning curves and clarity of the purpose of the app from 1.5/5 to 3.5/5. We also simplified the reporting of cases which saw an improvement from 2.5/5 to 4/5.
Other improvements if time permits, would be to look at language support so support the Mandarin speaking community. We would also look to work with the government’s back end systems to ensure the new categorizations are tagged and in sync with the agency architecture.
I definitely have a few takeaways from working on this project.
- Start with your most challenging persona — if I can solve the usability issues for the most challenging persona, I would be able to solve it for majority of the users.
- Knowing the business needs helps — sometimes businesses want to achieve a certain outcome. If we can design a product where user goals can help businesses achieve their outcome, it’s a win win situation. The magic is in the design of the product.
- Descoping features is a necessary evil
It is very tempting to include every feature your participants tell you to, or even the ones you dream up. But don’t. It’s really important to be discplined and remain focused. Use the results from testing your prototype to form your own guidance on which features won’t make the cut because they don’t add value to the user experience.
Check out my prototype here.
Lastly, a big shout out to my project partners Jie Ying and Ethan. Truly a pleasure to work with both of you. Each of you brought their strengths to the table and there was a good push and pull of ideas to get us through the hurdles. You guys rock!