Making it easy to show appreciation through mobile app

Social gifting mobile application to simplify the process of sending gifts

Overview

In this project, the goal was to come up with an idea for an application that would solve a present issue. We conducted design, testing and built a Minimum Viable Product (MVP) from the ground up. This project consisted of 4 people, me being the sole designer and responsible for the UX/UI and overall design of the application.

During our initial brainstorm session, the initial idea of Wrapp was born. This came from our own experiences and something that we would like to use. For example, sending something to ones girl/boyfriend to appreciate something they did or to a friend when they help you out with something. While saying thanks is important, most of times we wish we could do something extra to show our appreciation. Looking at the market, we felt currently there were no mobile solution that solves this problem. We wanted to tackle this issue by capturing the spirit of giving, receiving and opening a gift, as we believe that is something that most people enjoys and a perfect way to solve this problem.

Validating the idea

In order to validate our assumption and determine whether or not there was a market for this type of application. We conducted guerrilla testing out on the streets and approached our targeted audience of young adults around the age 18-22 and described the general idea, asked for their feedback and whether or not this would be something that they would like to use.

In general, most people were intrigued by the idea and thought that it would be a fun thing to do! By digging deeper through general questions, we could get their opinion on what features they would like the application to have. For example, we did not mention what type of gifts the application would offer. After explaining the general concept, we instead asked them what type of gifts would they like to give to someone? A common response to this was something small and simple, such as coffee or a cookie!

Core Functionalities

By combining the notes from street interviews and discussions within the group, we outlined the core functionalities of the application:

Login/Register – To save user data
Display available products – Displaying what users can buy and gift
Select gift – Select size, quantity, attach a short message
Friends – Add/Select friends to gift
Payment – Select/add payment method
Categorize/search for product/vendor
See available gifts/unopened gifts

User Flow & Application Map

Based on the outlined core functionalities, an application map was created before I started to sketch or create wireframes. This to simulate how the application would be used and establish a coherent user flow. This gives insight of what type of interactions the user will have with the application and also flushes out different component/pages of the application.

However, one issue that we discovered during later user-tests confirmed that the initial assumption of the gifting flow had a problem. During the tests it became quickly apparent that users wanted to select friends prior to specify gift (size, amount etc) as they mentioned that it felt more natural as it creates a feeling and focus on sending a specific gift to a specific person. At the same time, they also mentioned that by having it after already deciding specific gifts, it felt weird to then select friend when they were expecting the next step to be to pay for the said gift.

Group Sketching & Wireframes

Once the outline for the user flow was presented to the group, we conducted an paper sketching session. Each step of the flow would become a seperate screen that would be designed. We prioritized the most important functionalities that was needed to create the MVP, for example the onboarding screens was not selected as it was deemed not as important as the core functionalities of gifiting.

We went through all the important flow steps one by one, everyone in the group created their version of the screen and after a 5-10 minutes sketching session per flow, everyone would present their design and the layout would be discussed. In the end we combined features and design ideas that we agreed upon within the group and I finalized these ideas into wireframes. A few examples of the wireframes can be seen down below.

User Testing

User tests were conducted throughout the different stages of the project. It was first conducted by making wireframes interactive. By doing this, we could see how the user would interact with the application and fix/iterate on any issues easily. Once the underlying interactions were good and no bigger issues were present. I started to covert the wireframes into high-fidelity mockups.

The high-fidelity mockups functioned as the MVP and was made interactive using inVision. We tested the prototype on 10 testers. These testers were a mix of our friends and classmates. The usability tests were conducted in person and we gave the testers instructions of actions they needed to perform such as gift a friend a coffe, open a gift etc. We also asked them to think-out-loud. Afterwards, in a semi-structured manner, we asked them a series of questions related to the functionalities of the application and what they thought of it after using it. After completing the user tests, discussion was held in the group about the user feedback and in the end based on our conclusions I iterated on the final design.

Some take aways and changes for the final design included:

  • Changing the sequence of gifting letting user select friends before specifying gift information
  • Limiting the message length (simillar to twitter)
  • Adding favorite feature/category
  • Adding more payment methods besides credit cards
  • Adding amount of items user would like to gift
  • Show specification of gift (size etc) for individual gift

Final User Interfaces

What have I learned?

Several heads are often better than one.
Eventhough I was the only designer in my project team, it was so interesting to incoporate the whole team while brainstorming/sketching/designing/discussing. It became a perfect team-building thing to do and I learned so much from listening to the ideas from people with different background, things that I probably would not have come up with alone.

Mapping out the user flow provides a clear picture
In other projects I’ve worked on previously, I’ve not made an application map to map out the different flow and screens. This proved to be a great asset, not only to create a clearer picture of what interfaces/interactions was needed to be created. But it also proved to be a great way to provide an easier understanding to team members without technical background.

What I'd do differently?

Dig deeper into the users
During the validation stage, we went out and asked people whether or not they like/would use the idea. Looking back at it, it would have been even better if we could go deeper into the user research by creating personas and determine pain-points to form a deeper understanding and research to back up the claim.

Back to Home