UX Design field notes: designing a mobile app to connect parents

Yes, I designed a mobile app for parents — and I knew nothing about parenting the day I started.

How did I do it? I convinced the two enthusiastic co-founders to run a user research project with me.

When they approached me, they wanted to build an app that could connect parents trough their kids, but didn’t want to create a social network in a strict sense, also because lots of the information about kids can’t easily be shared for privacy reasons. So they were looking for some ‘hook’, some reason why people would create profiles in first place, and being parents themselves, they were sure parenting in itself was a incredibly messy area of people’s life, full of problems looking to be solved.

All of this sounded good to me, but I pointed out. ‘I am not a parent’.

And then, carefully, added:

‘Who are these parents you have in mind? Can I chat with them?’

I still grateful that they accepted, because that initial green light to testing opened up to months and months of research I run solo, but having them constantly involved in each step, and often present at testing and interviewing sessions.

I ended up interviewing parents and nannies in parks, swimming pools, lunch breaks, out of the school gates or at their homes, and testing many divergent prototypes. We ended up pivoting after getting a feedback on our first concept. And now — believe me — I know lots more about parenting than most parents do.

Me, during a field research in the mist of a swimming pool.

What I have done when I didn’t know — yet — what to do: surveys, in-person interviews, and early concept testing.

To chick-start the research, I asked my clients for lots of contacts and email, and I found ways to reach parents through different channels as well. We targeted working parents with kids under 10 years old, and run a survey and had a good response rate. The results confirmed some of our hypothesis, but some data seemed a bit too ‘eccentric’ to be ignored.

Data like the one above revealed that practical concerns like schedule, pick-ups and contacts, that the founders considered crucial, where perceived as less important than emotional ones: what parents struggled with was spending meaningful time with their kids.

How to correctly interpret these results? And more over, what kind of products could we build to target these emotional needs?

We collected a bunch of hypothesis to further validate with in-person interviews, to gather much more context about these answers, and see if we could isolate recurring patterns. We started scheduling one-to-ones interviews, asking about habits and routines, and trying to validate our intuitions about the problems we could solve.

A mum showing her diary during a user interview.

One of the most recurring things parents did during the interviews, was to show where they kept all the information about the kids activities, events and routine, that was coming from school emails, or many different kids of places, and not in analog form.

Most of them were telling us this information was fragmented and confused, and it was hard for example to remember ‘when its’ hot dog day, and my son needs to bring lunch at school’, or what is the ‘name of Mark’s nanny’, etc to coordinate between different members of the family about it.

We ended up collecting and studying lots of pictures of fridges with paper notes, or handwritten timetables and diagrams. Some of them were actually solutions, and others just representation of the problem.

Carrying on in this process, though, we also realised that most working parents did not have to remember all of this information. Lots of parents started to get confused about the schedule, because there was a person that was the expert, and that was simply not them.

After running the first 5 interviews, we realised we were completely blind to one important potential user of the app: the professional nannies.

At that point, we decided to change our research plan and interview nannies, too.

Once we started deep diving into this specific sub-group, we discovered that they were worrying about things that many parents would consider almost trivial. For them, taking care of the kids was properly work, and some apps like Whatsapp, were productivity tools, to connect to parents and other nannies.

We formed the hypothesis that this segment could be targeted to get initial traction, since we could build a better, more customised productivity tool for them. The app could enable a frictionless sharing of this information by relying on the nanny imputing the information. Nannies need to plan carefully and precisely, and they could do it in the app, while parents just want to know ‘what’s going on’, and the app could give them a sense of control and participation, whenever they needed and wanted it.

The importance of a user’s hierarchy — that is the distinction between nannies and parents attitudes and functional roles emerged during the testing, too.

Once showed some design concepts of a list of contacts, parents told us: ‘ I want to talk to other parents’, and nannies wanted to speak to other nannies, too.

Testing different ways to display contacts organising them by kid. We discovered that roles mattered: nannies wanted to quickly identify the other nannies, and mums the other mums.

What to do when once you know a bit more: create stories and tasks, and prototype the most relevant.

Interviewing in-person around 20 people in the target group gave us the opportunity to hear a lot of stories: stories about their kids, their relationships, episodes, desires, etc. We still remembered them both vividly , so we started writing them down, and assigning them to a user type, and a level of prioritisation.

After using many different techniques, like prioritisation matrix and early sketching and participatory design, we could decide on a basic structure for the app, and isolate the two stories we could start actually designing as a flow, to get further validation trough testing.

One thing that is particularly challenging in this phase, is where to start from. Some ideas are actually specific and defined, while others are vague and depending on ‘structural’ decisions about the product.

Participatory design sessions: how mums imagined the organiser and map sections of the app

Sketching with the founders and parents we interviewed was a great tool. It made their intuitions tangibles, and also helped illustrating flows and interactions details before I actually even started designing any screen.

What I have done once I have something designed: show, not tell.

Again, the presence of the two groups determined a split testing. We still tested with mums, but paid particular attention to testing with nannies, knowing that their genuine buying-in was crucial.

Testing with Pinky, a full-time nanny.
Testing with a mum and a au-pair, live-in nanny.

These interviews were particularly intense, since lots — maybe too much — was going on. Lots of social dynamics were at play, since nannies were often feeling somehow pressured to praise our solution, and also sometimes not fluent in English, and generally hyper-aware. Lots of the interpretation work of the testing was not just about what they said to us, but what they didn’t dare to say.

Nevertheless, after spending time designing prototyping way too many screens to a fairly hight level of detail, we had to conclude: the prototype didn’t work. And didn’t work to its essence. It didn’t meet the real emotional needs of the users.

One pivotal moment that helped us understanding this, was a mum that told us: ‘I have lots of ways to remember when to take him to the gym, but what I really want to know are the secrets gyms other mums use, without having to ask them directly’ A nanny accidentally told us the same: she can remember the activities by using a calendar, but ‘finding new ones in the area every day is the hard part’.

So. Back to drawing things on paper (or cardboard, in our case).

What I have done when the first prototype failed: pivot users segmentation, and therefore the product.

Yes we got it wrong. But we learnt a lot too, from investing in a fully formed solution maybe a bit too early.

What do you do at this point? Restart with the problem.

We understood that nannies and mums that had a similar reaction to our prototype, shared the same view, we felt like they belonged to the same group despite having different functional roles.

We concluded that there could be different ways to segment our target groups, that was less about their role ( mum, nanny, dad) and more about their attitude towards it. We went back to the in-person interviews notes and read them under a different lens. We mapped out this psycho-attitudinal landscape of parenting types, and our users reactions to it.

Back to the drawing (card)board

We figured that a specific group of mums and nannies are ‘in the know’, and get targeted by other types of mums that see themselves as less reliable, precise. The second group systematically relies on the other to get all the information and help with practical parenting tips.

This simple mechanism could lead to exchange information and tips as social currency inside a network of parents and nanny. We could still keep roles, profiles, and activities in the app, but the main difference would have in allowing selective social sharing of them outside the inner family circle, still without disclosing too much private information.

We were ready to put together our pieces differently, and rapidly create the ‘Kidscards’ prototype.

This last prototype was actually a much leaner product, that was easier to understand and also to build, so the client ended up realising this version, and not the one we spent most of the research time building and validating.

Parents and nannies seemed to see more value in it.

A UX happy ending, and a sort of confession.

We ended up building the second version, boldly getting rid of a prototype and a product idea that we risked to idealise just because we had spent so much time in it ( aka Ikea Effect ). This is, per se, a proper UX happy ending.

We could iterate much faster the second time because running the initial research gave us a repertoire of problems to solve, and of parenting personalities we could segment in many different ways. We got to know the (human) material so well that we could choose to manipulate it in many different ways. And we managed to (un)validate a possibly expensive idea as it was real, without even writing a single line of code.

The client was happy, and got delivered a coherent, lean, and tested product before even writing a line of code.

And now the big question. Would I do anything differently? Probably yes.

The first prototype was focusing on functionalities and interactions, and even customised it to each of the testers. Looking back, it was too early in the process to do that.

But every project has its own story and logic, and that’s why I am sharing the story of a successful product concept pivot. Cause if there is one good thing about product development is that there are no mistakes, but ways to find out what doesn’t work, and build the next step on the top of that knowledge.

So happy researching and pivoting to all of you, too! :)

Product Designer— previously @Prezi. Making stuff, adventurously.