Interact with my V01 protoype:

Project Brief:

Social Graces is an app to help parents manage their children’s behaviors with a positive reinforcement rewards system.

The Challenge:

For the app to be as effective as possible, and the child to feel involved with the system, we needed to create two (2) user types at launch — a parent side and a child side. This required one initial account set up by one parent/guardian that could then be used by multiple users with different permission types.

The Approach:

Initial Download

To assist with permission types, and to allow for other users (especially children) to sign-up/join an account without requiring log-in information, we created a system where the child or another guardian could join the app with an invite code.

Account Set-Up

Due to the possibility of having a handful of users under the same account, with one parent as the main account holder, account set-up for this project was very robust.

A parent user could have anywhere from 1 to 3 other parent/guardians and from 1 to 6+ children, which could cause a potentially very lengthly and frustrating experience for an initial set-up. One of the major blockers for this project was the amount of time and thought that would go into creating and maintaining a child’s contract.

Upon further research and development, we opted to instead allow an initial profile/contract set-up to be skipped or exited early. This would allow the user to get a sneak preview of the app and its capabilities without having to dedicate a significant amount of time or buy-in up front.

We found that this method of skipping the initial contract set-up, and getting a glimpse into the app sat better with the busy and always on-the-go lifestyle of our typical user.

As part of this, we needed to think through all of the different contract page empty states and how we could effectively onboard a user once they were within the app. We wanted to ensure that regardless of what stage they skipped the set-up, we were onboarding a user as best we could.

Sign-In

We also had to take into consideration how a multi-user account would function if these users were to be utilizing the same device, and how each user would get in and out of their profile. This required us to build both a log-out and a “switch user” feature, which would allow for multiple users on the same account. Due to the different permissions of a parent and a child, this further required the user to create a password set-up to get back into a parental account.

The initial solution to this required a security pin, or password, for each individual user. However, upon further development, and reassessment we pivoted directions. The only users with sensitive information were parental accounts, so child accounts later had this step removed from their sign-in flow.

Next Steps:

During the discovery phase of initial user testing, we discovered that contracts was the specific area where a user was likely to fall off, so we needed to prioritize this in our future iterations. By splitting up rules/chores into categories and building out a more robust list of options for a user to select from, we were able to come to a clearer and more concise contract set up screen.

Visually splitting up the UI into categories helped to break apart the extensive list of options a user had to choose from, and eliminated much of the overwhelmed reactions we received during our initial testing stages.

As with anything, the iterative process continued and from here we focused on building out the intricacies of the day-to-day use of the app, planned for future and premium features, and mapped out and validated our user flows for the initial App Store release.