Skip to main content
JoshuaBriley.
Logatot logo

Case study

A voice app for hands that are always full.

Logatot is a voice-controlled app for people who run childcare out of their own homes. A provider can log a nap, a meal, or a diaper change just by saying it out loud, hands-free, while still watching the kids. The paperwork that used to take an evening now comes from that same record.

TL;DR

Situation
Logatot is a voice-controlled app for people who run childcare out of their own homes. I led the front end on a three-person team, in charge of the design and the app's overall structure.
Problem
Three separate provider interviews all pointed to the same problem: a job that demands constant attention leaves no time for paperwork, so providers filled it in from memory at night, and those memory-based records were the ones inspectors and food-program auditors cared about most.
Alternatives
  • Let an AI model guess what was said

    More flexible with unusual phrasing, but it can guess wrong with confidence, logging a nap that never happened into a record a parent or inspector might read.

  • Match speech against a known list, use AI ahead of time

    What's said is checked against a fixed list of known phrases. AI is used earlier, to guess how a child's name might sound in different accents, before anyone ever speaks it.

Decision
I chose matching against a known list in the moment, and using AI to prepare ahead of time instead. A record someone might use to check compliance can't afford a confident guess.
Implementation
Every voice entry is logged, even the ones the system can't fully understand. Unclear entries go to a review queue where a provider taps the correct word, which teaches the system that name for good.
Evidence
One provider said she saved over two hours a day on paperwork. Attendance, meal, and safety records now come from the same entries logged during the day, so reviewing them takes minutes instead of an evening.
Reflection
The busiest screen doesn't announce its state to a screen reader the way the rest of the app does, and the layout only adjusts at one screen size, which leaves tablets, the exact device this runs on, poorly served. Both are on my list to fix.

Receipts

Product design
  • Voice-first interaction design
  • Two-sided information architecture
  • Failure and repair flows
  • Print-first compliance documents
  • Fifteen annotated design sheets
Engineering
  • 21-module design-system helper layer
  • 21 ViewComponents, 9 namespaces
  • HTMX + 74 Alpine islands
  • Rails 7.1 domain, 51 tables
  • Deterministic voice parser
Platform
  • Picovoice Porcupine (on-device)
  • Web Speech API
  • OpenAI phonetic aliases
  • Pusher real-time
  • Stripe + association billing
Contribution
  • Lead front-end on a 3-dev team
  • ~1,100 of 1,939 commits
  • English + Spanish at parity
  • Shipped as a paid product
  • Sold direct and via associations

Step 01

Designing for hands that are full

A home daycare provider is one person: caregiver, cook, and record-keeper, often holding a toddler through a twelve-hour day. She also has to answer to three separate sets of rules, all reflected in how the app is built.

None of those rules get followed at a desk, so the paperwork used to happen after the fact, at 8pm, from memory. The whole app exists to move that record-keeping into the moment, hands-free, so the required paperwork falls out of it instead of being redone later.

Three regimes, all of them in the schema

  1. CACFP

    The federal food program reimburses a meal only if it met component requirements for the child’s age group, and only if you can prove it.

  2. State licensing

    Signed attendance records, fire drill and shelter-in-place logs, allergy and medication rosters.

  3. Tax

    The IRS home-daycare time-space percentage, which needs both business hours and the square footage used for them.

The product problem behind 8pm-from-memory

  • Memory isn’t reliable

    A nap logged from memory at 8pm is a guess, and so is a diaper change. The records that matter most legally are the least accurate ones.

  • It wears providers down

    Many providers leave this work because of the paperwork. The goal was giving them their evenings back, not just a tidier form.

  • Problems surface too late

    Finding out at month end that a lunch was missing a vegetable is too late to do anything about it.

Four roles, one authentication surface

  • The provider

    Primary user, and the hardest to design for. Mobile, interrupted, often one-handed, twelve-hour day.

  • Parents

    A dozen sessions a year at most. Mobile-first, passwordless by necessity, usually in a car park at 5pm.

  • Authorized pickups

    Each has their own PIN and their own list of children they can pick up, so custody rules are tracked, not assumed.

  • Employees

    In multi-staff accounts, clocking shifts through the same event pipeline as everything else.

All four sign in through the same account system, with each person's specific role, employee, caregiver, or authorized pickup, attached underneath. One way to log in, three different kinds of user.

Step 02

Talking to providers first

Before any screen on this page existed, I interviewed three home-based providers separately: Angie, Deborah, and Yari. I also talked with the administrators who process food-program reimbursements, and with childcare influencers who talk to that audience online.

All three providers, without hearing each other, described the same problem: watching children all day leaves no attention left for the paperwork it also requires. And they described the same fix: capture it by voice in the moment, then review it later, instead of trying to remember it at night. That's what the Voiceboard and the review queue described below are built around.

Two calls, two shipped changes

  • Accents were getting misheard

    The transcription tool wasn’t trained on the range of accents providers actually speak with, so words came through wrong before the app ever tried to understand them. That’s why the app now keeps a list of likely mishearings for each child’s name, instead of trusting the raw transcript.

  • Providers needed better proof for claims

    The people who process food-program reimbursements pointed out gaps in what the app gave providers to back up a claim, which changed both the reporting and the screens built on top of it.

“I would want to review it. Names can be difficult. A system may misunderstand a child’s name or a Spanish word. It should show me what it heard and let me approve or correct it.”
Yari, on trusting voice entry for official records, before a line of the parser existed

Source interviews, lightly edited for length: Angie, Deborah, Yari, and the cross-interview theme analysis.

Step 03

Two views of the same day

The main screen is the Voiceboard: one row per child, one column per event type, for a single day. A provider scanning twelve children needs the rows to scroll left and right together, so they stay lined up on the same point in time. Without that, the grid is twelve unrelated timelines that happen to be stacked.

How these sheets were made

Every screen went through three passes: a rough sketch to work out the shape, a clean wireframe to fix it, and that same wireframe with the reasoning written onto it. The decisions themselves came from the provider calls described above, made while the app was being built. The sheets were drawn afterward, to document that reasoning for this case study.

How a screen got built

Voiceboard, rough hand-drawn concept sketch.

Sketch

Arguing about the shape.

Voiceboard, clean wireframe without annotations.

Wireframe

Fixing it.

Annotated wireframe of the Voiceboard: live attendance tiles across the top, reminder rails for diaper changes and health checks, then a child-by-event-type grid, with callouts explaining synchronised horizontal row scrolling, per-device column visibility, and pre-rendered empty rows.

Annotated

The reasoning written on top.

A crude sketch to settle what the page is for, a clean wireframe to settle where things go, then the same wireframe with the decisions written onto it. The third pass is the one that did the work: it records why a row scrolls horizontally in sync, and why empty rows are pre-rendered rather than drawn on demand.
Annotated wireframe of the Voiceboard: live attendance tiles across the top, reminder rails for diaper changes and health checks, then a child-by-event-type grid, with callouts explaining synchronised horizontal row scrolling, per-device column visibility, and pre-rendered empty rows.
01Voiceboard

One row per child, one column per event type, one day. A grid, because the provider is scanning twelve children at once.

The parent portal shows exactly the same events as a timeline: time down the left, one child at a time. The provider is scanning twelve children at once, so the provider gets a grid. A parent is reading about one child in order, so the parent gets a chronology. The portal is read-mostly with exactly one write, messaging the provider, because every extra write surface becomes one more thing to triage during the day.

Annotated wireframe of the parent portal in desktop and mobile widths: a chronological day timeline for one child with photos and milestones weighted heavier than counts, and a single message-the-provider action, with callouts on why the portal is read-mostly.
06Parent portal

The same events as the Voiceboard, as a timeline. Same data, opposite affordance, and exactly one write surface.

Underneath both views, whether a child is checked in isn't stored as a simple yes-or-no flag. It's worked out fresh each time from the full history of check-ins and check-outs, so it can never drift out of sync with what actually happened, no matter which of the ways a check gets logged, voice, tablet, or the shared board. A wrong headcount is a licensing problem, so it was worth the extra work.

Decisions built into the system, invisible on the screen

  • Rows scroll horizontally in sync
  • Attendance derived, never stored
  • Enrolment status derived from dates
  • Soft delete: removal is a display decision
  • Column visibility per device, persistent
  • Empty rows pre-rendered for live updates
logged_event.rb ruby
# app/models/logged_event.rb
# Voice, kiosk, board, and API all write here, so this is the only
# record all four already agree on. Attendance is read, not stored.
class LoggedEvent < ApplicationRecord
  enum status: { processed: 0, pending: 1, failed: 2, unknown: 3 }

  belongs_to :child, optional: true   # a failed parse may match no one
  has_one_attached :audio             # kept, so a human can repair it

  # A parse that fails is written, not dropped. The diagnostics say
  # which half broke; the raw utterance is what the repair screen
  # renders as tappable word chips.
  scope :needs_repair, -> { where(status: :failed) }

  # occurred_at is the SPOKEN time, not the processed time, so a
  # batch logged at 3pm still reads accurately in a parent's feed.
  def self.attendance_for(child, date)
    where(child:, occurred_on: date)
      .where(event_type: %i[check_in check_out absent])
      .order(:occurred_at)
      .last&.event_type || :expected
  end
end
The event log as the one record every write path already agrees on, with the failure diagnostics that make repair possible.

Alongside

Handing the tablet to a parent

Check-in is the one moment the provider's own tablet leaves her hands. Kiosk mode signs the provider out completely first, so a parent holding the tablet has nowhere to go and no record to reach besides their own child's. Parents sign in with a link sent to their email instead of a password, since most families only use the app a dozen times a year.

Annotated wireframe of the parent-facing check-in kiosk: a 96-pixel PIN field with no submit button, a filtered child list, and an inline signature canvas, on a dark full-bleed card with no navigation, with callouts on session teardown and per-PIN child filtering.
05Check-in kiosk

Handing over the tablet signs the provider out entirely. There is nowhere to go because there should be nowhere to go.

Flow diagram of the kiosk check-in and check-out path: provider enters kiosk mode, the session is destroyed leaving only the account id, a parent enters a PIN, selects their children, signs on canvas, and the provider signs back in with one tap.
13Check in and out

Handing the tablet to a parent and taking it back, with the session torn down in between.

Flow diagram of parent access: a passwordless magic-link request that returns an identical screen for known and unknown addresses, a fifteen-minute single-use token, role resolution at the shared sign-in, and the automatic end-of-day summary email that drives the daily loop.
14Parent access

Passwordless entry and the daily loop. The email is the product; the portal is the destination.

Step 04

Treating mistakes as normal

When the app can't understand what was said, it saves the attempt instead of throwing it away, along with the raw words, a translation, and the recording. A badge shows how many are waiting for review.

On the review screen, the words appear as clickable chips. Tapping the one that was the child's name teaches the app that name, and the same mishearing gets recognized correctly every time after. A single correction keeps paying off well beyond the one record it fixed.

The app also shows what it partly understood instead of discarding it, so a provider only fills in the missing piece. And instead of announcing a failure out loud in a room full of children, the spoken reply just says “processing unknown event for unrecognized child”, while it waits for review.

Annotated wireframe of the logged-events review screen: a queue of failed voice captures, each showing the raw utterance as selectable word chips, the partially understood fields, and the retained audio, with callouts explaining the two diagnostic flags and how a correction improves recognition permanently.
04Logged events: review and repair

Where the product’s honesty lives. A failed parse renders as clickable word chips that write back into the name vocabulary.

We couldn’t spot the child’s name in this event. Help us by selecting a word below that sounds like the name. If there’s no match, no worries, just ignore this step!
The repair screen, verbatim

Step 05

How voice recognition works

A wake-word detector runs directly on the device, always listening for "log a tot", so no audio ever leaves the device just to hear that phrase. With a live microphone in a room full of other people's children, that was the first question every provider asked.

Turning speech into a saved record runs on a fixed set of rules, with no AI guessing in that step. What's said is checked against a list of known phrases, and names are matched against the class roster. An AI model making that call live would be slower and could confidently guess wrong, logging a nap that never happened. The rule-based system either finds a match or sends it to a person to review, and a non-match is treated as normal, not a bug.

AI is used earlier instead. When a child is added, it generates a list of ways that name is likely to be mispronounced or misheard, and the app checks new recordings against that list. Toddler names are short and similar to each other, so getting them right is the app's hardest problem. Corrections a provider makes in the review queue get added to that same list, so the system keeps improving.

Spanish speech gets translated to English before the app tries to match it, so one set of phrases covers both languages. A single child mentioned updates the screen right away; several children at once take a moment longer in the background, so the response never slows down.

Flow diagram of voice event logging. An on-device wake word opens transcription, which runs through a ladder of phrase matchers and roster name matching, forking into a single-child inline write, a multi-child background job, or a failed parse that lands in the repair queue with its audio attached.
11Voice event logging

Utterance to structured event, including the failure and repair path. The branch that fails is drawn at the same weight as the one that works.

The services that made it real

  • Picovoice Porcupine

    Custom wake word, WebAssembly, on-device

  • Web Speech API

    Transcription, silence-timer endpointing

  • OpenAI

    Phonetic name variants, at child creation

  • Pusher

    Per-account channels for live board updates

  • Sidekiq

    29 jobs, 4 scheduled reminder workers

  • Stripe + union API

    Direct billing and association membership

Alongside

Built for more than one kind of user

Voice helps a provider holding a child, and it helps anyone who can't comfortably type mid-task. But it can't be voice-only: everything capturable by speech can also be entered by hand, so a failed recognition always has a manual way through. Every button shows a visible outline when focused with a keyboard, status changes get read aloud to a screen reader as they happen, and printed reports always come out in plain black text, even if the provider's screen is set to dark mode.

Translation goes further than swapping button labels, because Yari said so directly in her interview: “A translated button is not enough. We need the instructions, warnings, support, and official documents to be clear too.” English and Spanish are fully supported throughout the app, not just the screens, and Spanish speech is translated before the app tries to match it against a known phrase.

Step 06

What changed for providers

The paperwork stopped being a second job. Attendance records, signed releases, food-program claims, and safety logs all come from events already captured during the day, so month end became a quick review instead of an evening of catching up. The app shipped as a paid product, sold directly and through childcare associations, but the number I'd point to first is the evening a provider got back.

2+ hrs

a day of data entry removed

reported by a provider association president

~1,100

of the project's 1,939 commits

lead front-end on a three-developer team

The evenings came back

Providers reported saving over two hours a day, once logging happened hands-free during the day instead of from memory at night.

Compliance stopped being separate work

Attendance records, signed releases, food-program claims, and drill logs all come from events already captured. Month end became a review step.

It reached real providers

Shipped as a paid product, sold directly and through childcare associations, not left as a demo.

Flow diagram of provider onboarding, from first visit through account creation, roster population by manual entry or CSV import, and first voice capture, with the empty-board drop-off marked as the critical failure point.
12Provider onboarding

The empty board is the real churn risk. That's why CSV import sits beside "Add child" instead of buried in settings.

Flow diagram of the CACFP food program: building a menu validated per meal against the age-group component matrix, duplicating a week, generating a shopping list, serving meals through the shared event pipeline, and reconciling the month-end claim from records that already exist.
15Food program

Plan a compliant menu, serve it, claim it. Validation moves to plan time, where a mistake is still an edit.

The rest of the system

Six more sheets round out the product without repeating the device: the roster and its two independent axes, the tabbed child record, plan-time CACFP validation, drills as their own task type, print-first reports, and the manual-entry tier that shipped with its own home screen.

  • Annotated wireframe of the children roster screen.
    Children roster
  • Annotated wireframe of the child record screen.
    Child record
  • Annotated wireframe of the cacfp menu planner screen.
    CACFP menu planner
  • Annotated wireframe of the calendar and drills screen.
    Calendar and drills
  • Annotated wireframe of the reports screen.
    Reports
  • Annotated wireframe of the manual-entry dashboard screen.
    Manual-entry dashboard

What providers said

It is truly remarkable to be completing a physical task and talking to the voice assistant to record it simultaneously! Now I do not have to do my data entry outside of business hours. Each day I am saving over 2 hours on data entry!!!

President

CSEA/VOICE Local 100A

I never realized how much time I had to spend filling in paperwork until I didn’t have to. Logatot has given me my evenings back.

Margaret Balko

Home-based provider

The edges

Keyboard focus works well everywhere in the app, but the Voiceboard’s screen-reader support didn’t keep pace with how complex that screen got. These are the four I would work on first.

  • Screen-reader support on the busiest screen

    The Voiceboard’s expand and collapse controls don’t announce their state to a screen reader the way the rest of the app does. That pattern is built correctly everywhere else and didn’t make it into the hardest screen. First thing I would fix.

  • A two-size layout in a three-size world

    The layout switches at one single screen-width cutoff, which leaves anything in between phone-size and desktop-size, a tablet, poorly served. That matters more here, because the kiosk is a tablet.

  • Time zones kept coming back

    Most of the recent updates to this project were fixes to how it handles time zones. That’s an honest sign of a problem I kept bounded rather than one I actually closed.

  • No offline mode

    The pieces needed for the app to work without internet exist but were never fully finished. For tablets in homes with unreliable WiFi, that’s the highest-value thing that isn’t built.

Product design engineering

Good ideas fall apart if design and engineering don’t talk.

Treating failure as normal, not exceptional, only works when the same person draws the review screen and decides what the recognition system does with a mistake. That's the kind of problem I like to work on: the ones that need design and engineering to be the same conversation. If that's the bar you’re hiring for, let’s talk.