Products

Building RealFevr

Initial fantasy-football concept → actual product system.

Context

The work started with an initial fantasy-football concept and developed into a product system spanning game rules, core UX, flows, wireframes, workflow requirements, testing and iteration.

My Role

Owned

  • Fantasy concept
  • Game/product rules
  • Core UX
  • Flows
  • Wireframes
  • Workflow requirements
  • Testing/iteration

Collaborated

  • Visual composition/UI
  • Engineering
  • Business development

Did not own

  • Final visual design
  • Software architecture

The Problem

Turn the concept into an explicit product system across game rules, UX, flows, wireframes, workflow requirements, testing and iteration.

Constraints

  • The work crossed product, design, engineering and business-development boundaries.
  • Final visual design and software architecture were not José's ownership.

System Map

Reconstructed explanatory map

  1. 01Concept
  2. 02Game / product rules
  3. 03Core UX + flows
  4. 04Wireframes + workflow requirements
  5. 05Collaborative implementation
  6. 06Testing + iteration

Key Decisions

  1. Make the rules explicit

    Turn the fantasy concept into concrete game and product rules.

  2. Shape the core product flow

    Translate the rules into core UX and product flows.

  3. Make requirements visible

    Use wireframes and workflow requirements to make the intended product behavior explicit.

  4. Keep iteration inside the product process

    Testing and iteration remained part of José's product ownership.

Inside the Work

  • Game/product rules
  • Core UX and flows
  • Wireframes
  • Workflow requirements
  • Testing/iteration

Before → Learning → After

Before
Initial fantasy-football concept.
Learning
Rules, UX, flows and workflow requirements had to become explicit enough to test and iterate.
After
An actual product system.

What Shipped

A fantasy-football product system shaped through game/product rules, core UX, flows, wireframes, workflow requirements, testing and iteration.

Outcomes

Fact
Initial fantasy-football concept → actual product system.
Interpretation
The case demonstrates product-systems work across rules, user experience and operating requirements without claiming sole visual-design or engineering ownership.

Provenance

  • Public facts are limited to the approved portfolio design spec and this case-study packet.
  • Ownership is separated between work José owned, work he collaborated on, and areas he did not own.
  • The system map is a reconstructed explanatory visual, not an original historical artifact.