EA brought me in to lead the redesign around the jobs that kept players returning: find a challenge, play it, and get back to a favorite game.
Pogo had grown across JavaScript, Flash, HTML, and mobile generations without a shared structure. More than fifty games sat inside a product whose navigation, category pages, challenges, account tools, and social features had accumulated over two decades.
Players reported avoiding navigation they did not understand. Game tiles did not make their contents clear, and the pages that mattered most buried challenge progress among material players rarely used.
The release-one plan cut the site footprint by more than half and centered it on games, challenges, and account access. A responsive grid, labeled game tiles, and a six-part challenge card gave the catalog one repeatable system.
The homepage moved active challenges first, then new content and favorites. Game details and Challenge Central reused the same hierarchy instead of creating another way to browse.
I used five phases with iteration running through all of them. The sequence began with a full site audit because the team needed to see the product it had before deciding what the next version should keep.
Validate whether two decades of player behavior still pointed to the same core jobs, then define the smallest release that could serve those jobs across desktop, tablet, and mobile.
Pogo's audience had used the product for years, often on older devices and slower connections. Familiar patterns and explicit labels mattered more than novelty.
The team was small relative to the product footprint. I pushed for a phased launch so release one could be coherent instead of carrying every historical surface into a new shell.
This comparison is reconstructed from the project record. It explains why the team chose a catalog row pattern already familiar from streaming and shopping products.
| Legacy Pogo | Catalog rows | Release one | |
|---|---|---|---|
| Primary scan | Mixed modules | Horizontal rows | Challenges, then rows |
| Game identity | Image-led | Image and title | Large label and category |
| Challenge data | Scattered | Not native | Six fields on one card |
| Responsive behavior | Uneven | Known pattern | 4, 8, 12, and 16 columns |
| Learning cost | Existing but confusing | Familiar elsewhere | Familiar pattern, Pogo language |
“Too many levels and too many links, I don't even use or know what most of this is.”Player interview, navigation research
Across the research, the durable jobs were to find a challenge, play it, and return to a favorite game. That became the release-one filter.
Players could not reliably identify games from artwork alone. Larger tiles, visible titles, categories, progress, time, and reward moved the needed information into the scan path.
Five player segments were refreshed from the survey. The percentages shown are the ones preserved in the project file. The surviving record does not name the remaining fourteen percent, so this case does not assign them.
How might we make the next meaningful action clear without asking established players to relearn Pogo?
How might we carry fifty games and recurring challenges through one responsive system?
How might we cut the first release without cutting the reasons players return?
The original deck does not preserve formal alternative boards. These are the actual choices described in the project record, with the rejected path stated only where the record makes it clear.
The first audit mapped the current site. User flows then separated destinations that served the core loop from historical surfaces that could wait. The release sitemap grouped the retained product under games, challenges, and account access.
The accessible tree below is a simplified transcription of the release sitemap. It preserves the named destinations while removing repeated category branches that would make the same structure harder to read on a portfolio page.
These one-page PDFs are the surviving legacy product inventory. They show why a homepage redesign alone would not have fixed Pogo: games, profiles, friends, tournaments, badges, forums, and avatar tools each carried their own structure.
The product could be reduced because the player's recurring story was short. Challenge discovery and game discovery are different entry points into the same act of play.
Scan the active events and understand the task, time, progress, and reward.
Recognize a labeled title or move directly from a challenge into its game.
Launch the game without a detour through pages that do not support the task.
Return to the same challenge card and see what remains.
Complete the challenge, then repeat with a favorite or newly discovered game.
The original flow artifact names player goals but does not preserve every state. The diagrams below reconstruct branches and return paths from those goals and the released screens. They are marked as reconstruction, not original 2018 deliverables.
Get a returning player from the home page to a familiar game with one recoverable sign-in check.
ContinueSigned-in players move directly from favorites to play.
RecoverSigned-out players authenticate, then return to the same favorite row.
Carry the challenge, time limit, progress, and reward into the game and back again.
ContinueAn active challenge launches its game and returns with updated progress.
RecoverAn expired challenge returns the player to an equivalent active option.
Let category labels and related games support browsing without interrupting the path to play.
ContinueA good fit moves directly from detail to play.
RecoverRelated games return the player to a scoped catalog instead of a dead end.
This map separates three kinds of evidence: screens preserved in the archive, recreations built from those files, and destinations named in the sitemap with no surviving final drawing.
See all challenges→ Challenge Central
Open a game→ Game detail
Browse the catalog→ Game catalog
Open a game→ Game detail
View game details→ Game detail
Return home→ Home
Play the game→ Home
Browse related games→ Game catalog
See all challenges→ Challenge Central
Open the game→ Game detail
Inspect a challenge→ Challenge card
Launch the game→ Game detail
Choose another challenge→ Challenge Central
Return home→ Home
The original implementation repository does not survive. This reconstruction stays at the level the project evidence supports: player intent, responsive interface, shared content patterns, product destinations, and the legacy platform below them.
Reconstructed from the surviving project record. No implementation repository survives, so this diagram describes the delivery architecture evidenced by the released screens, grid rules, and content model. It does not claim a specific software stack.
These low-fidelity frames were rebuilt for this case from the recovered sitemap, player goals, responsive grid, and released screens. They document structure without pretending to be lost originals.
Challenges first, then new content and favorites.
One labeled grid for browsing by category.
One filter and one repeatable six-field card.
Play action, challenges, screenshots, then related games.
The same hierarchy compressed to four columns.
Named in the sitemap. No final drawing survives.
These are interactive recreations built from the archive, not screenshots of a current live account.
| Type | Challenge | Progress | Time left | Reward |
|---|---|---|---|---|
| DAILY | Win 3 hands without undo | ✓ 3 / 3 | 02:14:33 | +50 |
| DAILY | Score 1,200+ points in a single game | ✓ 1 / 1 | 02:14:33 | +50 |
| WEEKLY | Win 25 games this week | 14 / 25 | 4d 11h | +250 |
| MONTHLY | Reach 500,000 lifetime points | 243K / 500K | 21d | +1500 |
Time remaining, event type, game identity, task, progress, and reward were the data points players repeatedly said they needed. Keeping them together prevents the card from becoming a decorative tile.
Analytics and engineering set support at four columns on mobile, eight on portrait tablet, twelve on landscape tablet, and sixteen on desktop, with breakpoints at 360, 600, 960, 1280, and 1600 pixels.
The game page leads with play and active challenges. Everything else sits behind a blade so the default page serves the reason players opened it.
Category and Challenge Central use the same grid because both help a player find something to play. The content differs; the wayfinding job does not.
The archive preserves the 3,400-player survey method, the follow-up interview range, and two positive feedback captures after launch. It does not preserve a formal usability report or a quantified post-launch behavior change.
