Three words that probably shouldn’t ever be uttered together; “finding parking” and “London”.
AppyParking aimed to make this easier, by showing on and off street parking locations for London and ten other cities in the UK. I’d previously downloaded it with excitement and optimism – only to rage quit when it fell badly short of expectations.
Therefore, it only made sense to redesign the app.
If the design process doesn’t interest you, feel free to use the prototype that was created.
The current situation
Customer reviews told the story of a divided fanbase. Having read every review left by users on Google Play and the App Store, opinion on the app could be split into two categories: people who “used to love” the app, but now found it hard to use due to large amounts of bugs, and users who found the app “unusable” because of its design, performance and accuracy.
Users in both categories had one thing in common – they liked the idea, but were growing frustrated by the execution.
The app had also fallen from an App Store high ranking of 4 to 115, and was currently at 275 in the Google Play Store (in navigation, as of 14th June 2018). It looked like the app couldn’t attract large amounts of new users, with its main base being “highly motivated” people who put up with the app as gain outweighed pain.
But what if pain could be eliminated altogether?
This solution is only missing colour – deliberately done, as this prototype was used to test usability, not aesthetics.
To minimise the confusion of a radical redesign, the changes made would be released over an extended time period. This was done to stop users having to learn a comparatively new system, even if it did make use of several common design patterns used in mapping apps.
As mentioned earlier, customer reviews were split into two groups; people who “used to love” the app, and users who found it “unusable”. It made sense to target the latter, as their problems made up the bulk of AppyParking’s negative reviews.
Analysing the feedback left by these users revealed three pressing issues; poor performance, confusing design and inaccurate parking data.
But was this justified? I went for a drive to find out.
Having set up a recording rig in my car, I attempted three tasks;
- Confirming the parking rules at my home address both now and at 11am on a Sunday,
- Finding three potential parking areas near my workplace that were available for office hours and suitable for my vehicle,
- Finding parking at a location that I would be likely to visit at the weekend.
The easiest way to identify the app’s problems was to encounter them myself.
I experienced the majority of the issues that users were complaining about. They also fitted into the categories assigned earlier;
The app took ages to load (due to giving information on spaces up to six miles away), and was bug-riddled. It also didn’t work without an internet connection, even though a GPS based app shouldn’t be reliant on one.
Inaccurate parking data
The parking information for my home was wrong (the app said enforcement from 08:30 – 18:00, when in reality it’s 24/7). Certain spaces also gave contradictory information, depending on what screen was viewed.
Because of its confusing design, things like comparing parking spaces, setting favourite locations and booking parking were more complicated than they should have been.
In particular, the registration process was one of the worst I’d ever gone through, and took over five minutes. A lack of form feedback, a confirmation email that was sent without notifying me (but needed to be agreed to), and STILL being told to sign up even after I had done so stopped me from effectively using the app (as the majority of its features were exclusive to account holders).
A heuristic evaluation was also carried out. This is an inspection technique that evaluated AppyParking against a list of proven guidelines that tend to result in good interface design when followed. The app didn’t do well, failing half of the criteria.
At this stage, enough information had been gathered about the failings of the app. However, I now wanted to focus on the user.
What motivated them? What annoyed them about the app? And most importantly… who were they?
Through talking to drivers (who also carried out guerrilla usability tests), gathering information through reviews left for competitor apps, and using “forum” websites such as Reddit, Twitter and Mumsnet, user personas were slowly created.
In total, three types of potential user were identified;
These users plan as much of their journey as they can beforehand, and prefer to have everything sorted before they leave.
These users are visiting an area, and want to park as near their destination as possible. They differ from planners, as they are not likely to do this before leaving, but when nearby.
These users need specific parking like disabled spots, electric bays, or motorbike spaces..
Task and user flow maps were also sketched out. Through this, it became clear that the most useful features of the app (directions, street view and a comparison of cheapest and nearest parking) were only available to account holders. But, as mentioned earlier, registering wasn’t the easiest thing for users to do.
It was impossible to effectively use the app without an account. However, due to bugs, it was often impossible for users to create an account.
Registration was currently a compulsory action presented as optional – a move that, in its current form, was causing users to get frustrated, and ultimately abandon the app. It therefore became a priority to fix this problem.
Goals of the redesign
The redesign process was split into four main sections; user research, mapping, sketching and prototyping. User testing was done at the end of the prototyping stage.
It aimed to build on a four point vision;
- creating a simple app that gave the user everything they needed, but nothing more,
- improving reliability, and regaining the users trust,
- allowing users to quickly find, pay and navigate to spaces,
- designing a convenient product that users would sub-consciously want to use.
So what changes were made?
Why did users need an account?
From AppyParking’s point of view, account holders seemed desirable as they provided data for analysis. Indeed, the company asked for excessive information at times, like the full name of the user or (somewhat more sinister) access to their photos, media and files for no obvious reason. The amount of terms the user had to agree to (four) was also suspiciously high.
However, having an account didn’t seem essential for any of the features offered. Ironically, features that registration would have logically made sense for (such as paying for parking through the app) didn’t require one.
I therefore decided to remove the “limited features” model of registration. This was mainly to get users engaged (by looking for parking) as quickly as possible – but also because the app hadn’t provided enough value to the user at the previous registration point. Adding to this, if the registration process was broken, users would now still be able to effectively use the app.
It was key that the main task of finding parking wasn’t interrupted.
However, for features like paying for parking through the app, it made sense to have an account. With users having made a small investment in the app (spending time to find a suitable spot), and moving the registration process later in the user flow, it was hoped that conversion rates wouldn’t drop, while still signing up as many users as possible.
Intuitive input forms
Forms were mainly needed for two reasons in the app; for registration, and to give feedback on the app. But while the registration forms were poor (due to their lack of feedback), actual feedback forms didn’t even exist!
The previous design of the app required users to manually send an email, increasing the workload on them and ironically making it less likely to get feedback (as only the most motivated users would carry out the desired behaviour). Luckily, this problem was easily solved by including a “contact us” form in the app.
Decreasing the work the user had to do made it more likely that they would do it.
This form had a pre-defined list of choices, and changed depending on where it was accessed from. If a user was coming from the main menu, it would remain non-specific – whereas a suggestion of “wrong information” was given if the “report issue” button had been pressed. This was done to constrain the possible choices of the user, making it easier for them to select an option, and for the company to quickly categorise any feedback received.
Major changes were also made to the app’s registration form;
Giving immediate feedback
The old form didn’t give any feedback until it was submitted. The new form would warn the user if a field was incorrectly completed before this could be done, graying out the submission button if needed.
Clearly displaying password constraints
The new form clearly indicated the constraints on a user’s password, and used symbols (ticks or crosses) to indicate if they had been met.
Allowing the user to see their password
The two ways to prevent mistyped passwords are either making the user confirm it, or allowing the user to see their password. The latter was selected, as having to repeat information had been proven to lower conversion rates.
Stopping users having to agree to various terms and conditions
AppyParking had an excessive amount of agreements (four). By changing to an “auto-accept” model, unnecessary user interaction was reduced.
New app structure
With information not where it would normally be, the main thrust of the redesign focused on the information architecture of the app. I spent a few days first creating a map of the previous designs structure (see above), before re-categorising much of it.
By re-categorising where information would be found, several pieces of non-critical information were removed from the app completely.
A lot of the categories combined naturally – single yellows, paid bays, resident bays and car parks became “on street” or “off street” parking, while “cheapest and nearest parking” for single yellows, paid bays and resident bays could be labelled “price” and “proximity”. Because of this, it was possible to extend the filtering of parking spots shown in the results.
Other key parts included making it easier to report an issue or set a location as a favourite (by having this information clearly displayed on the parking information page) and adding a new section that clearly stated how up to date the parking information given was.
General usability improvements
One of the problems found on my usability test was being unsure of how far a space (especially on-street) was from a destination. This became a bigger issue when considering the fact that users often had redo their searches when comparing parking spaces, as the parking space selector (the big “y”) was fixed to the centre of the screen.
Having to redo searches when comparing spaces gets annoying very quickly – especially if you’re in a rush.
To solve this, shaded “radius rings” that showed the walking distance from a destination were introduced, in order to allow the user to have a sense of how far away the parking they were looking at was. The function of the parking space selector was also changed. It would now act as a “pin” – clearly indicating the location that the user had searched.
The new design also changed how available spaces were displayed. Currently, AppyParking highlights areas with available parking in green, with non-usable spots in red. On closer inspection however, this wasn’t always accurate – only residents controlled parking zones were highlighted, meaning suitable single yellows and paid bays could be shown as unavailable. This also didn’t work for roads that had more than one set of rules on them.
To combat this, the display was changed to highlight individual roads, instead of sections of the map. However, while this method solved the problems mentioned earlier, large highlighted areas (even if inaccurate) are easier to glance at than roads. Another possible solution would have been to combine the two – large highlighted areas when the map was zoomed out, before showing individual roads when the map scale was less than 200m. I freely admit that I’d want to further test this with users before committing to one particular solution.
Finding a way to display the correct information at all times without affecting usability was one of the biggest challenges of the redesign.
Other small changes made included;
Only showing users actions they could take
The old design often showed the user features/actions that they couldn’t do. The redesign aimed to get rid of many of these instances as possible (e.g. the “pay” option was only shown if the user could pay through the app).
An intuitive landing page
The landing page of the app was changed from the registration wall to the main map. This was also set to open to the user’s current location (the old design always opened the app to Russell Square).
Displaying appropriate information at relevant times
The new design only showed the user information when they’d be likely to use it. For example, specific parking spots (car parks, pay bays) were only shown when the map scale was 100m or less.
All of the changes mentioned above can be seen in the high fidelity prototype that I created along with this project.