Testing Steady on real people, finally

For most of the time I’ve been building Steady, the only person using it has been me. That’s normal for a personal project— you build it, you refine it, you use it yourself, you refine it again. What’s less normal is how long I let that loop run before asking anyone else to actually try it. I finally have, and it’s been sitting with me since.

It wasn’t really a decision I arrived at on my own. A family member pointed out, fairly bluntly, that if I wanted people to actually notice my work and try it out, it would make less and less sense to just keep it to myself. They were right, and I think I knew it before they even said it. It’s just easy to keep polishing something in private indefinitely, because as long as no one else has used it, nothing about it has technically failed yet.

So the test itself is intentionally low-friction: a Google Form with a link to the app attached, sent out to both family, friends, and people I don’t work with or see day to day. No script, no specific hypothesis I’m trying to confirm. I didn’t want to ask narrow questions and only get narrow answers back. I’d rather know what people actually notice first, what confuses them, what they skip past, than get a tidy yes to a question I already assumed the answer to.

There’s a version of this that would’ve been easier to write about if it were purely practical, but it isn’t only that. Steady wasn’t built for a client or a course. It was built mostly for me, out of what I actually needed, and handing that over to strangers to poke at is a different kind of exposed than handing over a school project. Not dramatic about it, just honestly a little nerve-wracking in a way client work never quite is.

I don’t have results to share yet, so this isn’t that post. It’s just the part where I stopped refining alone and let other people in.

August 2026 update: what happened next?

2 of the 3 volunteers completed the follow-up evaluation after using Steady for about two weeks. Both used it almost every day on mobile and described the experience as calm. ‘Tasks’ were the clearest source of value, while the difference between ‘Tasks’, ‘Routines’ and ‘Habit Tracker’ needed more explanation. Remembering to return without notifications was the most obvious engagement problem.

That feedback led to clearer feature descriptions, less overlap between ‘Tasks’ and ‘Routines’, a more visible ‘Habit Tracker’ explanation, gentle reminders for important dates, mobile fixes and a broader accessibility pass. A later database review also found early account adoption beyond the form responses, although account numbers are not the same as active users. The full method, results, limitations and iterations are now documented in the Steady inclusive design case study.