Most household software fails for a reason that has little to do with code quality. A household is a group of people with different schedules, different comfort with technology, and different ideas about what counts as finished. A shared board has to work for the person who checks it every morning and for the person who opens it only when something is missing.
TaskFamily began as an attempt to put chores, schedules, lost items, and reminders in one place, instead of spreading them across notes, chats, calendars, and memory. The idea was straightforward: when every household commitment lives in one visible place, fewer commitments fall through the cracks. The execution turned out to be less straightforward, and the lessons came mainly from the places where the first version created friction instead of removing it.
One board instead of scattered lists
The first useful decision was consolidation. Before the board existed, a chore could live in a chat message, a school event could live in a calendar, and a missing charger could live only in conversation. None of those places was wrong on its own. Together, they made the current state of the household hard to see.
A single board changed the question from where a task was recorded to whether the task was visible. When a household member opened the board, the upcoming week, the unfinished chores, and the missing items were present in the same view. That visibility mattered more than any single feature. It also exposed a risk: when everything shares one surface, clutter spreads quickly, and the board needs clear sections and a way to hide completed work.
Chores: claiming beats assigning
The early design treated chores like tickets in a work queue. One person assigned a task, another person received it, and the system recorded the assignment. In practice, assignment created resistance. A task that arrived without discussion felt like an instruction, even when the work itself was reasonable.
Claiming worked better. When tasks were posted openly and household members chose the ones that fit their time and energy, completion rates improved and fewer tasks needed reassignment. Rotation still helped for unpopular chores, and a visible history made the rotation fair. The lesson was not that assignment is always wrong. The lesson was that a household board needs consent built into the workflow, because the people using it also live together after the task is done.
Clear definitions of done mattered just as much. "Clean the kitchen" meant different things to different people. A short checklist, a photo, or a named outcome removed most arguments about whether a chore was finished. The extra detail took a few seconds to add and saved repeated discussion later.
Schedules: a weekly glance beats a stream of reminders
Schedules exposed a different failure. The first version relied on reminders. Each event produced a notification, and each notification demanded attention at the moment it arrived. After a few days, the notifications blended together, and important events were easy to miss among routine ones.
A weekly view changed the pattern. When the coming week was visible at a glance, household members could plan around school runs, appointments, work shifts, and family events without waiting for a prompt. Reminders still had a role, but the role became narrower: a single timely reminder for an event that needed preparation, rather than a sequence of reminders for every event.
The design lesson is about timing and attention. A calendar is a planning tool first and an alerting tool second. When alerts replace planning, the household stays reactive. When the week is visible in advance, the household can prepare, rearrange, and avoid last-minute surprises.
Lost and found: location matters more than categories
Lost items were the most revealing part of the board. The first version organised items by category, with neat groups for electronics, clothing, books, and keys. That structure looked logical in a data model and performed poorly in daily use. A person searching for a missing item rarely thinks in categories. The first question is usually where the item was last seen.
Adding a last-seen location, a short description, and a photo made the lost-and-found section useful. A simple status also helped: missing, found, or returned to its place. The photo mattered because household items often share a name. Three chargers, two black umbrellas, and several water bottles are difficult to distinguish in text alone.
The broader lesson applies beyond lost items. Search works best when it matches the way people remember things, not the way a database prefers to store them. Location, appearance, and recent activity are often stronger signals than a formal category.
Reminders: fewer, later, and tied to action
Reminders were the feature most likely to be turned off. The first version sent reminders early, often, and for almost everything. The intention was helpfulness. The result was fatigue. When every task produced a reminder, no reminder carried weight.
The version that worked followed three rules. Reminders were fewer, because only time-sensitive tasks received them. Reminders arrived closer to the time when action was possible, rather than hours ahead. Reminders were tied to a specific action, such as leaving for an appointment or starting dinner preparation, rather than to a vague task name.
Snoozing also needed care. A snooze button that only delayed a reminder by a few minutes created a loop of interruptions. A snooze tied to a later, realistic time worked better, because it matched the moment when the task could actually be done.
What broke
Several choices failed in ways that are useful to name directly.
A permission model with too many roles confused the household. Admin, editor, viewer, and guest roles made sense in a workplace product, but a household needed a simpler distinction: who can change the board, and who can view it. Extra roles created questions without adding safety.
A task form with too many fields also failed. Title, priority, due date, notes, tags, recurrence, and attachments turned a ten-second entry into a longer project. People stopped adding tasks rather than filling in every field. A title and an optional date proved to be enough for most entries, with the rest available only when needed.
Duplicate tasks were another problem. Two household members could add the same chore from different places, and both copies would appear on the board. The fix was partly technical, with suggestions for similar open tasks, and partly social, with a shared view that made duplicates visible before a second copy was created.
Gamification failed most clearly. Points, streaks, and leaderboards turned shared work into competition. The household did not need a winner. It needed a fair distribution of work and a clear record of what had been done. Removing the competitive layer made the board calmer and easier to trust.
What worked
The features that survived were the quiet ones.
Single-tap completion made finishing a task feel lighter than leaving it open. Recurring chores reappeared without being recreated each week. A visible weekly view gave the household a shared sense of what was coming. A short activity history answered the common question about whether a task had already been done, without requiring a message or a phone call.
Low-friction entry mattered more than a polished interface. A task could be added in seconds, edited later, and completed with one action. The board also needed to work for the least frequent user, not only for the person who set it up. When that person could open the board, understand the current state, and act without instructions, the design was close to right.
Lessons for builders
Family software is a useful test for product thinking, because the users cannot be trained, cannot be segmented by role, and cannot be asked to read documentation before doing the dishes.
First, the design should serve the least frequent user. The person who opens the board once a week reveals more about clarity than the person who opens it every day.
Second, the current state should be obvious in seconds. A household board is checked in passing, between other activities, and a board that needs study will not be checked.
Third, notifications should be treated as a scarce resource. Every alert spends attention, and attention spent on a routine task is not available for an urgent one.
Fourth, the data model should stay close to daily language. Last-seen place, next step, and who is doing it are more useful than abstract categories and status codes.
Fifth, success can be measured by what stops being said. Fewer repeated questions about schedules, chores, and missing items are a stronger signal than a high number of tasks created.
TaskFamily is the board where these lessons were learned, and the project continues to change in response to them. The board described here is TaskFamily.
