COMMUNITY BLOG | What I Learnt…
From Our First User Tests Activity
Dean Roberston, nooli (Canopy Member)
We’re excited to be kicking off a new series alongside our founder community titled What I Learnt… The series offers a platform for founders to candidly share learnings and insights from their journey to date. We believe the open and often vulnerable sharing of both wins and losses will support, inspire and educate the current and next generation of founders, potentially saving them precious time and heartache.
The first cab off the rank is Canopy member Dean Robertson — a second time founder who exiting his first business, Mexia, after it was sold to Deloitte in 2018. He’s now the founder of nooli, a simple, intuitive platform for busy working parents to collate the household’s information in one safe, user-friendly place. Here, Dean has mapped out his experience with nooli’s first user testing and has generously and openly laid out the wins and shortcomings associated with his test.
nooli are currently raising, so please get in touch with Dean if you’d like to hear how nooli are making the running of busy family homes so much easier.
Hey my name’s Dean Robertson, I’m the founder of nooli — a platform that helps make running the household easier.
In April we ran a two week test phase with 20 users from my network who had expressed willingness to help out with the testing of the platform.
Out of the 20 users, we only had five active testers (see Bad → Poor User Test Execution) who gave us feedback on our hypotheses.
We were testing three hypotheses with this first test phase, focussing on the use cases within a busy family household (i.e. not on community shared events).
These hypotheses were:
1) Connected Accounts: Do users mind connecting their Google accounts to nooli so we can parse their inbox and bring in the notifications they’ve asked us to?
The answer here was YES. Of our test users, few had issues connecting their Google account provided they trusted us to not read their emails. This reinforced to us that trust building is a big part of our go-to-market marketing and communication strategy.
2) Shared Household Inbox: Do users want a combined “Household Inbox” where they could have shared visibility of those notifications that required actioning?
YES. Of our active test users this was liked, provided the mechanism for getting notifications into nooli was simple. For example we could allow users to peek and select items from their inbox directly in nooli, as well as our current support for Gmail star/flagging and forwards to firstname.lastname@example.org.
3) Rapid Actioning of Emails with Taps: Do users like the ability to populate the fields of a calendar event by simply tapping on the words in the email?
YES — provided it works every time. Unfortunately we had issues with the reliability and accuracy of the tapping gestures, but that is something we’re working to rectify this month.
Unfortunately, despite this positive feedback we were told none of our test users wanted to continue using nooli after the test because of the following reasons:
1. Missing household calendar functionality to see the actions that were being created. This is under active development;
2. Clunky Household Inbox UI/UX which made it cumbersome to see who else in the house has already actioned an email, what emails have been “done”, and the ability to delete emails from nooli once actioned.
3. No user & household account profile settings pages to edit household members, set profile pics etc.
4. No Android version so non-iOS users in their household can’t join the Nooli household.
Despite the positive hypothesis tests explained above, we feel this testing phase was overall relatively unsuccessful for the following reasons:
- We weren’t clear on what was required of them to participate in the test (e.g. they need a gmail account, iOS only etc)
- Not everyone who volunteered was sincere in their willingness to take part in the effort to test a buggy product.
- We received good feedback from a few users, but the feedback was ad hoc and conceptual in nature because the app wasn’t stable.
- We had a few UI elements that weren’t functional which we should have disabled. This caused confusion and distraction about why parts of the app weren’t working, so unfrotunately they gave up on trying to use the app at all.
- We didn’t have any app tracking metrics configured yet, so we had no insight into what they were trying to do.
KEY LEARNINGS & TAKEAWAYS
- Recruit a smaller test cohort who are willing to invest the time required to be onboarded, persist with a buggy app, and provide specific feedback (verbal is ok) on the product.
- Don’t send lots of emails with long-winded or confusing instructions on how to find/download the app from Test Flight. Instead, onboard the test user personally (in person or via Zoom) to help them get the app installed for the first time, unless it’s the onboarding UX flow that we’re specifically testing.
- Be sure to help them through their first functional UX flow through the app, both to ensure they understand what the scope of the test is and to hear/see their confusion if the UX is not intuitive.