Deep dive and redesign for the One Services mobile app — a UX case study
This was probably one of the toughest projects I went through during my time with two fellow partners at General Assembly. Although we had numerous challenges including the lack of resources, competency and time, it gave me the learnings I needed to put it into my future work.
Project Overview
So, we selected the app, OneService, because we felt that there were many improvements that it could be made. Another evident point to note was that the app wasn’t very well adopted by Singaporeans.
I always had keen interest on the projects developed by the government, especially those that help build and foster great bonding amongst our people. This project is the result of a 9 days work with my partner at General Assembly. We were both eager and keen to help improve the experience of the app. There were several options on the table but we decided the OneService app was the one that immediately resonated with us. We wanted to improve the everyday lives of fellow Singaporeans.
Project brief
Work in a team to identify problems and/or an opportunities with an existing mobile application and utilise your knowledge to design a solution.
Background research
In order to address municipal matters and to help improve the living environment for fellow singaporeans, a community of government agencies, town councils and citizens can now partner together via the Municipal Services Office (MSO). Its objective is to improve the Government’s coordination efforts by promoting civic responsibility and community partnerships.
The OneService app was created to resolve municipal matters. It has also recently went through a design revamp and added some additional features including parking. Some parts of the parking feature is still in its beta stage.The parking feature is added to increase more app usage and increase more adoption. It is worth noting that the app might ‘scale up’ potentially with more features in the near future.
OneService currently have presence online via their main homepage, social media like Facebook, Youtube and Instagram as well as their own mobile app.
Overall approach
Our work process revolves around four key areas. They were Discover, Define, Develop and Deliver. This was a very tough 9 days sprint and there were several issues to tackle. But we had to narrow down and focus on some key areas that can be addressed within such a short time frame. The processes we choose were both tactical and vital to our success in getting to the root of the problems.
Competitor analysis
One thing to note was that municipal reporting apps were largely governmental initiatives, the scale is on a national level and competition within the local context is not easily available. Hence, to get a better picture of how the experience of the app will be, we did a comparison with 3 other apps. As these apps were not local, it gave us more insights into what other countries were doing and a better understanding of their cultures.
From the competitive analysis, OneService scored the lowest. This can be attributed by:
- Lesser technical functions compared to ‘FixMyStreet’ which have a map feature for reporting case
- No direct link or means to resolve urgent matters or mechanisms in place to address urgent matters
- No proper decentralisation of zones or areas for reporting compared to ‘LA Unified School App’ which allows for segmented reporting. If resources are tight, might face issues handling cases throughout the country
Heuristics evaluation
We conducted a heuristics evaluation using Jakob Nielsen’s framework, on the OneService app and found several issues revolving around “Flexibility and Efficiency of use” as well as “Consistency and standards”.
User flow
A flow of the current app and some of its key processes.
Initial questions
From the information gathered, we identified several areas we could work on to improve the experience of the app. Some of the key questions include:
- How might we help MSO to increase community engagement?
- How might we improve the features of the existing app?
- How might we create a less silo experience for the app?
- How might we create a system that scales up as new services get added in?
Contextual inquiry and user testing
We proceed to interview several users in order to gain more insights from their perspective of OneService and the app itself. While using the app, users were assigned tasks to complete. Their responses led to several key findings:
“I would only consider reporting if the issue was extremely severe”
Some of the users felt lesser need to report a case unless it proves to be extremely urgent. This is primarily because many cases that were reported had little or no response from the authorities. The app did not have any mechanism to indicate urgency.
“I actually prefer to use other means to report issues like these.”
Many of them felt there are faster alternatives that would be easier and assert more pressure on the authorities. However, there is a case of distinction bias at work here. Comparing both reporting on the app and going directly to the authorities, the difference is not that great because the response time will still be the same.
“Sign up process is too troublesome”
Currently there are 4 different methods to sign in to the app and users felt the process was way too troublesome. They can sign in using their Singpass, Facebook, google mail or through the OneService app itself. After doing so, they are required to wait for an OTP key to be smsed to them, making it more cumbersome.
“Every time i tap ‘shared bicycle’ the pop up appears again and again.”
The reporting case feature can be a pain for many users. While the interface is now much cleaner than before, the process of reporting certain issues is still a nuisance to some. For example, to report a discriminated bicycle parking issue, the process to do so is irritating and extremely troublesome. Other features have their fair share of problems as well.
“The icon’s design and graphic illustrations looked very mismatched.”
Users felt that the interface was easy and clean but somehow there seemed to be several different style of design.
Interview questions
We conducted an in depth session and was able to find out a lot more than what we know. Some of our assumptions were validated by key questions asked during the interview. Bellow are some of the questions that we asked the participants.
Affinity mapping
After collating the feedback and results from our users, we were able to synthesise our findings using affinity mapping. We observed several patterns and were able to group our findings into similar categories. Among the groups of data collected, we noticed users’ behavior played a pivotal role in our research. On top of that, there were general doubts and also several flaws surrounding the app. We were able to coordinate the findings and use this data to create our personas.
Problem statement
People are unsure of the product flow and features of the app due to design ambiguity.
If this problem is not addressed, it will continue to disrupt the app experience for all its users.
User Personas
Through the data gathered from the affinity map, we spend some time synthesising and were able to come up with three personas. These three personas are categorised generally under high involving users, conditional users and low involving users.
Persona 1: Jackson Liang — active user
Jackson is someone who is very involved with his community and see a point in staying on top of things through the use of the app. He represents the modern dad or someone who stays with his parents. Jackson is committed to look after his family and neighbourhood.
Person 2: Laura Chong — conditional user
Laura is a homemaker who takes care of her household and places her family on top of everything. She would want to use the app for important news like weather, dengue conditions and even occasionally use the parking app for to help her husband check parking availability as well as fees.
Person 3: Shih Min— low-involving user
From all the three personas and their journey maps, we identified several potential areas to work on. Although the main feature of the app was to report municipal matters, it has also integrated new features like parking which proved to be one of the more important things our users actually use during all our testing. It is a feature that should not be ignored.
Feature prioritisation matrix
Moscow method
Given that we only have 8 days to complete this sprint, we had to prioritise the most important things to tackle. Using the Moscow method, we aligned within ourselves and made the necessary list of features to work on.
Storyboarding
Lo-fi paper prototype
We begin by creating fast paper prototypes to run our MVP with existing users. This helps us get a quick test and see what is the feedbacks as soon as possible. We went ahead to test it out with our users to get some of our initial assumptions validated.
Key findings from our user testing:
Paper prototype:
- Users are still unclear why some features are integrated into the app.
- Users needed more explanations to understand the system.
- There was a general lack of citizen-centricness.
- Users kept looking for a feature that would show others suffering from similar reported cases.
Mid-fi interactive prototype:
- Users find the on-boarding process still pretty ‘vague’, but appreciated that the copy is now more personal and less ‘commanding’
- Previously, users find a lack of information. They now liked the new notifications tab which gave them more information than before.
- We implemented an “Acknowledge” feature to indicate that someone shared the same problem and decrease the need to report the same case multiple times. This function was misinterpreted as being a case acknowledged by the authorities instead.
- Previously users were having general usability issues including not sure of certain task flows and objectives. They now have a sense of where to click and appreciate the ability to allow them to have more control when they submit or report cases.
Hi-fi prototype
Functional Improvements
We made several enhancements to improve the overall app experience.
Submit case: ‘shared bicycle’
By changing the orientation of the menu, users now express easier menu navigation as well as being able to know what are the next steps.
Bumping a case
By adding “bump case” feature, users can now bump nearby cases they witness themselves. This reduces multiple reporting as well as fostering better community engagement when someone acknowledges your case too.
The module that keeps popping up is resolved now with an additional option to not show it again. The next step in the process is selecting bicycle operators followed by entering the number of bicycles spotted for each individual operators. Users expressed a hassle and will not use this feature because it can sometimes be difficult count the number of bicycles if the quantity gets messy or they are in a hurry. A slider with an estimate number of bikes help to remove this hassle while at the same time keeping the operator logos there helps to provide the authorities with details on the case.
Parking feature
The parking feature comes with a number of problems initially. Users didn’t want to use an app that relies on another external app for certain features. Aside from that, the app didn’t effectively provide any new value for users. So, we introduced the notifications and alerts feature that effectively leverages on submitted cases to intelligently notify users of potential hazards.
Weather widget
The weather was further improved to provide weather details of the destination location. This proved to be extremely useful for the user. While this feature might not be the main reason why people use this app, this change was in line with MSO’s approach to increase adoption through making the app more useful and integrated. Together with the parking feature, the weather widget helps user like Shi Min (persona 3) to plan their route better.
Strategic resource alignment
One of the things that really needed a lot more work was to improve on how to tap on the submitted cases of users. While this might require more testing, the long term potential of leveraging on this intelligence is great.
- Allows for app scalability by allowing new features to be added, tapping on user submitted cases
- The recommendation model removes silo experiences and foster better community engagement
- The recommendation model helps to link multiple features together, maximising their overall productivity
- Improves front stage experience with more complex back stage process allows users to see the best of an otherwise complex app. This reduces cognitive load by having lesser steps, more efficient processes and better overall performance
Moving forward
We are looking to see how new features can be incorporated into the app and be easy for new adopters as well as current users. There are also some ideas that we discussed but have yet to do our testing on:
- Including a video feature for recording potential accidents that residents witnessed. A car accident for example.
- Integrating several features on other online presence with the app but this might require more research to validate. An integrated platform to help bond residents require more information that is available on OneService’s other platforms.
Happy to have completed this sprint! Thanks for reading. If you enjoy your read, please feel free to drop me feedbacks or comments! Claps are welcomed too! ;)
