SUP the App Redesign

For our final UXDI project under General Assembly, we did a pro bono project for a local startup to apply our UX knowledge to help the startup to the best of our abilities. My group was assigned to SUP the App.

SUP is a social mobile app that helps you find friends who are nearby and available right now for an activity such as lunch or watching a movie. The concept employed is similar to that of GrabTaxi, but instead you can “grab” a friend on demand.

Kickoff Meeting with Our Client

During this 2-hour meeting, we learnt about the origin of this idea and the background of the startup. Towards the end of the meeting, we came to a consensus that for the duration of our project (3 weeks), we would focus on the following:

  1. Privacy Settings — How to obtain permission from users for location services, contacts, and notifcations
  2. Convince Users of the Usefulness of the App — How to get users (both new and existing) to use the app
  3. User Acquisition — How to get people to share the app and invite friends

Target Users: 18–35 years old with outgoing personalities

Double Diamond Model

For this project, we used the Double Diamond model to guide our UX design process.

User Interviews

Over the first few days, we conducted a total of 9 user interviews with the aim of finding out how users usually plan their activities. We also asked our users what draws them to social apps nowadays in order for us to gain greater insights on what users would want from a social app.

User Interview with Esther, a 22-year-old NUS student

Affinity Mapping

We consolidated our findings from our user interviews into an affinity map in order to identify common patterns in the behaviours of users.

My project groups mates — William, Eugene & Lesly

The results of our affinity mapping are as follows:

Personas

To help us better empathise with users in terms of understanding their needs and pain points, we created 3 personas. The persona that we focused on most was John Siow, a 34-year-old lawyer who enjoys spending time with friends, but is unable to do so often due to his hectic and unpredictable schedule. He finds it difficult to ask friends out at the last minute.

Key Persona — John Siow

In addition to this, we created 2 more personas to better understand and meet the needs of other types of users.

Usability Testing (of current app)

We used Lookback to record the thoughts and behaviours of users during our usability testing of the current app.

Users were deeply confused by the app and deemed it highly unusable.

Wireframing & Ideating

While analysing our user research, we realised that there are two possible user flows that users might undergo, depending on the scenario that they are in. In some scenarios, users preferred to find out who their nearby friends were before deciding what activity to do, while in other scenarios, users already had an activity in mind before deciding which friends they would invite to join them.

Taking this finding into consideration, we began brainstorming for ideas and transforming them into wireframes.

Wireframing

As a group, we came up with several designs for different screens and flows. We had some doubts about which design would be ideal for users. Before investing a substantial amount of time into digital wireframing and prototyping, we decided conduct usability tests using paper prototypes first. This took significantly less time as compared to creating a digital prototype, and the results were just as useful. When in doubt, we should always test our designs on users first instead of allowing our personal biases to cloud our thinking and cause us to move the product in a direction that might not be useful or usable.

William testing our paper prototype on Su

Prototyping & Iterations

After conducting a few rounds of usability testing, we made many iterations to our app design. Both verbal and behavioural feedback from our users allowed us to continually improve on the usability of the app.

We had a internal debate over 2 possible designs for the home screen. Hence, we conducted A/B Testing to test which version was more beneficial to our users in terms of the flow and functionality of the app. The results of our A/B Test were not very conclusive as we received mixed reviews regarding both designs. There was no clear winner.

Version A was inspired by the recent Pokemon Go craze. We thought that it might be a fun way for users to see their friends nearby on the app. However, we realised that this design would infringe on users’ privacy by pinpointing their exact location. Version A also would only allow users to see their friends within a small radius, which might be a potential limitation of the app.

Version B allowed users to see their friends on the app all across the country without revealing the exact locations of users. If a user in Yishun was heading towards Tampines, he could plan a meet-up a few hours in advance with a friend who was currently in Tampines. This would significantly increase the functionality of the app.

Based on the above reasoning, we decided to go with Version B.

Privacy Settings (Location, Contacts, Notifications)

Going back to the the key focuses of our project, to increase the likelihood of users giving the app permission for location, contacts, and notifications, we decided to only ask for permission just before it is necessary. By allowing users to first explore the app without prompting them for access to their information, users are likely to feel more at ease.

To further increase the likelihood of users providing the app with the required information, we tried to make it obvious to the users why the information the app was asking for was necessary. For instance, when users see a map in the background, they are more likely to see the link between map and location, and hopefully allow the app to use their locations.

Convince Users of the Usefulness of the App

We tried to increase the usefulness of the app by introducing a new feature which allowed users to view venues with ongoing promotions with their credit cards. When we conducted usability testing with our new prototype, users commented that this is a useful function and that they would use it.

Another function that our users really liked was the suggested activities and nearby places. Deciding what to do and where to go has become an increasingly common problem faced by many people.

By increasing the usefulness of the app, existing users would be more likely to stay on and continue using the app.

User Acquisition

To increase user acquisition, SUP users are able to send SMS invites to their friends who are not SUP users. This function kills two birds with one stone, as it allows SUP users to send invites to more friends, and it also allows non-SUP users to be included in the loop, increasing the user acquisition rate.

On a side note, I believe that if a product is truly useful, existing users would spread the word and encourage their friends to use it too. By focusing on making the product more useful, new users will be drawn to it as well.

SUMMARY

Through this project, I witnessed the importance of doing user research and usability testing before investing resources to develop a product that might not be useful or usable. It is in our human nature to get excited and begin developing our ideas without considering the possible negative consequences. That’s where UX comes in to remind us to keep our biases at bay because we are not our users.

Link to prototype: https://marvelapp.com/i9i8af

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.