1,001 views
Most pet care platforms make you build a recurring schedule one booking at a time. PetBizApp’s Schedule Request grid works differently: pick a service type, click the cells on a 7-day, 8-slot grid to paint your pattern, click again to clear it — done. What used to take a dozen clicks now takes one visual pass.
It was also the hardest single interface problem in the build so far — worth getting right, because nothing else in the market works quite like it.
What Made This the Hardest Interface Problem So Far
A traditional scheduling form asks a user to specify a recurring pattern through a series of dropdown menus and checkboxes: select the days of the week, select a start time, select a duration, repeat for every distinct service window a client needs. For a simple, single-visit-per-day pattern, this works fine. For anything more complex, a client who needs a morning walk on weekdays but a different midday visit on weekends, or a household needing two separate visit types on overlapping days, the dropdown-based approach quickly becomes a tedious, error-prone sequence of a dozen or more individual selections, each one a chance to fat-finger a day or time slot and not notice until the resulting schedule is already wrong.
The visual grid approach solves this by making the entire pattern visible and editable at once, rather than assembled piece by piece through a sequence of separate form fields. But building a grid that’s genuinely intuitive to paint patterns onto, rather than just a visually dressed-up version of the same underlying complexity, took real design iteration. Early internal versions of this grid were technically functional but visually confusing, testers struggled to tell at a glance which cells were currently selected versus empty, especially on smaller screens, and the click-to-toggle interaction wasn’t always predictable when someone tried to quickly paint a whole row or column at once.
Solving the Visual Clarity Problem
We went through several rounds of visual design specifically to solve the selected-versus-empty clarity issue, eventually landing on a combination of strong color contrast, a subtle animation on toggle so the state change is unmistakable even on a quick glance, and persistent row and column labels that stay visible even when scrolling on a smaller screen, since losing track of which day or time slot a given cell represents defeats the entire purpose of a visual grid. We also added a drag-to-paint gesture, letting a user click and drag across multiple cells to select or clear a whole range at once, which came directly out of watching early testers instinctively try to do exactly that and get frustrated when the interface didn’t support it.
Handling Multiple Service Types on the Same Grid
A meaningful share of real client schedules involve more than one distinct service type across the week, and we needed the grid to represent this without becoming visually cluttered or confusing. The current design lets a user select a service type first, paint the pattern for that service, then switch to a different service type and paint a separate, potentially overlapping pattern on the same underlying grid, with each service type getting its own distinct color so the full weekly picture stays legible even with multiple service types layered onto the same 7-day, 8-slot structure. Getting the layering right, so overlapping selections read clearly rather than as a confusing blend, required real attention to color choice and contrast, informed by direct testing with actual color-blind users to make sure the distinction between service types didn’t rely on color alone.
Why 7 Days and 8 Slots Specifically
The specific grid dimensions weren’t arbitrary. Seven days covers a full week without needing to scroll or paginate, keeping the entire pattern visible at once, which is central to the whole value of a visual approach. Eight time slots per day came out of research into how pet care businesses actually structure their daily service windows, morning, midday, afternoon, and evening visit windows, each potentially split into an earlier and later option, covers the overwhelming majority of real-world scheduling patterns we observed across the businesses we talked with during design. We considered a more granular, hourly grid at one point, but testing showed it added visual complexity without adding much real value, since almost no pet care business actually needs to distinguish between, say, a 9am and a 9:15am visit slot at the pattern level, that level of precision belongs in the specific booking details generated from the pattern, not the pattern-painting interface itself.
How This Connects to the Rest of the Scheduling System
This grid is the front-end interface for the pattern-based booking generation described in an earlier build update covering the visual sitter calendar. Once a pattern is painted here, it feeds directly into the logic that generates the actual individual bookings the pattern implies, which then appear on the sitter calendar and become subject to the same drag-and-drop rescheduling and cascade-based fallback coverage described in other build updates. Designing this grid well was a genuine prerequisite for that downstream generation logic to work smoothly, since a confusing or error-prone pattern-input interface would just push scheduling mistakes further down the pipeline rather than eliminating them.
Mobile Design Challenges
A 7-by-8 grid, 56 individually tappable cells, presents genuine challenges on a phone screen that don’t exist on a desktop browser with a full-size display and precise mouse control. Cells that are comfortably clickable on a laptop screen can become frustratingly small and imprecise to tap accurately on a phone, particularly for a user with larger fingers or anyone using the app one-handed while managing a pet at the same time. We built a responsive version of the grid that adjusts cell sizing and, on the smallest screens, allows horizontal scrolling through the day columns while keeping the currently visible days and their labels clearly anchored, rather than trying to cram all 7 days into a width that would make individual cells too small to use reliably. We tested this extensively on actual phones of varying screen sizes rather than only in a desktop browser’s mobile simulation mode, since touch-target sizing issues are one of the categories of problem that’s easy to miss without testing on real hardware.
Undo and Pattern Preview
Painting a pattern across a 56-cell grid is fast, but that same speed makes it easy to make a mistake and not immediately notice, particularly with the drag-to-paint gesture covered above, where a slightly imprecise drag could select or clear more cells than intended. We built a straightforward undo function directly into the grid interface, along with a clear preview step before a painted pattern is actually submitted and converted into real bookings, giving the user one more opportunity to review the full pattern visually and catch any mistake before it propagates into dozens of individual calendar entries that would each need to be corrected separately after the fact.
Feedback From Early Access Users
We shared an early version of this grid with a small group of beta testers before finalizing the current design, and the feedback was notably more positive than for some of our other early feature previews, several testers specifically described it as the first scheduling tool interface they’d used that actually felt faster than doing the equivalent task on paper or in a spreadsheet, which was exactly the bar we were trying to clear. The main piece of constructive feedback centered on wanting clearer visual confirmation after submitting a pattern, showing exactly how many individual bookings had just been generated across what date range, which we incorporated into the final design as a confirmation summary screen that appears immediately after a pattern is submitted.
What’s Left Before Full Release
The core grid interaction described here is functionally complete and in active beta testing, but a few refinements remain before we’re ready to call this fully released. We’re still finalizing the exact confirmation summary flow mentioned above, incorporating feedback from a slightly larger beta group than our initial testers, and running additional accessibility testing to make sure the grid works well with screen readers for visually impaired users, an area that’s genuinely harder to get right for a visual, spatial interface like this compared to a traditional form-based scheduling flow. We’d rather take the additional time to get these details right than rush a full release and have to walk back design decisions after they’re already in wide use.
Given how central this input method is to the overall scheduling experience, we’re treating the remaining polish work with real care rather than treating it as a minor afterthought once the core interaction works. Expect a follow-up update once the accessibility testing and confirmation flow refinements are complete and this feature moves from beta into general availability.
If you’re part of the current beta group, thank you for the direct feedback so far, it’s already meaningfully shaped the interface in ways we wouldn’t have arrived at through internal testing alone.
We’ll open the beta to a wider group as soon as the remaining refinements are locked in.
