💢 Problem Definition

Context:

This was a fictional project sparked by CareerFoundry. I had no data to inform my understanding of the problem except for the prescribed readings & research provided by the course or external articles.

In order contextualise the problem, I used my own preconceived experiences as a base, which would later evolve to include more solid understanding from external sources, user input & mentor advice.

Problem pitch:

We all face similar grievances with tangible cash being outdated, while at the same time being forced to use apps & websites that slow our efforts down.

We all lose track of cash here & there, be it with friends, family or colleagues. Why not make it simpler to be mindful of the little costs - if you take care of the pennies, the dollars will take care of themselves.

People need a way to keep track of these small costs that occur in groups. Outgoing, incoming or splitting the sum, we need a way to make it easier for those on the go. Enter PlutoPay!

👀 Pre-Research Assumptions

In the recent past, I made an effort to educate myself & become more financially diversified.

As a result, I found myself dipping into many different apps for different needs - crypto, unit trusts, tax-free accounts. All were useful, but I noticed some patterns & asked myself a few questions.

💹 What can I bring to the table that fills a gap in the market?

I felt as if there was a lack of attention surrounding the smaller costs people accumulate among friends & family, coming to the un-validated assumption that:

💸 Users want to be able to easily & efficiently split costs without the hassle of cash or credit cards.

📲 I also assumed that many bank apps are not cross compatible, & that users would appreciate an intermediary service that fills in the gaps for them.

🔍 User Research
Phase

Research goals:

• Identify what kinds of apps users currently utilise to aid in the transferal of money.

• Understand how willing users are to talk about financial service providers & if they are willing to change service providers given the right conditions.

• Uncover the patterns users have towards performing online payments between friends & family members.

• Establish the overall demand & usefulness of an app like PlutoPay to our target market.

Survey results:

I found myself in a situation where I didn’t know how to write proper survey questions. I made the rookie errors of asking leading & aspirational questions.

As a result, I edited the questions to be more open-ended, then ran a rudimentary survey that later informed how to structure & write the actual survey.

1. How do you currently settle small debts or share costs with friends or family?

2. How committed/ loyal are you to the current cost splitting methods you use?

3. How often do you use online tools or applications when transferring or receiving money?

4. Which features have been most useful for you when managing money?
(Users were allowed to choose more than one option)

🤝 Empathising With The User

User personas:

The obtained user research allowed me to amalgamate all the information into more bite-sized chunks known as personas.

The patterns found within the personal information, pain points, successes & desires shows through in these two personas.

🙇‍♀️ Although many UX designers are on the fence about whether personas are even worth the time & energy, I found it remarkably useful to see the collated information in my two ideal user groups condensed into fictitious profiles. I will definitley do it again!

🧠 Ideation Phase

At this point I had a few ideas floating around that seemed as if they would help address the personas needs & goals while eliminating pain points.

💰 Effectively remove the need for users to use their credit card or cash by building a similar tap function into the app, while allowing for other methods of payment that work easily on desktop.

Another main issue users faced was splitting costs, in response I thought it would be best to allow users the option to split costs via a similar tapping function.

💳 Why tap a card when you can have flexibility & achieve more through tapping with your phone?

Pain points:

• 🏦 Lack of cross compatibility between banks.

• 🙅‍♀️ Admin involved in keeping up with split payments, or having to ask for cash directly.

• 🏧 Having to still deal with cash in an increasingly cashless world, & the issue of cleanliness in the global COVID-19 climate.

Possible solutions:

The first possible solution:

👍 We believe that by creating an intermediary group payment function that helps banking apps be more cross-compatible for Temi, we will achieve providing Temi with a way to easily split costs with several of his friends at once without worrying about what bank they belong to.

The second possible solution:

🤹‍♀️ We believe that by creating a mobile app that allows users to easily set up recurring payments, as well as once off payment requests for Ashanti, we will achieve having Ashanti gain peace of mind with splitting costs at home & being able to quickly send reminders to friends to pay her back specific amounts.

🚧 Information Architecture

Content audit:

I performed a content audit on a similar app called SnapScan to PlutoPay to see what functions, steps & screens I might need to implement going forward. The audit also gave me key insights into effective responsiveness & display for the future desktop version of PlutoPay.

📱 Wireframes & Prototyping

🌟 I will be showing images of the most important functions of PlutoPay, this includes “Pay, Split,Request”, onboarding & home screen flows.

💻 You will see a smattering of different wireframes that illustrate the growth from low to high fidelity.

Low fidelity wireframes:

I am a relatively decent sketcher, so I tried several methods of creating low-fi wireframes. I had a blast fleshing out the functions of PlutoPay.

Mid fidelity wireframes:

After outlining (literally) what structures are best to carry through to the next iteration of wireframes, I decided to use some of the Figma community resources, namely the Lo-Fi Wireframe Kit.

🧱 Using preset design systems supplied me with the building blocks that allowed for a focus purely on structure, rather than creating my own assets.

💡 Usability Testing

Test objectives:

The online moderated usability tests all took place on Google Meets. Users were supplied with NDA forms, recruitment emails & reminder emails that helped them access the test with ease & allowed me to record them legally.

The test objectives were as follows:

🎯 Observe how well users navigate onboarding processes & whether the sign-up functionality is set up in a logical manner.

🤳 Test how users navigate the apps main functions from the home page, to what extent are different features accessible to users.

💫 Observe how users interact with the three core features of PlutoPay. Is each separate function learnable, what errors pop up?

All the information gathered was assigned a rating from Jakob Nielsen’s five-step error scale — 0 being no problem at all, to 5 being a usability catastrophe.

Findings & patterns:

There was so much data gained from each & every usability test. Each interview yielded key patterns in errors, pain points & successes, while they also yielded unique points of interest based on each user’s experience using the InVision prototype.

🔴 Icons & Wording: Iconography was not the strongest in this prototype, the main feature symbols were ambiguous. As was the wording, the paragraphs hindered more than they helped users in their journeys. Onboarding didn’t leave users with a great enough impact.

🟠 Learnability: Each function was similar to its counterparts, many users expressed how good this was for their ability to expect or anticipate what to do for the next task. I had switched up the order of tasks for users to see how they approached each feature, & for the most part, users chose the correct pathways.

🟡 Mentioned Improvements: Each user had their own useful tidbit of information on what they thought would make the experience better, a large aspect seen across all user data was consistency. Having the same options available for each feature, such as date, reference, due date, recurring tasks & so on.

Necessary design iterations:

Each set of design iterations was based on multiple points of user feedback. The below points are collated from another affinity map, outlining the key points that need to be addressed going forward.

💭 Issue:
Onboarding unclear & lacking visual impact

📝 Suggested change:
Use better copy-writing & highlight keywords to be sure users take in info.

🧐 Evidence:
Onboarding did not leave a meaningful impact on users for how to approach each separate function.

💭 Issue:
Distinguish the tapping functions different uses.

📝 Suggested change:
Make tapping unique when adding people & doing transactions.

🧐 Evidence:
Many users were confused when it came to tapping to pay & tapping to add contributors.

💭 Issue:
Input fields disappearing & ineffective iconography.

📝 Suggested change:
Have input fields be visible at all times & use familiar Google icons.

🧐 Evidence:
After users input the amount to pay, it would collapse, users mentioned that this was not ideal.

💭 Issue:
Users had difficulties in collapsing the keyboard.

📝 Suggested change:
Stop using “next” on keyboard as a CTA button & allow easy exit for users.

🧐 Evidence:
The keyboard was a major pain point for users, all users got stuck while the keyboard was active.

💭 Issue:
Differentiation between Split & Request not clear.

📝 Suggested change:
Streamline the Split process to be different from the Request process.

🧐 Evidence:
2/6 users chose incorrect methods of dealing with a split cost, Split & Request are too similar in structure.

Preference testing

I edited the screens according to the proposed solutions mentioned above, creating a new UI that was tailored to usability test data.

✨ Lessons Learned

Informed by the future:

An interesting nugget of wisdom I came across enlightened me to the possibilities of informing your current situation by looking ahead a few steps. I was faced with the predicament of not knowing how to proceed in certain tasks, so I would essentially skip ahead to save time — at first, this did not seem ideal, but I later realised that the step forward was so incremental that it was trivial to fret too much on that point. In fact, skipping ahead to the next stage of development allowed me to contextualise how the previous task should look & what it should provide me with in order to effectively tailor my deliverables to according to the brief.

Key point: Just as we remember the past & learn from it — try keeping in mind what your future may look like, so you can learn from it too!

Don’t design for yourself:

As you may have noticed, the high fidelity screens & prototype followed a very bespoke design aesthetic that seemingly popped up out of nowhere. This was my own desire to create something unique getting ahead of user research-based design decisions. Naturally, this idea to create a bespoke design died quite quickly, as it fundamentally went against user needs & expectations.

Going forward, I will be sure to not let my creative drive get ahead of me again unless it’s for the explicit creation of more called for passion projects and UI exercises for my personal enjoyment.

Ask for help:

Something I will never get tired of, asking for help. During the course of the project, I had access to mentors, tutors, several Slack communities and friends. Each and every person I went to had their own tidbit of useful information that helped me along the way. A major milestone for me was putting myself out there to ask for help from strangers, which is not necessarily a bad thing. However, I really struggled with this at first, and looking back I know I will never actively put myself in that situation again. Help is good, and I don’t know all there is to know, so what’s the harm in some support!