Onboarding Parent and Child with Connected Accounts for e-Wallet App: A UX Case Study

A Student Project

Project Dates:

April — July 2022. This was 10 weeks of learning and implementing along the way.

Project summary:

This was a student project in response to a design brief about a fictional app called Wallet.ly.

Wallet.ly facilitates responsible money management for children ages 10–14 and their parents. Parents send children allowance through the app, and children can make in-app purchases while also receiving appropriate guidance on budgeting, saving, and tracking spending. My role was to design a seamless onboarding experience (FTUX) for both parent and child.

The business goals for the FTUX were to make it easy, fun and painless for the user to

• create a new Wallet.ly account,
• connect the parent’s bank account or credit card, and
• transfer the first allowance amount to the child’s account.

I interpreted the business goals as the foundation for a fun and freeing experience for a child, while conveying security and reassurance to the parent, to maintain the appeal of an e-Wallet.

I worked with a provided proto-persona of a fictional child user, Caiden. I needed to design a first-time user experience for Caiden so that he could get the sense that he’d be able to experience his desires from this app. Caiden wants to:

• have fun with his friends on the app,
• not have to worry about his budget, and
• maintain trust with his parents.

Wallet.ly would also be useful to Caiden because money from his parent would be sent straight to the app for him to use.

Proto-persona of Caiden

I created a proto-persona of a fictional parent, Bill, as well. I imagined that a parent like Bill would be concerned about:

• his child’s safety,
• the security of his money on the app, and
• that his child, Caiden, will be able to enjoy money, while learning to use it responsibly.

So the design for the e-Wallet would need to include reassurances of the app’s safety and security. Parents like Bill can be aware of what their children are learning via explanations of how it will teach children about responsible money management.

Proto-persona of Bill

An e-Wallet would satisfy Caiden’s desire for freedom to use his money and be trusted by his parent, instead of having his parent check on him all the time. Similarly, Bill can rest assured knowing that Caiden is using money responsibly. It will be easier for him to remember to give Caiden allowance and teach him how to use it wisely.

Trying parent-only, child-only, and parent-and-child onboarding flows allowed me to think through the different scenarios and find the flow that used the fewest screens.

I created low fidelity wireframes using pen and paper because I first needed to try out concepts for the basic flow, without worrying about details. I tried design patterns and practices including:

• a child-only, feature-focused FTUX using a progress bar, quick win, and blank slate pattern. I thought incorporating a quick win would help the child to feel engaged right away. Empty-slate was one of the design patterns I immediately thought of, because it can suit an FTUX’s goals of getting the user to supply a funding source. A progress bar could help the child to stay patient through the steps of the process.
• a parent-only, task-focused FTUX that included a personalization step and a friendly, conversational tone to build trust with the parent. Making the FTUX task-focused would ensure that the necessary steps to get set up on the app were clear.
• a parent-and-child task-focused FTUX featuring an empty slate pattern. I thought the combination of a task-focused, empty slate pattern would get the child to create an account and would get the child engaged on the app right away, so that they would then be compelled to ask their parent to help them with funding and send their first allowance.

An onboarding flow involving both of them used the fewest number of screens, so that was the flow I moved forward with. I also thought that since Bill and Caiden both needed to be involved, it made sense to have them sign up together. Then I assembled the low-fidelity wireframe on Figma.

One of the paper mockups of a parent-and-child FTUX using a task-focused, empty slate pattern.

Two screens from the low-fidelity wireframe on Figma.

I tested this paper prototype to help me raise the fidelity to wireframe level.

I tested such a low-fidelity prototype because I wasn’t looking for feedback about the interactions or other details like the visual design or personalization options; rather I wanted to know if the flow itself worked and if users could understand what they were supposed to be doing and how. I explained to test participants that both a parent and a child would be onboarding together, and asked them to imagine the perpsectives of both parties. Participants understood how to complete tasks like account setup, setting up funding, and setting allowance amount and frequency. However, participants made comments like “maybe some of this [content] could be in an email” and felt that there were too many screens, so it felt tedious.

Medium-fidelity prototype in hand, I sought to validate the combined parent-and-child flow, and found evidence that it didn’t suit a variety of possible scenarios. I also discovered the possibility that Wallet.ly’s strategy might not fulfill users’ desires in an e-wallet.

After a couple of weeks away from the project at the end of May, I returned to the project in June, when I created a medium-fidelity wireframe of the revised low-fidelity prototype to show a new group of testers.

I responded to the feedback from the previous test and cut down on the amount of content and included progress bars and options to skip. In this round of the process, I wanted to focus my questions on the transition from child to parent account setup and the practicality of using one device, so that I could validate my choice of a combined parent-and-child flow. I also wanted to test the inclusion of language that tried to appeal to a younger audience.

A portion of the medium-fidelity wireframe that shows the transition from child-account creation to parent account creation including some of the new, “younger” language. Testers felt this part of the transition was “clunky” because of the “Parents, tap here” button. They also universally stated that the language seemed too juvenile for the 10–14 age bracket, and that the empty wallet screen made them feel like they did something wrong.

I conducted five tests, again over Zoom, with five participants. Three of the participants were completely new to the concept of Wallet.ly and this project, and two were classmates who were familiar with it. I tested with people who weren’t from my class so I could get an outside, less biased perspective. I used a Feedback Capture Grid while watching interview recordings to record notes and important quotes from the interviews, so that I would then be able to synthesize the feedback into key themes.

A screenshot of a second-round user testing session.

A number of themes emerged from synthesizing the user test data:

• Screen ordering/information architecture,
• Introduction to the app and initial screen(s),
• Visual design,
• Personalization,
• Problem Space,
• Transition between parent/child flows and interaction between the two accounts,
• Parent flow,
• Child flow.

The top three areas of feedback included issues related to:

• The problem space. Important questions raised included: How do children ages 10–14 actually want to spend their money? How much parental administration and surveillance would feel appropriate and useful to both parent and child? What about other people who might want to give a child money, like grandparents or people who hire them for small jobs? I would need to answer these questions related to the strategy of Wallet.ly by conducting further research, particularly with children and parents.
• The transition between setting up both child and parent accounts, beyond feeling “onerous” and “redundant” to testers. Testers suggested the child could be frustrated if they want to sign up but their parent isn’t present — they would have no way of saving and coming back to it later. They also thought an option for parents to sign up first could be useful, since many parents might like to “check out the app and see what it’s about before giving it to [their] kid.”

Users didn’t like the clunkiness of the “Parents, tap here button” and felt it was strange that there were two account creations in a row. They also wanted an option for parents to sign up first.

• The child flow. The language and visual design didn’t feel appropriate for 10–14 year olds, participants said, including one who was a middle school teacher. I would also need to research how to design a structure and surface layer for that age range.

Because of the time limitation of this project, and because I was already focused on improving the structure of the onboarding experience, I chose not to dive into researching the problem space.

I set design goals for a new structure based on participants’ critical feedback on the combination of parent and child account creation in one.

When considering the transition between child sign up and parent sign up, test participants asked questions like, “What if the parent is not with the child [at the moment of sign up]?” One user felt that if the child completes their part of the flow, they would be “left at a standstill” in the app.

• I needed to create a way that parent and child could each sign up on their own time.

Another user wondered, “are the accounts merged as one account with separate logins?” which communicated that it wasn’t clear to them what kind of accounts they were creating.

• I wanted to make it clear that they were separate, but connected accounts, because I interpreted Wallet.ly as having two accounts with their own settings and boundaries.

Another asked, “Where does [the ‘Parents, tap here’ button] lead?” (Would it send parents back to the homepage? Send them a link? They didn’t know what to expect).

• So I decided to get rid of the “Parents, tap here” transition altogether.

Additionally, I only allowed the child to sign up first in my current prototype, but I realized that a parent-first option should be available as well: Say Bill finds out about Wallet.ly and likes the convenience of it and the lessons it would teach Caiden — he should be able to sign up first and then invite Caiden. Or, maybe Caiden finds out about Wallet.ly from a friend and wants to sign up, and then asks for his dad’s support.

• Both a child-first sign up and a parent-first sign up should be available.

I focused on addressing four possible practical scenarios of a parent and child signing up for Wallet.ly, and left open the possibility that I might need to abandon the combined parent-child flow entirely.

I brainstormed a new structure by constructing a 2 by 2 matrix with pen and paper delineating four scenarios in which parents and children would be getting started with Wallet.ly. I put kids with their own phones on one end of a spectrum and parents who don’t give their kids phones on the other end. The other spectrum had the parent signing up first on one end and the child signing up first on the other spectrum.

Key insights revealed by the 2x2 matrix:

• When the child has their own device, an invitation process seemed natural, where whichever person signs up first could have the ability to invite the other and it wouldn’t matter who it was (i.e. parent signs up first and invites the child, or vice versa.)
• It still seemed tricky to include children who don’t have their own phone, since I learned that the combined parent-and-child sign up process didn’t work. But I could imagine Bill wanting Caiden to use Wallet.ly, still — Wallet.ly makes automating allowance easy and Bill wants Caiden to learn responsible money management from a trustworthy source, regardless of whether Caiden has his own phone or not. So this scenario still seemed important.
• The two-device scenario seemed simpler, because two devices would surely mean separate flows. I wanted to try separate flows in this second round of iteration, since I was trying to resolve the challenges of a single, combined flow.

The solution then involved creating separate apps, Wallet.ly for Kids and Wallet.ly for Parents.

I created task flows to ideate a solution to the onboarding issues without having to draw many new screens, which would have been less efficient. So I drew out task- and wire-flows so I could think about key moments in a revised onboarding process with separate accounts on two connected apps: Wallet.ly for Kids and Wallet.ly for Parents. Separate account creation on two different related apps solved pain points like, what if the parent is not available when the child wants to sign up, is it one merged account or separate accounts, whose phone should the app be used on, and what to do about the overall clunkiness of the transition from child to parent in the single flow.

I decided on a happy path of a parent-initiated sign up process across two devices.

Based on my insights from the 2x2 matrix, a parent-led relationship seemed more balanced than a child with total independence trying to use Wallet.ly. I also thought about one of the test participants’ point that from a parent perspective, parents might want to look into the app first, which implied a parent-initiated sign up process. Of course, this choice would need to be validated, and if this were a real project, it would be my priority to validate this choice of the happy path.

Then, I ideated a solution that would hopefully work for all four scenarios branching off of that happy path.

Task flow for key moment of parent inviting child to Wallet.ly for Kids.

Task flow for key moment of child receiving parent’s invitation and creating an account.

I used FigJam to create the entire flow from start to finish, including possibilities branching off of the happy path to allow for the other three scenarios. A “Child Account Generation” (CAG) code would allow the parent to invite the child to set up their account, link it to the parent’s, and begin receiving allowance.

Because I wanted to focus on resolving each of the four scenarios, I didn’t include some of the screens from my low-fidelity prototype, like the informational screens or personalization screens. I figured that should I move forward with this project, I could reincorporate those, but they wouldn’t be necessary to construct the foundational user flow that suits each of the four scenarios.

A walk-through of the final userflow:

The user flow begins with the parent flow. The parent downloads and opens Wallet.ly for Parents, and then sets up their account, either using a third-party social account or their email address. They are then prompted to verify their phone number:

In case the parent didn’t receive the one-time code, they can request another method of delivery, and then complete their account verification:

Next, the parent can set up allowance automation. They first set the allowance frequency and then the amount. These details are then confirmed before asking for payment:

Selecting any of the payment options will lead to a confirmation screen that the parent has successfully set up their account on Wallet.ly for Parents:

Here is where the transition to child account creation begins. The happy path assumes that the child has their own phone but hasn’t downloaded Wallet.ly for Kids or created an account yet. In this scenario, the parent can generate a Child Account Generation (CAG) code, and then send an invitation to download Wallet.ly for Kids via the app to the child’s phone. The child is then able to use the CAG when they create their account to link it to the parent’s existing account.

In the case that the child has already downloaded Wallet.ly for Kids, the parent only needs to trigger the invitation with a link to connect their accounts. When the child taps on this link, the app opens with a screen confirming that the accounts are linked and the child can start using their e-wallet.

If the child doesn’t have their own phone, then the parent uses the CAG code to create a new account for the child on Wallet.ly for Kids on their own phone:

Finally, all paths lead to the same congratulations page with a call to action button so the child can access their e-wallet dashboard.

The parent’s and child’s user flows are individual but linked at two different points, depending on 1) whether the child already has a Wallet.ly account and 2) whether the child has their own phone or not.

Lessons Learned

Throughout this process, I had the opportunity to learn and use best practices and common patterns for designing FTUXes. This project also reaffirmed the fundamental importance of supporting every design decision with informed reasoning. It wasn’t very surprising that combining the parent and child flows into one presented problems when tested, since my initial choice to do so was relatively arbitrary. I didn’t have much tangible information to base the choice of a combined parent-and-child FTUX, and I was glad to be able to gather information from interviews that helped me carve out a more thoughtful direction.

Who You Test With Matters

I also learned how important it is to interview participants who can be objective and who are relevant to the target audience. The contrast of feedback between classmates who were familiar with the Wallet.ly project and those who didn’t know about Wallet.ly before showed me how big of a difference bias can make. My classmates were biased because they knew about the project and the goals of the FTUX–they could see how I was trying to achieve those goals. But because the people who weren’t familiar with Wallet.ly had a more distanced perspective, they were able to give me a lot more useful feedback. One of those testers was a middle school teacher, who provided relevant insights about pre-teens that I would have never known. If I had more time, I would go even further and test with parents and children.

Challenges

One of the most challenging aspects of this project was trying to make sense of all the feedback and putting it into actionable steps. After sorting the feedback into piles, I wrote about my findings in a document and was simply overwhelmed by the amount of information. It took some time, but I was able to further boil down the information into key insights. I thought about the big picture and set priorities from there.

Feedback from the tests also raised some important considerations related to the potential need for interconnectedness of multiple accounts (e.g. parents with multiple children, grandparents who might also want to send money to their grandkids), which would be an interesting second phase of Wallet.ly to design.

Furthermore, while my first round of ideation and wireframing included a personalization step where kids could check off categories of items they might be interested in purchasing, I decided to exclude this from the user flow ideation step because I wanted to focus on just the interaction between parent and child account set up. But personalization can serve a business goal of getting users interested in the app and finding value in it before even signing up, such as in apps like Duolingo and Headspace. So I would be interested in looking at how personalization could be a positive step in the Wallet.ly onboarding process.

If I had more time to work on this project

I would have loved to do more research into the problem space. Issues related to the problem space was the largest category of feedback. I would like to learn how children actually spend their allowance and what would help parents teach their kids about financial responsibility. I’m also interested in learning how to specifically design for youth, and hopefully I’ll have the opportunity to work on designing for children in future projects.