A table tennis club needed a replacement for a failing app. I designed the connected experience across booking, play, and club operations—with Hebrew RTL as a core requirement.
The existing app had unreliable payments and broken booking journeys. Members needed a dependable way to book and manage sessions; club operators needed a product they could run the business on. The challenge was to deliver a complete foundation while requirements and implementation evolved in parallel.
I owned the product experience across the surfaces: auditing existing Figma files, reducing an inconsistent feature set, designing the mobile app and back office, and communicating Hebrew RTL behavior. I worked closely with the product lead and development team as payment providers, pricing models, and capacity rules changed.
A long feature list risked making the replacement harder to ship and harder to use. I organized the experience around three jobs: book a table, play, and manage the session. Coach bookings, plans, replays, and tournaments became supporting layers.
This kept the first experience coherent while leaving room for later capabilities.
Selecting a slot holds it exclusively. The timer needed to stay accurate when a player backgrounded the app, then returned to pay. Working through expiry and competing-booking scenarios led to a destination-time approach and an explicit expiry state on the payment screen.
The important design work was the booking state and recovery path, as well as the countdown itself.
Some players wanted detailed statistics; others only wanted a score on the television. Requiring every player to be added created friction for the second group. I removed that requirement from match creation: Team A, Team B, and a target score were enough to begin.
Auto-rematch supports a continuing session without repeatedly returning to the app.
Duplicating every screen in Hebrew was unrealistic for the timeline. I annotated a set of the most complex RTL examples to communicate layout behavior to the developer.
A focused reference made the adaptation understandable without maintaining a second complete screen library.
The app is live for WePong members in Israel. Players book tables and manage sessions digitally, while physical buttons at the tables feed the live scoring experience. Quantitative post-launch results are not yet available in this case study.
View on Google Play ↗The measurement plan focuses on booking completion, abandonment, time to book, repeat bookings, and support requests. These indicators test whether the product makes the club easier to use and operate. Performance targets are goals for evaluation, not measured outcomes.
A multi-surface product needs a shared model of the session. Designing the handoffs between a phone, a table, and a TV was as important as designing any single screen.