Diamond Kinetics had recently acquired sidelineHD, so the product was new to our team too. I ran 30-minute interviews with power users and kept hearing the same thing: parents described themselves as tech-savvy and said the experience was straightforward. But then they'd mention going to YouTube to learn how to start a livestream. They needed help, even if they didn't frame it that way. Our CX rep confirmed it too. She said users regularly reached out after sign-up asking what to do next.

I looked at what users saw after signing up and it was pretty clear. The team page defaulted to an empty "Highlights" tab. You haven't done anything yet, so there's nothing there. At the bottom were two bold buttons: Go Live and Score Game. Both are serious commitments that make no sense five minutes after creating a team on your couch. They were also split into separate flows, which was confusing, because from a user's perspective streaming and scoring go together for the same game. I dug around and found this split existed because that's how the backend worked. The information architecture was a mirror of the codebase, not of how anyone thinks about livestreaming.

The easiest fix would have been tooltips and walkthroughs. But the information architecture itself was wrong, and I didn't want to put a band-aid on it. The old flow asked users to pick an action first (Go Live or Score), then create a game to attach it to. People don't think that way. They think "I have a game Saturday, maybe I'll try streaming it." So I flipped the whole thing. Create the game first. Then branch into actions from there. The team page now defaults to a Schedule tab showing the game you just created. Tap the game, and you get an action sheet with everything you can do for it.

One of sidelineHD's biggest constraints is that you can't appreciate what the product does until you go through a full game. But there's a good chance you download the app on Monday and your next game isn't until Saturday. That gap was killing conversion. The new architecture spreads the setup across time. "When is your next game?" is now the first question in onboarding. During the week, users set their lineup, invite players, and configure streaming destinations. By game day, the only thing left is tapping Go Live and scoring, instead of trying to figure everything out in ten minutes at the field.

Asking users to create a game right after team creation does a lot of work at once. They're making a mental commitment to stream that specific game. We finally know when the desired action is, so we can send push notifications at the right time. The game becomes the object they interact with going forward. And they're learning the ideal usage pattern: set things up early, not at the field.

The game card and action sheet had to handle a lot of ground: three account types with different permissions, eight supported sports, two game management methods (including third-party imports), and various game states across all of them. I wrote detailed acceptance criteria broken down by component. It was the first time our team worked closely with the product owner on spec-level documentation, and it made a real difference in how smoothly engineering went.

The redesign moved the needle on every metric we cared about. Game creation jumped 23% post-onboarding, which told us users were finally understanding the new architecture and committing to a specific game upfront. Even better, teams creating two or more games went up 70%, meaning the pattern stuck beyond the first session and people were starting to use sidelineHD the way it was meant to be used. And time to first livestream dropped 73%, which closed the exact gap we set out to fix. The team that used to take a week to figure out streaming was now getting there in a couple of days. Together these numbers gave us confidence that the problem wasn't user motivation or product capability. It was the order of operations, and once we put the game first, everything downstream got easier.