© 2019 by Alea Abrams

Family Protector

Family Protector helps parents manage their family's iOS mobile devices in one spot, enabling them to set limitations on screen time, monitor and restrict access to the internet, apps, and more. 

Company

Intego

Role

UX Designer, Lead Visual Designer

I worked with Intego to design Family Protector and had the pleasure of seeing my work have a real impact on parents. Seeing that I am helping people is one of the most important aspects of my career. I was able to observe parents beginning to feel more confident in their children's internet and device safety. 

Process

I joined the project in the early days of ideation. Prior to starting, my coworkers had done some early concept testing, but little generative research. Over the course of a year my coworkers and I took this app from an idea to reality, participating in every step of the design and development process. A year of hard work resulted in three polished applications (iOS, Android, and Web). 

I was a member of a product team of 3 working on this app. Because of the small size of the team, everyone took on multiple roles and responsibilities and I was able to directly participate in most aspects of the product design. I gained valuable experience throughout the process, but my two biggest takeaways and learnings were: 

1. Test early and often (we got some of the best feedback from later usability sessions)

2. Communication between devs and designers is key, especially when working with new technology that not everyone is familiar with

Research

Since we were such a small team, as a designer I was involved in the research. Initial exploratory surveys had already been completed before I joined the team, so I used this information to identify our target customers. We decided to focus on parents with children who were in elementary school because we felt that they wanted to have the most control. I worked with the researcher on my team to create a survey to assess parental interest at different stages and, contrary to our initial beliefs, we found that parents of teenagers are actually just as concerned with their children's device usage because kids of all ages can get up to anything online. 

 

Once we identified and characterized our target user base, I worked with the researcher on my team to create an interview guide. We planned questions aimed at understanding how children are actually using their devices, how concerned parents are about this usage, and what parents are currently doing to address these concerns. Here are some interesting quotes we received: 

"Once they start clicking around, they sometimes don’t know what they are stumbling upon."

"My daughter asked Siri to show her pictures of mermaids. I looked at the screen and there was a dead mermaid."

This research yielded some pretty interesting results, shown in the visualization below. The biggest surprise for me was that children of a wide range of ages have access to multiple devices (some have their own phones, others share tablets with their siblings, and many use their parents devices). Since multiple children and adults share the same devices, there must be some way of assigning devices so that the correct management settings are in place. 

Ideation

Because we were building a brand new product, I had the privilege of ideating from scratch, which is one area of design that especially excites me. I have always been an “outside the box” thinker and in my career this translates to strength in ideation. I love brainstorming and using my creativity to translate information and data into a design solution that is a good balance of viable, feasible, and desirable.

Once we felt like we understood the space a bit better, the team was able to translate the data into product features. We identified the issues that were most concerning to parents and spent time theorizing how we might solve those issues. One such issue was application use. Not only did parents want to have the ability to monitor their children's app usage, but they also wanted to make sure that they did not have access to applications that were too mature. We decided to allow parents to set their child's are range which would limit their use to only apps rated for their age, according to the specifications on the app store. Parents do not like giving too much private information about their children, so age range was an effective way of getting the information we needed in a manner that parents were comfortable with.

These decisions took place over a series of meetings with the designers, PMs, developers, and executives all collaborating to decide what was feasible. Each meeting was focused on an individual feature with the intention of identifying what we had the capability to design and build. For each meeting, my fellow designer and I prepared our recommendations in a low-fi way to just get the conversation started. The results of this back and forth was our minimum viable product as well as a plan for future releases. 

Architecture

My team had the challenge of simultaneously designing the app on three platforms (web, iOS, and Android). There was a lot of thought and emphasis placed on fully understanding the interaction and ensuring that it would translate well between platforms. The architecture was pretty similar between the three versions, with the exception of platform conventions. To create an application in different platforms I had to do a great deal of research into standards and how to translate functionality and organization, so that the experience was not diminished in any one version. For the overall architecture, my teammate and I began with the iOS application and converted that into the web and Android versions. The main differences between the application and web versions of Family Protector is that the website is fewer pages with more functionality whereas the apps take the users to new pages for each function and feature. 

Wireframes

Once the architecture was defined, the team began to build out the wireframes and the content of the application. We split the workload by platform, so I designed the Android version while my coworker completed the iOS wireframes. This process was unique because we were able to compare how we designed the same features within different environments. Sometimes our solutions differed because of the platform and other times because we had different ideas. We were able to pull from each other and make each product better because of this collaborative process. 

This sketch shows the process of thinking through and designing the web monitoring system. I show this because it was one of the more complicated sections of the app. We needed to communicate large amounts of data to users (their child's entire web history) and allow them to either allow or block sites. We also needed to communicate the difference between websites and pages. This is an early sketch I created that shows the steps down the process a user might need to take to get to a specific site. Below is a low-fi wire flow of the sketch taken a step further.

Prototype

I was in charge of converting the rough wireframes into a functioning prototype using Invision. We then tested a series of scenarios usability testing. Initial tests were done at a lower fidelity, but as I made progress on the prototype and we learned from the research, the prototype gradually became its highest fidelity version. I worked with the research lead to conduct weekly studies to ensure that our prototype was on track and there were no usability concerns.

 

Usability Testing

Each week we would identify 2-3 issues to target and I would create an interactive UI flow to best test the concept. Our researcher would bring in about 2 people to test with, and I listened to the tests while they were being conducted. After each test, the researcher, my co-designer, and I followed each research session with a debrief where we would identify what was successful, what needed improvement, and what we would reiterate on for the next week. I found this process of consistently conducting research to be incredibly valuable and influential in my design process because I was able to learn that designers can be wrong and that is not a problem. It is good to get constructive criticism and negative feedback sometimes because without it neither you, nor the product will improve. 

Feedback

Our final form of feedback before general release was to give the app to a couple of "mommy bloggers" because we thought that they would be "super users" and would help us make sure we were 100% ready. The results were great and you can read their articles about the experience. This final research stage reminded me of the research methods described in Eric Ries's The Lean Startup. He talks about this method of guerrilla testing with experienced, or "super users." They have strong background knowledge and are able to provide valuable feedback in a very short period of time. Here are some great quotes to leave you with:

"Also, for parents (like me with my daughter!) who share their devices with their children, there’s an AMAZING feature called KidSet. This is a lifesaver for me and my daughter because I never know what she’s going to press and where she’s going to go when she’s on my phone! With KidSet you can easily assign your device to whomever is currently using it." - Mom Generations

"I can hit 'timeout' and lock his device instantly. This is much better than trying to wrestle his tablet away from him (yes, it's happened.)" - The Mama Maven