Friends plan trips together, but the saving process can become a burden. TripFund helps friends save money as a group and discover more about their trip destination as they save.
TripFund helps friends travel together by challenging them to save money as a group
Miguel Pinto and João Araújo
Information Architecture, Wireframing, Prototyping, User Testing, UI/UX Design, Animations Prototyping
The main goals of the two weeks were to (1) understand how information should be organised and displayed on a mobile environment, (2) what patterns to apply and (3) how to maintain a consistent but dynamic Design System library while working.
We attended a Masterclass at The New Digital School about Mobile Design with Javier ‘Simón’ Cuello , a designer with experience on app design in companies like Zara, Telefónica and Yahoo. During this 5 day Masterclass, we were challenged to pick a specific problem and solve it with a solution designed specifically for mobile devices. Javier guided us through the solution building process, covering topics such as:
- Paper Prototyping
- User Testing
- Interface Design
- Design System
Friends love to travel together and they can only do so if everyone has the budget. A simple solution is often to save the necessary funds together, as a group. However, this can present some problems:
- Friends have different expenses during the year and so it’s hard to focus on saving for any specific common purpose
- Friends easily bail on the saving goals due to lack of motivation and priority changes
So how might we help friends save money together for trips?
TripFund aims to solve those two main problems by creating a different saving experience for groups.
- Save as a group — by sharing the progress of individual and group contributions. Saving is not only an individual goal, but also a team effort.
- Discover as you save — the more you save, the more information on the destination you and your friends can unlock, such as restaurants, museums, bars and so on. For example, saving 30€ will get you access to a recommendation of bars in your destination, helping you build your trip plan.
After we defined the problem to tackle and ideation phase, next steps were:
- User Flow
- Low Fidelity Wireframing
- User Testing
- User Interface Design
- Destination Page — user selects city of destination
- Trip Details — user fills in information about the saving plan
- Savings Plan — user selects if savings will occur daily, weekly or monthly
- Invite Friends — user invites friends to participate in the savings
- Feed — user has access to
- Delayed Savings — in case there are pending actions for the user to submit savings
- Discover Trip — to find out more about the trip destination and understand what information is waiting to be unlocked by savings
10. Trips — user has access to all the trips in which he/she participates
We were both familiar with the Android mobile environment, so we decided to design an Android app using Google Material Design. We started with pen and paper to create our first low-fidelity prototype. As we built the wireframes that followed the user flow, we consulted the Material Design documentation. It helped get a better sense of what components would better suit our interface goals.
While building the paper prototype, we made sure that
- The fidelity was low for speed, but understandable for testing purposes
- There were no elements such as polished details that could distract the users — at this stage we were not yet concerned with those aspects, but rather with the user flow validation.
We prepared an interactive prototype with Marvel App using photos of the paper wireframes and added links between them, creating a functionable low fidelity prototype ready for testing.
Testing & Problem Solving
Armed with our fast prototype, we quickly recruited testers. They were members of startups that are used to deal with technology in their day-to-day life.
We tested with a total of 5 people that did not have a great familiarity with money management apps.
The tests revealed problems with the interface. We gathered data and worked on solutions for the problems that we found.
Roadblocks along the way
Feed not clear enough
After creating their first trip, users were presented with the Feed page. The Feed page is the main page of the app that displays all the user’s pending tasks, such as savings of the day.
Because their first trip was created and they set their Saving Plan to start on that same day, they had to make their first saving. However, when they were led to the Feed page, they hesitated for a moment. The next action — to save their first amount of money — was not clear enough.
The reactions from users showed different aspects that proved the Feed page was not working as expected.
- There was not a clear action guide — the page did not present a clear action step. A lot of users asked themselves what they should do next to make their first payment.
- Saving Card did not have a clear call to action — in the Feed there was a card that asked for the saving of the day, but it did not stand out as an actionable card. Users had a hard time finding out the call to action.
- Saving Card looked like a Trip card — one user described the card as a card of the trip he had just created, rather than an action to be taken.
“I thought it was a card for the Barcelona trip I just created” — Imran Rahim
To solve these problems, we redesigned the way users landed on the Feed. We added an onboarding card to unveil the next action users should take. This action can be done at that moment or postponed for later. The onboarding card also works as confirmation that the trip has been successfully created.
We also redesigned the Saving Card on the Feed. To make it look less like a Trip Card we decreased the focus from the Trip by removing the trip photo and restructuring the hierarchy of the text that displays the picture.
Result after payment
After users did their first saving, they were confused with the feedback they received — an instant transition to an illustration of a camper. This illustration was meant to show the user all actions were completed and no pending actions were waiting.
However, the illustration led users to hesitate. They were not sure what it meant despite the help text below. One user actually believed the illustration theme — a camping scene — had something to do with the trip.
“Oh, so it looks like… I’m going to Barcelona to camp?” — Ana Barros
We considered different options for the illustration but ultimately chose to discard the empty screen. Instead of leaving an empty space on the feed, we saw the opportunity to engage users with content.
The feed became a place where users could find more about their future trips. The Discovery section is now available on the Feed, displaying available and locked items. The more users save, the more Discovery items they unlock about their trip destination.
Users were asked to check their overall progress after they made their first saving deposit. In our initial paper prototype we used a circular data visualization component. This component displays the user progress and the group progress. However, it was not immediate to users what their saving progress was.
We changed the data visualization component for two reasons:
- Improve data understanding
- A sustainable way to present other members saving progress
To accomplish this, we created a saving 5626progress bar that allows the interface to have as many as necessary, according to the number of members in the trip. We also included a saving progress bar for the whole group.
Better Trip Cards
Our initial Trip Card in the Trip section only contained the name and image of the trip destination. We did not understand the full potential of this card component.
When users land on the Trips section, their intent is to understand more about the trips they have. We decided to include information on:
- The trip destination — image and title
- The group saving progress — as a progress bar with the amount saved and the group goal
- The group members — photos of people participating in the trip saving
As an exercise on mobile app design, TripFund was an opportunity for us to train our skills in pattern designing, studying how to make the user interaction as smooth and as rewarding as possible.
What we did well
There are a few things we want to keep in mind and implement in future projects.
- Switching between fidelity level — It is easy to jump to higher levels of fidelity at an early stage of the project, which can undermine the consistency of the design. We always managed to switch between very close levels of fidelity, making slower but steadier jumps to different fidelity levels.
- Figma Components based workflow — From early on we decided to organize our User Interface design with Components. It helped us rapidly iterate on our designs, by staying consistent across screens and being easy to build by reusing already created elements.
- Agile board on Trello — We set an agile board on Trello, assigning the necessary tasks to the backlog. This allowed us to set the sprint for the two weeks and assign individual tasks for each one of us.
What we would change in the future
It is crucial to pin out some things we missed out or could do different on a next project:
- Ask people to test it on their phones — We did all our testing using one of our phones. We understand that in the future, in order to create a more realistic testing environment, testing should be done on the users’ phones.
- Embrace branding earlier on — This project was done in 2 weeks and the focus was to perfect the experience of a mobile app. We made the decision of not creating strong branding and kept it simple, based on Google’s Material Design. In future projects, we want to experiment with creating our own design system from earlier on, and try to be equally efficient.
- Better documentation on our process — While we were writing this case study, we remembered insights and design decisions that could have been documented better. That data could be valuable later for the project or for future ones.