Playshifu Parent App
This is a case study of an app designed for parents to monitor their kid's growth with the Playshifu ecosystem. This showcases extensive prototyping of our wireframes through Figma, making contextual decisions much easier for us to iterate and integrate into our product line.
The need for a Parent app
Playshifu has a wide offering of AR toys pitched at early education. These toys utilize the STEM curriculum to help educate the child. This is done with a combination of well-designed toys and apps to grab the child's attention to educate and entertain him/her. The app ecosystem grew with every new product being added to the roster. Simultaneously, we also started pitching to schools to inculcate Playshifu toys to teach STEM curriculum.
This meant that teachers and parents were keen to demand a common app where all of Playshifu's learnings could be tracked and set into a schedule. The development also saw this as an opportunity to gather feedback from the users directly and gain insights into new products.
Thus we launched research into the development of a new app, titled the 'Playshifu Parent' app, which could consolidate the learning that the child was getting through the products, set routine learning goals, and act as a one-stop identifier of the child's growth.
My role
As the senior Designer aboard the project, I had to take end-to-end responsibility for the product lifecycle. My first task was to collate user personas together from our qualitative and quantitative feedback analysis We used these as a basis to identify the pain points of our users and find the problems that needed solving for.
once we had a set of features we thought would solve our users' needs, I moved ahead to direct the minimum viable product (MVP) for this product venture. This helped us focus on the essentials and keep it lean.
I moved on to defining the flow within these feature sets. This helped us understand how our users would use the app and pitch our product placements. This was proceeded by my design of mixed fidelity prototypes using Figma. I then iterated these prototypes multiple times based on the feedback we received from the team as we tested them.
Once we nailed the flow and were happy with the prototype, I quickly defined the style guide and proceeded to design the UI.
User Personas
Like many ed-tech companies, Playshifu exists in a unique situation where the product user is different from the target customer. This means that it is important to realize that the product is being designed for the child while appealing to the parent. This subtle but important difference is often where a lot of ed-tech companies fail to fit their product.
We began our user research by consolidating personas representing the parents of the kids using Playshifu. These were created by clustering customer data and through direct feedback received from the users. Through this, we were able to understand the environment of the customer, their pain points, and how we could fulfill their needs.
Feature list & MVP creation
We gathered all the pain points together. From this, we were able to get an overview of the needs of the user. This helped us think of features that could solve these needs.
This gave us a starting point for features in the app that would solve the user's needs. This list was then appended with input from the team to create a list of features that we could theorize would be useful to our users. We shortened this list into essentials and nonessential features. This was used to create the feature set for our MVP.
We then grouped these features into different 'sections' of the app. Each section represented a set of screens where the feature would be primarily present. The ungrouped blobs represent the ways through which users would learn about the app. These constituted the app discovery.
The Minimum Viable Product shows how well the app works when all only the core features are present. This helps teams to focus on what's really important and save development time.
User flow
Once we had an overview of the different sections of the app, we decided to organize these features into a user flow in the order in which the user would use these in the app
Once the user had signed into the app and verified his profile, he can view his child's profiles in the app. These profile pages would contain the overall progress bar of the child, along the STEM curriculum. This progress consists of the concepts learned progress along the curriculum. This can also be expanded to see more details and get small trivia to test the knowledge of the child.
A tale of 2 approaches
As we moved ahead to analyzing the viability of the user flows, we got some additional feedback from our educators, who helped us gain more insight into the STEM curriculum. They helped us understand how and why it is important and how it can be better measured. This insight helped us design append a flow that emphasized the skill graph of the user.
At the same time, we wanted to integrate the flow with product pitches. This would help us cross-sell our product and encourage the user to cover more of the STEM syllabus through our products.
Each of these 'feature blobs' was expanded into a set of screens to build the low fidelity wireframes. These were iterated through time as our understanding of the flow progressed with time. Some of these screens can be seen below.
Approach 1 : Skill Focus
This approach to the user flow focuses on the detailed skill information being provided to the user. This helped the user contextualize the growth in learning the concepts through progress in the product.
This approach asks a new user to fill out a benchmark test to evaluate their child's current understanding of the concepts. This benchmark test would be necessary to move ahead with more functionalities of the app. Once we had an overview of the child's progress in a particular skill, we could take them on a deep dive into how the child could improve their skill. This data could also be aggregated into a detailed report of the child, which would help the user understand their child's progress and rank them globally if they scored particularly well.
You can click through the iphone screen shown above to interact with the flow through the figma prototype. Additionally,
You can see the Figma prototype here
Approach 2 : Product Focus
This approach to the user flow focuses on putting the product pitches at the forefront. This added an extra product page that discussed how using a particular product could help the child learn the needed STEM skills. This took a top-down approach to learn through the product through the growth page. This displayed the progress of the Playshifu set, and the concepts learned through it.
This flow focussed on the kit-specific progress and tied it to the child's development. This was a comparatively more aggressive pitch aimed at schools and creches.
You can click through the iphone screen shown above to interact with the flow through the figma prototype. Additionally,
You can see the Figma prototype here
Combining both approaches
Prototyping the flows helped the team to share the idea of the flow. It helped them have a more nuanced look at the features and how they would tie into each other. This made it easier to compare the flows and eliminated guesswork. This helped contextualize the experience of the user in a particular section. The accessibility of Figma prototypes also meant that these could be used anywhere, anytime on any device, while working remotely.
the Figma prototype can be seen here
We combined these two approaches to have the product pitch along with the skill deep-dive. These functionalities were available after the benchmark test for the student. Our STEM experts designed the benchmark test and gave the user guidance on where his/her child's understanding lies.
The prototype of both approaches combined can be seen here. Additionally,
Prototyping with Figma enables the team to get feedback early and iterate sooner. This also makes it easier for all stakeholders to understand the flow.
Style Guide
Once the flow was nailed down, I quickly began to set the UI elements in line with the existing identity. This was done with a brief typographical analysis using Rubik combined with Mikado. These fonts were chosen because they're rounded and friendly, appealing well to a young audience. Additionally, they have a good x-height and are very clearly visible, even in smaller sizes.
These elements were then combined with the wireframes to create the screens. This project is still underway.
Conclusion : How prototyping helps
Working in a fast-paced environment imposes certain limitations on the scope of research that the team can carry out before launching a product. Here it is imperative that all the stakeholders commit to a flow to avoid needlessly pivoting in the future. Discussing features and flows as a concept offers little leeway into understanding the usability of the app. It often happens that the core functionality becomes overshadowed by additional features (or bloat).
Defining the MVP is the first steam to make sure that the app's focus remains consistent throughout its journey. It offers a good starting point for the vision of the app. Prototyping the low (or high) fidelity screens offers a great way for everyone to intuitively understand and commit to the product's flows. Creating prototypes with Figma was very fast for me, which enabled us to incorporate any changes in the flow or feature set easily.
