Why you should care about empty states

Too often maligned to the pile of “Nice to Have”, here I present the fourfold argument for introducing empty states; acquisition, education, retention and reactivation.

1. To allow us to acquire new users from the app store listings.

2. To educate users about what the post match value proposition is.

3. To let users invest in their profiles, giving nannies better information to match on and providing “stickiness” to buffer browsing churn.

4. To smooth the journey back into matching on reactivation.

1. Acquiring new users

In my research I found that a substantial number of both nannies and families found Koru Kids in the app store but as they can’t log in until they sign a contract they think “what’s the point in this app if all it does is direct me to the website”. Whilst there was a problem to fix (remove the log in restriction for users who haven’t signed a contract yet)— there’s also a free acquisition opportunity here to use our app store listings to drive sign ups. We would never list highly in the childcare category without more downloads and usage so we were shooting ourselves in the foot. Worse our users were actively confused by the journey they encountered when our first impression is a costly one.

2. Value Proposition education

As Steve Krug made famous in Don’t Make Me Think there’s only one thing you can be sure of about instructions or long form information — users won’t read them. So in addition to distilling our value proposition down to a compelling story we can also use the app to get new families to understand our service/value prop by letting them see the app ‘infrastructure’. My hypothesis is that a really easy and intuitive way to understand what we actually will do for them in once they’ve entered into a contract is to let them click around the app; from payroll to training. They’d even be able to access the new referrals tab driving growth — and you get all this value just for adding empty states.

Worth noting; this is much more a family side proposition than nanny side — as nannies get a lot of context in applying, the funnel and training.

Our present family guides— if you like the ‘user manual’ to a family — are only exposed after a nanny has signed a contract but we might envisage allowing a family to share it sooner — for example during the interview process.

3. Promoting investment in a profile

In the existing flow one of the major issues is families who join the site as browsers and never return after sign up. If we moved two of the match onboarding cues (Direct Debit and Family guide prompts) to this stage, we would prompt new families to invest in their profiles and show off some of the value of our service simultaneously.

After going through the effort of creating a family guide and/or setting up a direct debit mandate, users would have more of a reason to return to the service having already invested time in creating these resources within our ecosystem.

Furthermore, apart from being able to trial a nanny without further admin or on finding a better match because nannies now have far better and detailed information about their job offer, new families who opt to complete these steps send us a very strong signal about their intent to become an employer through Koru Kids.

In an extension of 2. (Value Prop Education) even showing these steps illustrates without talking at a customer that we’ll take care of all their payroll needs and help structure all the nitty gritty of what being a nanny for your family looks like for any future nanny.

N.B. whilst much of the family guide would be helpful to a new nanny interviewing with a family fields contain Special Category PII and would need to be obscured. I’ve shown the matched concept here.

4. Reactivation

Finally, the reactivation journey was broken and empty states provided an additional opportunity to smooth them.

With the success of an earlier project, app download rates were >95% of families with a Koru Kids nanny (customers) all of whom retain access to the app even if they no longer employ a Koru Kids nanny. Furthermore, our analytics were clear that once a match goes live the app becomes the default way for a customer to interact with Koru Kids and my hypothesis would be that they find it natural and easier (thanks to easier log in) to return there.

On requesting a log in link or opening their app, families without a nanny presently, weren’t directed to search but to the app which didn’t display any relevant content for them. Having some empty states in the app would handle these journeys that were dead ends for returning customers.

Early concepts for empty states in app

Your nannies view for families

• Prompts to fill in family guide and direct debit mandate on the landing view lead the users into investing more time and effort into their profiles that would be painful to lose.
• Empty state that routes them into matching (where they can find a nanny on the site) ease sign up, repurchasing and reactivation journeys.

1.1 Pop up to push new families into matching. 1.2 CTAs to a new user to complete their Direct Debit & Family Guide. How the app’s Nannies view changes it’s empty state depending on the customers status (3.1 never hired a nanny, 3.2 returning customer, 3.3 present customer)

New shifts and pay view for nannies

Whilst I’ve largely focussed on the value that introducing empty states for our customers (families) brings to the business, there are clear symmetries with the nanny views in showing how the product works rather than telling.

• 2.1: A new nanny who’s yet to work a shift can see that they are expected to add their shifts under the Shifts part of the app (we may flip this to be “Pay” in future and in keeping with the designs for 2.2 & 2.3).
• 💡 We could even expose the shift reporting views to nannies not yet working — as they have no contracts to record a shift against they would not be able to create a shift but they will be able to see what happens. For nannies who’ve worked a cash in hand trial we may find their usage of the shift reporting a helpful way to catch unwitting off-platform behaviour.
• Presently 2.1 returns each month — causing anxiety to nannies who rely on it over their banking apps to keep track of their monthly earnings. Assuming we can persist paid months in app, I proposed that once a nanny has recorded a shift 2.2 becomes their default shifts/pay home. It too may frequently have an empty state — the illustration would be the same as 2.1
• 2.3 is a mock up for a new empty state for Pay where a nanny has no historic paid shifts (image is stock from Pablo Stanley for illustrative purposes only).