Interface2018Product manager and UI/UX designerShipped

Simble Forms & Bookings

Two products constrained by one Sketch system: offline field forms and multi-resource scheduling, designed and reviewed in staging against 343 shared symbols.

Product designSketchAtomic design systemStaging QA

Simble Bookings day view with columns for staff, an hourly grid, colour-coded appointments and resource filters

I was product manager and UI/UX designer for Simble Forms and Simble Bookings. They solved different jobs—offline field data capture and multi-resource scheduling—but they were not allowed to become two piles of unrelated screens.

The system came first

I built the Sketch component library that constrained both products: 343 symbols organised around atomic patterns, semantic type and colour roles, inputs, navigation, tables, icons and state variants. This was early use of atomic, token-constrained design-system practice—not a claim to have invented it. The point was propagation: change the primitive once instead of repainting every screen.

I reviewed the implemented interfaces in staging and QA against that system. Violations went back for correction. That was design-system enforcement, not code review, and the UI/UX ownership described here is specifically Forms and Bookings. On CarbonView and other products my cross-team role was operational communication, not their product or interface design.

Forms: design for the network not being there

Entries saved locally first, carried explicit draft and sync status, and could be sent from a visible queue. Signature capture supported both drawing and photographing an existing paper signature. The system did not pretend the network—or the old workflow—would disappear because software had shipped.

Bookings: model constraints, not just time

The day view answered who was free and what the day was worth. The week view answered how the team was loaded. Availability included named breaks, split shifts, days off, locations and services each person was qualified to perform. Every flow was designed at desktop and mobile sizes rather than left to collapse afterwards.

The continuity

The current AI-native process is the same discipline at a different execution speed: build from shared primitives, review against an explicit system, return violations, and turn decisions into rules the next implementation cannot quietly ignore.

Simble Forms screens showing a form list, offline draft and sync states, and an entry-saved confirmation — Forms made local drafts and per-entry sync state visible because field work could not depend on a network.

Signature capture screen offering drawing as well as photographing or uploading a signature already on paper — Two valid routes to a signature: draw it, or capture the paper workflow that still exists.

Visible sync queue stating that entries are ready to sync — Sync was a visible product state, not invisible background optimism.

Entry filter with last-week and last-month shortcuts, custom dates and client selection — Common date questions first; custom range when the common case does not fit.

Submitted-entry confirmation with Start Another Entry as the primary action — The next action reflects field reality: people usually submit another entry.

Bookings week view with staff as rows and days as columns — Day and week views answer different operational questions, so they use different layouts.

Desktop and mobile booking calendars showing navigation and filters adapted around the preserved schedule grid — Designed at both desktop and mobile sizes; the schedule remained the invariant.