PICK’EM did not need more complicated picking. It needed continuity — a system in which a choice leads to a result, the result to statistics, statistics to rivalry, and rivalry to story.
Pick’em mechanics are almost brutally simple. The user chooses the winner of a game. A correct pick earns one point. Then they wait for the result and check the table. That is enough to run the competition, but not enough to build an experience people want to return to between weeks.
The biggest problem does not appear at the moment of choice. It appears a moment later. The click takes a few seconds, while the season lasts for months. If the product shows only a list of games, selected picks and the current ranking, a huge part of the emotion lives outside the product: in conversations between players, memories of a spectacular loss, a run of good picks, a change of leader and anticipation of the next week.
A classic interface can record a result. It is much worse at answering the question, why that result mattered.
A typical season game has a natural rhythm: picks, waiting, result, table. Between those points, however, there is a lot of “dead time” when the product has nothing new to say.
That is where the greatest unused potential sits. A player may no longer have any decision to make, but still wants to know whether they are losing position, who is catching them, who won the week, which result changed the table, and what that change means before the next round.
The project was not meant to increase the number of clicks. It was meant to increase the meaning of what had already happened.
The final table is essential, but it reduces the season to its current state. It shows “now”; it does not show the path.
If two players have 17 points each, the table does not say that one led for three weeks, then fell after a disastrous round, while the other clawed back one point at a time and has just caught up. The numbers may be identical at the end of the week, but the stories are completely different.
That is why the main design question shifted from function to dramaturgy:
How do you make every league week have a beginning, tension, a result and a consequence — like another episode of a season?
| Area | Scope |
|---|---|
| Experience | 12 screens |
| Scoring | 1 point for a correct pick |
| Data | TheSportsDB integration + local Schedule |
| Game layer | picks, scoring, standings, week history |
| Statistics | league standings, week-by-week battle, season moments |
| Narrative | 1,230 text elements |
| Interactions | Press Conference, Trash Talk, comments |
| Typography | IBM Plex Sans + IBM Plex Mono |
The most important decision was not about color or a single screen. It was about what the product should become in the user’s mind.
Instead of designing another sports dashboard, we treated the league like its own broadcast network. Not one that merely shows the score, but one with a programme, segments, rhythm and memory of events.
That shift solved several problems at once. It gave the product a language for guiding the user through the week. It connected data with emotion. It justified commentary, articles, conferences and season summaries. Most importantly, it created a structure in which statistics do not have to pretend to be entertainment — they can remain statistics while becoming part of a larger story.
TODAY ON THE NETWORK acts as the opening slate of the broadcast. It is the moment of entering the world of the league.
MAKE YOUR PICKS is the user’s main action: the choice has to remain simple, fast and legible. We did not want to complicate the core of the game just because the rest of the product is rich.
THE BROADCAST opens the layer of commentary and league life. This is where results begin to have a voice.
LEAGUE STANDINGS shows the current balance of power.
WEEK-BY-WEEK BATTLE shows change over time and lets the user see how the ranking was formed.
SEASON MOMENTS treats data as archival and analytical material — as a chapter of the season, not another table.
The whole experience consists of 12 screens. Some are narrative segments, while others handle game mechanics and league state. The common rule is that the user should not feel as though they are moving through a random set of subpages. They should feel as though they are moving through a programme.
An early, natural direction was to use team colors more strongly. It quickly became clear, however, that the more club colors took over the layout, the less identity remained for the product itself.
Team colors were therefore reduced to details, signals and local accents. The visual system received its own palette: very dark navy as the broadcast space, red light as tension, neutral typographic fields, and cooler blue accents appearing only when they communicate data, status or the technical layer of the system.
This decision mattered more than aesthetics alone. It allows the user to watch the season through one coherent interface, while teams appear as league content rather than competing mini-brand systems.
The project consistently moved away from three easy directions.
The first was a classic fantasy dashboard: many small cards, badges, charts and colors competing for attention. It was functional, but it had no dramaturgy of its own.
The second was aggressive fan service: lots of logos, full team colors, stadium effects and decoration without hierarchy. That language quickly turned the product into visual noise.
The third was a “TV costume”: pretending to be a specific network by copying existing broadcast packages. Broadcast was meant to be the logic of the experience, not cosplay.
The API is not an invisible add-on for the developer here. It is the point where the real season enters the product.
Game data changes the state of the week. The state of the week affects scoring. Scoring changes standings and statistics. Changes in statistics create new context for the narrative engine. A single update can therefore pass through several layers of the product.
API → STATE → SCORING → STATISTICS → NARRATIVE
That is why data integration has to be designed as consciously as the interface. Excessive polling is unnecessary. Checking a game too early produces no useful information. Parallel synchronizations can perform the same work several times. Without local state, the external API starts deciding everything.
The first rule is to check the local Schedule before making a request to TheSportsDB.
The system knows which games exist, when they kick off and which results have already been stored as final. The external API is used only when local state says there is actually something worth checking.
This changes the integration from a “ask the API and see what it says” model into “I know what I need, so I ask only when it makes sense.”
Not every game that has started qualifies for checking.
In the target synchronization mechanism, the system considers only games for which at least kickoff + 2h45has passed. This buffer reduces situations in which the API is asked for a result before the game has a realistic chance of being over.
If the local Schedule contains no game meeting this condition, synchronization ends without a request to the external source.
If all completed games already have final results and the next game is still in the future, the system also performs no empty work.
Synchronization can be triggered by the presence of any active user on the page — including a logged-in administrator. It does not require a separate manual process available only to the admin.
The first active user can start the check. Subsequent users, however, cannot start a second identical process in parallel.
A lock is used for this: syncInProgress.
If synchronization is already running, another visit does not generate another set of requests. When it finishes, the system also stores lastSyncAt.
The second barrier is a cooldown: if less than 15 minuteshas passed since the last check, the system does not query the API again.
These two rules solve two different problems. syncInProgress protects against parallel execution. lastSyncAt protects against repeating the same work too frequently.
The sequence is deliberately conservative:
syncInProgress;lastSyncAt and the 15-minute cooldown;Schedule;kickoff + 2h45 without a confirmed final result;In this architecture, the external API is not the clock for the entire product. It is a data source used when the product knows that the data can actually change something.
The user does not see the lock or cooldown. What they do see is the consequence: the product does not churn without reason, standings are not updated chaotically, and multiple active users do not cause a flood of identical requests.
Good API integration is invisible in the interface but visible in the behavior of the system.
The core game remains simple: one point for a correct pick. That simplicity is strategic. The product does not need a complicated system of weights, bonuses and exceptions to generate tension. Complexity comes from the consequences of the result, not from the picking form itself.
The picking screen has one job: let the user make decisions quickly before the week begins.
That is why the visual pass could not turn this part into a poster. A striking composition still had to respect pick logic, selection states and matchup legibility. The large headline MAKE YOUR PICKS., the label WEEK 01 and the short rule ONE POINT PER CORRECT PICK. build context without competing with the actual action.
This is an important principle throughout the project: spectacle appears around the mechanics, not instead of them.
Once a game closes, the result triggers the next layer of the system. The user’s pick can be marked correct or wrong. Points change their position. Position affects standings. The history of successive standings builds the week-by-week battle. Changes can be used by Season Moments and the narrative engine.
In practice, one piece of information — the final result of a game — can change several screens at once.
This is the fundamental difference between a simple scoreboard and a season experience. A scoreboard stores the result. PICK’EM stores its consequences.
Standings answers the simplest and most important question: who is leading?
The table has to be instantly legible. Visual language can add tension, but it cannot hide the order. Position, player and season score form the basic picture of the league.
It was also important that the table not become a detached “widget.” It can interact with an illustration, a helmet or light, but its data remains more important than decoration.
Current standings shows the result. Week-by-week shows the process.
This screen shows how the rivalry changed from week to week. It reveals streaks, recoveries, drops and the moments when the league hierarchy shifted.
This is where statistics begin to function as memory. The user stops looking only at the point total. They see the trajectory of the season.
Season Moments goes one step further. It is not about another table, but about selecting from the data the events that give the season structure.
In the language of the project, this area was treated as DATA / ANALYSIS CHAPTER. This matters: the product does not pretend every number is an emotion. It shows the data first. Only then does the narrative layer give it meaning.
One of the risks was creating a typical sports panel in which every metric gets its own card, icon and color. Such a system quickly becomes information-heavy while remaining visually generic.
Instead, statistics were embedded in the dramaturgy of the page: a large number can work like a headline, week history like a narrative line, a table like the main image, and small metadata like a broadcast layer.
Not every piece of information needs its own component. It needs the right hierarchy.
The project separates two things that many sports products place in the same view: current state and history of change.
Standings should be ruthlessly fast. Within seconds, the user should see position, score and the gap to rivals. This is an operational screen.
Week-by-week battle has a different job. It is not for checking “who is first right now,” but for reconstructing the course of the rivalry. That allows for a richer analytical layer: consecutive weeks, trajectory changes and moments when the balance of power stopped being obvious.
This separation also matters for narrative. The narrative engine does not have to infer the story from one final number. It can use the difference between the current state and the earlier course of the season.
Well-designed statistics do not end the conversation. They open it.
If a player climbs several positions, the natural question is: what caused that move? If the leader holds an advantage for many weeks, how long the streak has lasted becomes more important than the raw score. If two players move almost in parallel, the data suggests a direct rivalry even if the product never labels it explicitly.
In this way, numbers become a source of context for the Commentator, articles and the Press Conference.
We did not want to add indicators just because “sports apps have lots of stats.” Every number should answer a specific user question or provide material for another layer of the system.
If a metric does not change a decision, help explain the ranking or provide narrative value, it does not deserve its own module.
This constraint protects the product from dashboard fatigue and preserves the impact of larger, genuinely meaningful data.
The narrative layer contains 1,230 text elements connected to results, standings, week history and player behavior.
What matters most, however, is not the “1,230” itself. This is not a warehouse of random jokes from which the app pulls one sentence after a week ends. The library was built like an editorial system: facts come first, then the system recognizes the type of event, then its specific state, and only at the end does it select the appropriate language variant.
That is why a single category can contain several entirely different situations. “Leader” does not mean one comment about the leader. “Pick behavior” does not mean one line about a bold choice. The same area breaks down into smaller states that carry different meaning for the league.
The narrative engine does not begin with writing. It begins with what actually happened in the game.
The system knows game results, pick accuracy, weekly score, standings, position change from the previous week, streaks, records, Joker, pick distribution and the history of earlier weeks.
From that, it detects events. Only an event can receive narrative.
This is the fundamental rule: copy may exaggerate the significance of a fact, but it may not invent the fact.
The simplest way to understand the system is to look at one category.
LEADER STATES is not one drawer labeled “leader.” Inside are five different states:
LEADER_STAYS — the leader remains in first place;LEADER_EXTENDS_GAP — the lead grows;LEADER_LOSES_GROUND — still first, but the advantage is shrinking;LEADER_RETURNS — a player returns to the top;LEADER_FALLS — the previous leader loses the lead.These are five versions of apparently the same information. In the table, each concerns position number one. In narrative, however, they become five entirely different stories: stability, dominance, pressure, return or collapse.
The library describing pick behavior works in the same way.
LONE_WOLF_WIN — one player goes against the field and is the only one to get it right;LONE_WOLF_FAIL — the lone pick ends in defeat;CONTRARIAN_PICK — a player deliberately takes the opposite side from most of the league;CONSENSUS_WIN — the group was right;CONSENSUS_FAIL — almost everyone takes the same direction and almost everyone pays for it in points.The interface still shows an ordinary pick. The narrative engine sees its relationship to the choices of the other players. That allows the same click to be interpreted later as sensible consensus, solitary courage or spectacular tactical suicide.
Not every story belongs to one player. Sometimes the table itself is the protagonist.
The TABLE SITUATIONS library distinguishes, among others:
CLOSE_TITLE_RACE — the title race tightens;RUNAWAY_LEADER — the leader begins to pull away from the field;LAST_PLACE_CHANGE — last place changes;LAST_PLACE_STAYS — the bottom of the table freezes;PACK_COMPRESSES — the pack compresses;PACK_STRETCHES — the gaps between players grow.This means the Commentator does not always have to search for a “hero of the week.” Sometimes the most important story is simply the balance of power.
The system also looks at continuity. One weak week is not yet a crisis. Two or three in a row may be.
STREAKS distinguishes a good streak, a bad streak and the moment the streak ends. COLLAPSE is a stronger state: it requires a real fall or a longer crisis. RECOVERY does not automatically mean a huge comeback — it may signal only the first signs of rebuilding. COMEBACK appears when the data genuinely shows a return to contention.
This matters because without such distinctions the league would quickly start calling every better week a “historic comeback” and every stumble a “disaster.” The system needs scale.
Records have their own library, but a record does not automatically take first place in the Broadcast.
The system recognizes, among others, RECORD_BROKEN, RECORD_TIED, BEST_WEEK_SEASON, WORST_WEEK_SEASON and the one-off FIRST_PERFECT_WEEK.
If someone improves their own record by a tiny amount for another week in a row, the result should be stored in the data, but it does not have to take over the commentary again. Narrative is not meant to read a spreadsheet. It is meant to select what genuinely changes the temperature of the league.
After the factual layer comes fictional commentary. PLAYER MINDSET is a satirical mini-report on how a player is supposedly “coping” with what has just happened in the league.
The library distinguishes states including:
CONFIDENT / DELUSIONAL / UNDER PRESSURE / RATTLED / BROKEN / PLOTTING / LUCKY / CURSED / CHAOTIC / MEDIA DARLING / PUBLIC ENEMY / FORGOTTEN
These are not statements about the participant’s real life or actual mental state. They are pure sports-show convention. A player who has lost three weeks in a row can be portrayed as someone “under pressure.” One who stays quiet for a long time and begins to recover can receive the state PLOTTING. A leader may temporarily become the “media darling,” while someone who repeatedly goes against the rest of the league can become the “public enemy.”
As a result, the table stops being made only of names and points. It starts producing characters.
HOLLYWOOD takes a real event from the private league and pretends the entire film industry has suddenly become interested in it.
This library includes different states and formats: CASTING, BIOPIC, PRESTIGE TV, DOCUMENTARY, TRUE CRIME, OSCAR BAIT, DIRECTOR, AUTEUR, AGENT, STUDIO WAR, TRAILER, METHOD ACTING, FRANCHISE, AWARDS or INDIE.
This is one of the most distinctive layers of the system because it uses deliberate disproportion of scale. The more ordinary the real fact — someone moved up one place, won the week or lost a Joker — the funnier the language of global show business becomes when it describes the event as a cultural phenomenon.
WORLD REACTIONS escalates even further. The league begins to fictionally affect reality beyond sport.
The layer can react through culture, the economy, cities, art, music, tourism, advertising, fashion, food culture, conspiracy theories, fandom or outright apocalyptic exaggeration.
Again: the fact remains true. Only the consequences are fake. Someone really did take the lead. The idea that the local economy supposedly reacted to their dominance is part of the fictional Broadcast world.
Other libraries change the point of view, not the fact itself.
CROWD REACTIONS describes the reaction of a fictional audience in the moment: cheers, boos, silence, laughter, chanting, a sudden shift in sympathy or divided stands.
BOOKMAKERS pretends to be the market reaction: moving odds, nervousness after a Joker, a change in perception of the leader, a comeback, collapse or sudden popularity of a lone wolf.
PRIZE POOL builds an absurd fantasy of future wealth: a yacht, Monaco, early retirement, conversations with an accountant, investments, taxes and a family already planning how to divide money nobody has won yet.
Each of these libraries looks at the same season through different eyes. This allows the product to return to the same situation without repeating the same perspective.
After events are detected, the system has to decide which ones actually deserve commentary.
The goal is not to report everything. If seven interesting things happened in one week, the Broadcast still needs hierarchy.
The strongest event becomes the Main Story. Alongside it, there can be at most two secondary stories. Then one reaction from the world or the crowd may appear, plus optional foreshadowing — a small signal of what might explode next week.
This makes the Commentator behave more like a sports editor than a summary generator.
A separate BRIDGES library does not describe any event. Its job is to connect beats.
It is a small but important layer. Without it, the commentary could sound like five separate cards stacked one below another: winner, leader, Joker, Hollywood, end.
A bridge allows the system to move from one topic to another and assemble several libraries into one fluid monologue. The user should not see the mechanism. They should hear one host.
The system remembers earlier stories. If the Commentator suggested a few weeks ago that someone was “plotting something,” and that player later actually wins a week, the previous motif can return as a callback.
The same rule allows running jokes to continue: the Joker curse, one player’s eternal crisis, an obsession with the Prize Pool yacht, or Hollywood repeatedly trying to buy the rights to someone’s season.
A joke should not return every week, however. Libraries have cooldowns so the league world remembers its motifs without turning them into a chorus.
The engine does not invent fake drama.
If standings barely changed, the system can choose a smaller event, build a stronger world reaction, use Player Mindset or close the episode with foreshadowing.
A boring week can still have character. It cannot have a false result.
Then the opposite rule applies: we do not try to fit everything in.
The most important facts go on air. The rest can be stored in memory, return in Week History, be used as a callback or simply remain in the statistics.
This is an important part of the system: narrative selects; data remembers everything.
When a week closes, the commentary is created once and becomes part of the league history.
Refreshing the page should not randomly generate a different “official” summary of the same week every time. By storing the finished version, every player sees the same story, callbacks retain meaning, and Screen 09 can later replay exactly the Broadcast that actually closed that week.
The system can be absurd, mean, cinematic and excessively pompous. But its foundation is very simple:
DATA = truth. RULES = dramaturgy. COPY = voice.
The 1,230 elements are valuable not because there are many of them. They are valuable because they sit inside a structure that knows when, why and from which perspective they should be used.
A PICK CREATES A RESULT. DATA CREATES CONTEXT. NARRATIVE TURNS IT INTO A SEASON.
The main league experience was built as one long programme consisting of 12 screens. Each has its own function, but all belong to the same broadcast.
This is not about twelve decorative scenes. The architecture leads the user from going on air, through picking and results, to analysis, season memory, commentary, a press conference and the final quiet ending.
The first screen after entering the league should feel like the opening of a major sports broadcast, not a dashboard.
It shows the current Week, the date, a highly visible countdown to the nearest kickoff, and all games played that day as one compact broadcast roster. Every matchup shows the teams, logos and kickoff time.
The key rule: one game does not mean one screen. Even if several games are played on a given day, the user sees them together as the programme for the day.
This screen sets the tone for the whole product: for a moment, a private league should behave like the biggest sporting event in the world.
This is the main interactive screen and the most important UX contract in the entire application.
The user learns one Week Table. The layout is not replaced depending on the phase of the week — only the data and states change.
Before kickoff, in the YOUR PICK column, the user chooses one of two teams. Opponents’ picks remain hidden as HIDDEN UNTIL KICKOFF. Joker can be assigned only to a pick the user has already made.
Each game works independently. At the exact kickoff of that matchup, its picks can be revealed while later games remain locked. After the FINAL status, the user’s own choice moves into CORRECT or WRONG, and player headers update the weekly score.
The path is fixed:
OPEN → PICKED → LOCKED → PICKS REVEALED → FINAL / CORRECT OR WRONG
The most important rule: the user learns one table; the state changes, not the interface.
This is the full-screen weekly commentary for the league.
A small GLOBAL PICK’EM NETWORKmark appears on the screen, along with the week status, a huge headline selected from the Main Story and one fluid Commentator monologue.
Much more can be working underneath: weekly results, movement in standings, Joker, form, media, crowd, Hollywood, bookmakers, Prize Pool and world reactions. The user, however, does not see the names of the libraries or the structure of the engine. They see a finished programme.
This is the screen where the narrative engine stops being backstage infrastructure and becomes the voice of the league.
Standings was not treated like a classic table.
Each player has a position, identity marker, name, change from the previous week, horizontal progress bar, total points and distance from the leader. A marker for the favorite team can appear at the end of the track.
The most important thing is to read three pieces of information immediately: who is leading, who moved up or down, and how large the gaps are.
The leader receives a clear LEADERstatus. Others can be described in relation to the leader, for example 3 PTS BEHIND. This makes the ranking behave more like a race board than a results spreadsheet.
This screen shows the points earned by every player in each individual week.
Eighteen consecutive columns create the visual rhythm of the season. Each week shows player bars, their weekly score and the winner of that round.
This is a screen for reading form: strong and weak weeks, short streaks and moments when someone won a particular round even if they did not lead the entire season.
The summary can show only the strongest statistics, such as BEST WEEK, WORST WEEK, JOKER HITS or WEEKLY WINS. The goal is not to create a wall of metrics, but to show the rhythm of the rivalry.
If the previous screen shows week by week, this one shows how those weeks built the whole season.
The main element is the CUMULATIVE POINTS OVER SEASONchart. The X axis runs from Week 01 to Week 18, the Y axis shows cumulative points, and one line represents one player.
Only events derived from real data are marked on the chart: NEW LEADER, PERFECT WEEK, JOKER FAIL, COLLAPSE, COMEBACK, BIGGEST JUMP or TITLE RACE.
This is the clearest connection between statistics and narrative. Screen 05 says: what happened in each successive week. Screen 06 says: how those weeks changed the course of the season.
The seventh screen deliberately steps outside the league’s own table and functions as a full-screen mini article.
Each piece has a story-specific headline, a protagonist, role or team, full text of roughly 60–100 words, and a visible clickable source. This is not a small trivia card.
Topics move toward stories that feel like fragments of a documentary or true crime: crimes, drugs, parties, lost fortunes, bankruptcies, scandals and the most absurd stories in NFL history.
The image system matters just as much. Sometimes a portrait works. Other times it is a stadium, tunnel, courthouse, police car, Vegas, airport, boat, money, bankruptcy document, empty locker room or another context specific to the event.
This screen expands the world of the product: PICK’EM not only comments on its own league, it also has its own editorial layer around football.
Week Browser allows the user to browse the entire season without building a second pick system.
It uses exactly the same Week Table as Screen 02. Only the selected week and the table state change.
CURRENT can be interactive. PAST is complete, showing final results, revealed picks, Jokers and the final weekly score. FUTURE shows scheduled matchups and kickoff times, but does not yet allow picks if that week is not active.
Navigation such as ← WEEK 04 / WEEK 05 / WEEK 06 → allows the user to view the season as both an archive and a future schedule.
One table. Three states. Zero interface duplication.
Screen 09 is the narrative equivalent of the Week Browser.
If Screen 08 answers the question “what happened?”, History / Broadcast answers “how did PICK’EM tell the story of that week?”.
For a completed week, the user receives the original saved headline and Commentator monologue. Historical commentary is not generated again — the archive replays exactly the version that closed that week.
If a future week is selected in Week Browser, Screen 09 does not fabricate a story. It shows an unavailable state, for example BROADCAST AVAILABLE AFTER WEEK 12 IS FINAL.
Press Conference is one module, but it has three distinct moments: the closed-room status, Attack Shop and the actual Live Press Feed.
Before the conference opens, the screen shows the event number, entry condition, countdown, player identities, their rank and — where relevant — current KD.
In the Attack Shop , the player chooses a target and the type of attack. Available levels include CHEAP SHOT — 5 KD, PRESS QUESTION — 10 KD, PERSONAL FOUL — 20 KD, PRIME TIME HIT — 35 KD and NUCLEAR — 50 KD.
The system builds the target context and randomly selects exactly three different statements for the same opponent, attack type and cost. The player chooses one, sees a preview and only then publishes. In the MVP there is no free reroll and no free-text insults.
Live Press Feed does not look like Messenger. It is a wide horizontal conversation field. Older statements remain on the left, newer ones enter from the right, and a rebuttal appears close to the attack it answers. A separate layer of Twitter-like reactions creates fictional media and crowd noise, but does not replace the players’ actual statements.
This screen shows two economies that deliberately remain separate from each other.
At the top sits the real Prize Pool for the season: one large amount, one winner after Week 18. It is not paid out every week and should not look like another points counter.
Below it runs the fictional Kilo Dollarseconomy. Points earned in the league can build KD, and KD can later be spent in the Press Conference. Spending KD never removes season points.
The middle section can show a timeline such as:
W01 +8 KD → W02 +11 KD → PRESS 01 -35 KD → ... → W10 +9 KD → PRESS 02 -20 KD
At the bottom, only 2–3 of the strongest statistics from the season economy remain: BIGGEST SPENDER, TOTAL KD BURNED, MOST ACTIVE ATTACKER, MOST ATTACKED or BANKRUPT BUT LOUD.
It should feel like an absurd sports report about money and ego, not like banking or a crypto dashboard.
The final screen deliberately slows the entire programme down.
After tables, results, statistics, editorial, the conference and the money, only the stadium, the goalpost and one quote remain.
The composition rule never changes: THE QUOTE ALWAYS SITS PHYSICALLY BETWEEN THE TWO UPRIGHTS. The uprights themselves become the typographic frame.
The shot can change: frontal, low-angle, three-quarter, night stadium, sunset, empty venue, fog, rain, snow or a ball flying over the crossbar. The quote always remains between the uprights and stays the main element.
It is a deliberately quiet ending:
goalpost + quote + stadium + silence after the game
In a private league, the result is only part of the fun. The other part is the relationship between people.
That is why the user should not be only a row in standings. The product gives them a score, a position, a week history and the opportunity to enter further narrative roles.
Press Conference is a minigame and, at the same time, an extension of the narrative.
After the events of a week, a player can be treated like a character whose result has consequences. Instead of another automatic message, an interaction appears, styled like a post-game press conference.
This feature works because it is not attached to an abstract user profile. It is grounded in the fresh context of the league.
Trash Talk gives the rivalry a more direct language. It is a space for emotions that would otherwise escape into a separate messenger.
The project does not try to replace a full social platform. The goal is to preserve interactions that strengthen the meaning of the league and feed back into the broadcast narrative.
The most interesting comments are not random. They appear when a result creates a situation worth talking about: a change of leader, a bad week, a streak or a direct duel.
This means the social layer is not a separate “community” module. It is another response of the product to data.
When score, position history, commentary and the conference all begin referring to the same person, the league gains personal memory.
The user is no longer just an account with a point total. They become someone the product can say something about.
The visual pass had a very specific contract: do not change the game engine simply because a new composition looks better.
The visual layer had to respect the existing scoring, picks, Commentator, Press Conference, JSON files, models, routing and backend.
That constraint was crucial. It separated a redesign of a working product from designing attractive mockups without obligations.
A new screen could change the position of a table, headline scale, amount of breathing room and the transition between segments. It could not, however, require a different data model just because that would be more convenient in the mockup.
If a table has a defined structure, the design has to carry it. If Press Conference has its own state, the layout has to support it. If Commentator uses JSON, the visual layer cannot replace it with static text.
This forced the design to serve a real product.
The easiest way to make an impressive redesign is to choose one ideal data state and design the entire screen around it. That works on Behance. It works less well in a product.
PICK’EM has to handle different weeks, different results and different numbers of meaningful events. The table can change shape. Commentary can be shorter or longer. Press Conference can appear in a different context. Week data is never as aesthetically obedient as a mockup.
That is why the visual pass was evaluated not only in one “hero state,” but as a system capable of accepting variable content without losing hierarchy.
Moving an element can look harmless, but in an application it can change meaning. If a status stops being associated with a specific game, if a pick starts looking like an ordinary label, or if commentary begins to dominate the result, the visual design introduces an error even when everything looks better.
That is why successive iterations were checked through the lens of contracts: what is an action, what is a result, what is state, what is commentary and what is only presentation.
The architecture includes ENTRY / LOBBY as an entry layer, but after entering, the user reaches the actual league experience. The project did not attempt to build a full authentication system from scratch as part of this work.
That was a deliberate scope decision: the league, its data, scoring, narrative and broadcast remained the most important area.
Changing the result synchronization mechanism also had to respect the existing product model.
The goal was not to create aggressive polling. The presence of an active user should be enough to trigger a check when there is a real need. The lock syncInProgress, lastSyncAt, the local Schedule, the 15-minute cooldown and the kickoff + 2h45 threshold together create a controlled mechanism.
This is an example of the same thinking as the visual pass: we are not adding an effect. We are building behavior that follows from the conditions of the system.
During the visual pass, logic was treated as a frozen layer. Hierarchy, typography, light, screen transitions and the presentation of tables could be improved. Scoring and models could not be rewritten without a real need.
This kept the visual iteration a visual iteration rather than an uncontrolled refactor of the entire application.
The most characteristic problems were not about “a nice color.” They were about relationships between elements.
On one screen, the table conflicted with a large blue rectangle and a helmet. The solution was not to remove the table, but to rebuild the layers and proportions.
The transition between Screens 01 and 02 was initially too hard. Instead of adding another effect, the image and light had to be allowed to cross the boundary between segments.
In several places there was too much empty background. The problem was not the white or navy itself, but the lack of visual information that the segments belonged to one broadcast.
These were compositional decisions, not decorative ones.
After the visual pass, the same core still works:
The new visual layer was meant to increase clarity and emotion without breaking the contracts on which the product depends.
Only a working product reveals whether the broadcast metaphor is truly a system.
If a screen looks good only with one set of names and results, it is not a system. If new commentary breaks the composition, it is not a system. If the table stops being readable on a smaller screen, art direction loses to use.
That is why final visual decisions have to be considered together with data behavior and responsiveness. The more expressive the form, the more discipline it needs in production.
The final direction does not complicate the core mechanic. The user can still enter, make picks and earn points.
What changes is everything that happens around that simple gesture.
For the player the choice has a longer life. It returns in the result, standings, week history, commentary and subsequent narrative segments.
For the league the season stops being a collection of isolated weekends. Week-by-week battle and season moments build continuity, while 1,230 narrative elements give those changes their own language.
For the product the API, local Schedule, scoring, statistics and narrative engine stop being separate functions. They become a flow.
For the identity broadcast is not decoration. It organizes entry, action, analysis, commentary and summary.
The simplest description of the whole product is:
DATA says what happened.
GAME says what it changed.
STORY says why it is worth remembering.
None of these layers would be enough on its own.
Without data, narrative would be fiction. Without mechanics, data would be a scoreboard. Without narrative, the game would end at the table.
The case study documents the product architecture, visual pass, data integration, synchronization system, statistics and narrative layer.
It does not attribute increases in retention, session time or engagement to the project without reliable data from full usage. If the product gathers that material after the season, it can be added as another layer of the case study.
Simple mechanics do not mean a simple product. One point for a correct pick can power a very rich experience when consequences are designed consciously.
The API should be queried with intent. Local state, cooldown and lock are as important as the request itself.
Statistics need time, not only value. The current table says less than the history of changes that led to it.
Narrative works only when it comes from the system. The library of 1,230 texts makes sense because it reacts to the real state of the league.
Broadcast is a structure, not a skin. The greatest value of this metaphor is that it organizes the product from entry to the season summary.
The visual pass should respect the working engine. A new form is stronger when it does not require sacrificing the logic the product already has.
PICK’EM is a project in which the weekly picking mechanic was expanded into a season-long experience built around the flow DATA → GAME → STORY.
TheSportsDB supplies game data when local state actually needs it. Scoring turns a result into a consequence for the player. Standings and week-by-week battle build memory. The narrative engine interprets change. Broadcast gives the whole system rhythm and form.
The most important result is not the number of screens or the number of texts.
It is continuity.
The user makes a choice once. The product remembers its consequences throughout the season.
DATA BECOMES RIVALRY. RIVALRY BECOMES STORY.