Skip to chat input
Concept · Data visualization platform · No team affiliation

Elite models exist. The interface is what turns them into decisions that win!

I’ve been a sports fan my entire life, and fell in love with hockey a few years before the Utah Hockey Club became a reality. When I saw a role building internal tools for a hockey-operations group, I caught the vision immediately — take the models and analytics the experts are already producing, and build the visual layer that translates them into something usable at the speed decisions actually have to happen. The visual layer is only half of it, though. The other half is working directly with key stakeholders early — identifying the right problems before a line of code gets written, defining what the tool actually needs to do, and iterating until it earns its place in the workflow. Championship teams are built on that kind of collaboration. So are the tools that support them.

Hint: Be sure to read to the end. Hat tricks are celebrated around here.

Executive Summary

The Three Stars

The case for Sightline — and for me — the way the game hands it out after the final horn: three stars, two honorable mentions.

  1. First Star

    The problem

    Every hockey-ops department is already drowning in data. What’s scarce is the layer that translates it — turning complex analytical output into something the people making the calls can actually read, trust, and act on. That’s a product and human-centered design problem before it’s an engineering one.

  2. Second Star

    The concept

    Sightline is a decision-support platform spanning all five departments — management, coaching, scouting, player development, sports science — built on one principle: the same objective data, translated into a clear visual answer for whoever needs to make the next call.

  3. Third Star

    The fit

    I’ve shipped complex platforms from high-level objectives before — including one used by millions annually, 95% workflow simplification, 100% WCAG. The ability to translate ambiguous requirements into fast, reliable, usable tools is what I do. The gaps in the stack (Pandas, Django, Docker) close fast.

Honorable Mention · The data

Nearly every visualization here is grounded in real, public NHL and NHL Edge data. Real measurements. No invented grades, no fabricated evaluations of real players.

Honorable Mention · The fan

I’m a Utah Mammoth season ticket holder. Building the tool I’d actually want hockey people to have isn’t a stretch — it’s how I already watch the game.

The objective I gave myself

Hand me the outcome, not the ticket. So I gave myself one — the kind a decision-maker in hockey operations might actually say out loud:

Every department is sitting on data — coaching, scouting, player development, sports science. Help them turn it into decisions they trust, faster than the competition.

No spec, no schema. My first job isn’t to build — it’s to identify which decisions actually move games and seasons, understand who’s making them and what gets in their way, and define what a tool would need to look like before they’d reach for it instead of a spreadsheet.

The real problem

Hockey operations doesn’t have a data shortage problem. What’s scarce is the translation step — the work of taking complex analytical output and turning it into something the people making the calls can actually read and trust. None of them act on a number they don’t believe. So the win isn’t a more powerful model. It’s an interface so clear and reliable that the right information lands at the right moment, without anyone needing to decode it first.

Get that right and the tool earns its place. Get it wrong and it’s one more tab nobody opens. Translating complexity into clarity — that’s a product and human-centered design problem before it’s an engineering one, and it’s the part I’m genuinely good at.

How Sightline works + the demos

Sightline is the concept I landed on: a decision-support layer that translates data every department already has into a clear, usable answer for whoever needs to act. One loop, applied everywhere — objective data in, one visual answer out, human judgment on top, decision logged. The goal isn’t to replace expertise. It’s to give it a better surface to work from.

Demo Block 1 · NHL & NHL Edge data

Every visualization in the first set is built on real, public NHL and NHL Edge data — shot locations, zone time, skating speed and distance, roster and prospect structure. Real measurements, no subjective grades.

Goals by area
00012165119111202630394

Coach lens: offensive-zone areas shaded by goals scored from each area — the danger map.

The decision lens. Take one objective dataset — where shots actually come from — and render the same truth for different chairs at the table. The coach sees danger zones and coverage; the analyst sees rate and shooting percentage by location. Same data, different decision.
Work rate · teamvalue · rank /32
Top skating speed24.4 mph
4th of 32 · league 23.8 mph
High-effort bursts> 22 mph127
4th of 32 · league 86
Distance per 609.1 mi
27th of 32 · league 9.2 mi
Total distance3,665 mi
29th of 32 · league 3,727 mi
Vertical tick marks the league average.
Work rate. Skating distance, speed, and high-effort bursts — the objective side of how hard a group is actually working. Useful to a development coach and a sports scientist for very different reasons.
Zone controlshare of zone time
All situations
Even strength
Power play
Penalty kill
Zone control. Where the game is actually being played — offensive, neutral, and defensive zone time, split by even strength, power play, and penalty kill.
Player universeroster · system
NHL Roster
34players
19 F · 11 D · 4 G
22 L / 12 R shot
avg 61, 196.1 lb
In the System
18prospects
8 F · 9 D · 1 G
Drafted prospects the club holds rights to.
2024 ×112025 ×7
Player universe. The NHL roster and the prospects the club holds rights to — objective structure side by side, derived from the roster and Utah’s draft selections. (Counts only, no names; this concept doesn’t grade real people.)

Data: NHL · NHL Edge

Demo Block 2 · The platform concept

The data charts above show what the pipeline can produce. These next views show how that translates into something a coach, scout, or GM can actually use — one consistent platform, five departments, the same underlying principle.

Decision

Who do we spend the pick — or the roster spot — on?

sightline / draft board · 2026 classConcept
Loading view…

These are concept demos, kept deliberately light. The point is to show the thinking and the data instinct, not to ship the platform.

How I’d build it & where I’d ramp

The honest version of the stack.

How I’d build it

The data lives in SQL, gets shaped with Pandas into the features each view needs, and a Django backend serves it. D3 handles the heavier charts; the rink geometry is hand-built. Tailwind and React on the front end, Docker on AWS — Git, CI/CD, automated tests, real security attention, because an internal tool full of competitive information is exactly what you don’t want leaking. Built the way I already work: AI-assisted, with tools like Claude Code doing real lifting while I stay responsible for every line that ships. This site is the proof.

Where I’d ramp

I’ll be straight: Pandas, Django, and Docker are the deliberate ramps. None of them are far from something I already do well — Django is Rails’ twin, Pandas is relational thinking in memory, Docker sits on top of deployment work I’ve already done. Pair that with the AI tooling this role already wants, and the gap closes in weeks. The product instincts — the ability to take ambiguous requirements and ship something fast, reliable, and usable — are the part that can’t be ramped. That’s what I’d bring on day one.

AI isn’t an afterthought here — it’s the natural next layer. Once Sightline is logging decisions and outcomes over time, the data to train on exists. The opportunity is using that to surface patterns no individual department would catch on their own: emerging gaps in a prospect’s development curve, workload trends that precede injury, matchup tendencies that only show up across a full season of play-by-play. The goal isn’t automation — it’s giving the people making the calls a sharper picture of what they might be missing.

Ownership & the Cup

End-to-end ownership isn’t a line in a job description to me — it’s a methodology. Identify the impactful work directly with key stakeholders. Define the requirements. Build fast. QA it. Iterate. That’s exactly how I already operate — and the measure of success in this context isn’t whether the engineering is clean, it’s whether the people using the tool trust it enough to act on it under pressure. Build enough of those, and they compound. That’s how a young team becomes a contender, and how a contender eventually lifts the Cup. I’d want to own a meaningful piece of helping that happen.

Why me

I’ve helped build a large-scale scheduling platform used by millions annually — 0 to 1, from high-level objectives, 95% workflow simplification, 100% WCAG on the client-facing app. The mandate was the same shape as this role: translate complex requirements into fast, reliable workflows that real people would actually use. I’ve also shipped at production scale reaching hundreds of millions of people. I know what it means to build something that has to hold up.

Visualization across domains

Simplifying complexity for the people who need to act on it is the through-line in my work. I’ve built data-driven interfaces across e-commerce, personal finance, and accessibility-first media — products where the gap between what the data said and what the user could actually do with it was the whole problem. Different domains, same discipline: make the complex legible without losing what makes it useful. That’s the skill that transfers directly here.

Why this one’s personal

I’m a huge fan and a Utah Mammoth season ticket holder. Building the tool I’d actually want hockey people to have isn’t a stretch for me — it’s just how I already watch the game. That’s the part you can’t teach.

If this kind of thinking is useful to your team — in hockey or anywhere else — the contact page is the fastest way to reach me.

Let’s team up
Conversation

Want to talk it through?

Ask anything about the concept, the data, the build, or the gaps. The assistant can go deeper.

Ask me anything about Sightline — the concept, the data behind the demos, how I’d build it, or where I’d ramp. Or pick a question below.

This is an experimental AI assistant trained on James Briggs’s approved professional information and perspectives. It represents his professional voice, not James himself, and it’s focused on this case study. For the real conversation, reach out at hello@james.br.com.