The right game on every screen
A small box running our algorithm changes the channels over the network. Setup your sports preferences, and the right game is always on without anyone grabbing for a remote.
Every screen picks its own game
A venue can run thirty screens off one remote nobody can find. This product changes every channel over the network, so the right game is always on and nobody goes looking for it.
The onboarding let the owner choose which sports and teams are preferred.
I designed and built a working prototype using live API data. This allowed me to rapid prototype and get sign-off in a fraction of the time.
A wrong answer nobody could catch
A bar manager knows which TV package the building carries about as well as they know their phone plan by name. The worse problem is what a guess does.
A receiver reports a channel the venue does not pay for as though it were fine, so nothing catches it and the schedule fills with games that land on a subscription screen. It had already happened at a real venue.
I was asked to shorten the list of packages. I removed the question altogether.
Probe the TV, don't ask the bar
What answers the question now is a probe the technician runs on site. They pick a TV off the plan they have just drawn and walk to it. The tiers stack, so it is three checks at most. The receiver will not admit a channel is missing, but it always fails the same way, A screen shows whether or not we have that channel, and based on the channel shown, we know what package they have.
Asked for sports, listed leagues
The old screen asked which sports a venue’s customers enjoy, then offered NFL, NCAA Football, NBA and NCAA Basketball. Those are leagues, not sports, and the distinction is not pedantic: a bar across the road from a college wants the college game and not the professional one. So I split sports into two levels, with their leagues one tap behind.
Two levels instead of one long list
Tapping a sport opens the leagues inside it, and each sport reads back which of its leagues are on, so a venue can check its answer without opening anything. I grouped teams under the league they play in, because that is what stops a search for one city returning four rows that read the same. The last screen plays the whole thing back in plain sentences.
The bar already had a tablet
The first install answered a question we had not asked. Both venues already ran everything off one shared tablet behind the counter: table availability, the HVAC, and the TVs. One of them drove its screens from a wall system with its own iPad front end. Nobody was going to keep two tablets behind a bar, so the product had to absorb the one already there.
One object, two moments
The map a venue builds during setup is the screen its staff use every night, so I designed the nightly view first and the builder second. The old one showed where each TV was and nothing about what was on it. A room encloses and a group tags, so a group is worn on the TV as a colored rank rather than drawn as a region.
Prototyped on the real data
The old team screen offered three guesses based on the venue’s city, so I went and got the real list: 38,266 teams, 3,557 competitions, 119 sports, pulled from the licensed feed the product already runs on. I found 5,584 apparent duplicates that turned out to be a men’s and a women’s team sharing a name, so I labeled them rather than merging them.
I cut five screens from the onboarding flow
The onboarding process was becoming a user experience issue. I cut the venue type because I checked what read it downstream and nothing did, while the screen itself claimed to shape the programming.
A promise the product does not keep is worse than no question. I kept the address and stopped asking for it, because it was already typed at checkout. I cut the other two because they asked again for what the venue had already given at purchase.
Ported the screens back into Figma
I built the prototype out of the library’s own components, because a prototype the client can click is worth little to the engineers if the design system does not know about it. I found 23 of the 35 components those screens needed already existed, and I had the tool propose each swap for review rather than apply it, because a silent match is how a library drifts.
I Vibe-Figma twelve new components
I don’t know what to call it, but using Claude and the Figma MCP Bridge, I built the remaining twelve as components, with auto layout throughout, and 225 bindings to the existing design system’s own color, type, and spacing variables. All matched. Fully automatic.
Every one of the 69 text layers on a shared text style. I made three of them sets, carrying seven variants between them, and drew nine states of one screen once to reuse 525 times.
3D and industrial design
Setup asks somebody to tell one receiver from another, and a person can only identify hardware they recognize. So I modeled the devices themselves and exported them into the app, rather than describing a black box in words and hoping the right one was found. I put each render on the screen that asks about it. (Branding Removed)
I left the venue less to answer
The Cable section is gone: five screens, three asking a bar manager what no bar manager knows. A probe answers it instead of a person. Teams to wade through fell 3,401 to 1,927, because the leagues a venue picked did the filtering.
These count the pool the design exposes, not shipped behavior, since the engagement is active. The interface got simpler because I understood the system underneath it.
