Responsive image


Comcast, like other cable providers, is experiencing a mass exodus of existing customers due to backlash over their high cable bills. Comcast's answer is RDK, an open-source Resource Development Kit. Along with four other major TV providers, they are building and contributing to this resource so they can address customer concerns by increasing the overall value they provide with their packaged services.

Comcast is building a software development kit named Firebolt. The purpose is to allow developers who would otherwise independently develop their apps for competing over-the-top and web platforms to have a home in Xfinity's eco-system.

I was brought in to work with the RDK group and Comcast's cable team to lead the design and development teams in building a developer portal and four products: Firebolt Native, Firebolt Web, Spark, and Lightning++


Part a —
business goals


After initial introductions, the design team developers (in-house & offshore) and the product team met with the stakeholders for a kickoff meeting. The floor was open to all to ask questions.

My questions were: What problem are we trying to solve? For whom? Why? What does success look like?

As a group, we defined the key results and objectives for the portal. From that initial conversation, we agreed on the following:

  1. Establish
  2. Create a Brandmark
    Create a website presence with documentation and discussion boards
  3. Onboarding
  4. Attract independent developers and connect with the broader OTT community to bring in at least 100 new video, audio, or interactive applications.
  5. E-Learning
  6. Create document and video tutorials
Part b —
first challenge

I asked each one of the team members for their input. Initially, we agreed to meet for a creative session (affinity map).

After scheduling conflicts and a rapid timeline started to outpace our research window, everyone wrote in their suggestions. This is not ideal because we lost the ability to truly collaborate and iterate on each other's ideas.

targeted users who actively use portals

The question I posed was: How do we build a practical and easy to use documentation portal? Answers included:

  1. Mood Board
  2. Competitive analysis
  3. Reviewing Case Studies
  4. Research activities

Combining a mood board and a competitive analysis gives us some insight into how competing and noncompeting platforms deliver their content. Our goal was to establish a list of what we thought was the best based on the below criteria.

  1. Site Architecture
  2. Interaction experience
  3. Depth of knowledge
  4. Excellent onboarding experience

Next, we listed out our assumptions regarding what our users would want in their experience on our portal.

  1. Inline demonstrations
  2. Video walkthroughs
  3. Step-by-step instructions with highlights giving emphasis to specific parts of the document
Part c —
user goals


Next, we targeted users who actively use the portals on our list. Our users consisted of in-person and online interactions. Some of our questions:

  1. Why do you use this portal over another?
  2. Who recommended the use of this portal?
  3. Can you share a positive experience you have had while using this portal?
  4. Can you share a negative experience you have had while using this portal?

We analyzed data collected from 15 developers over a period of two weeks and discovered that video walkthroughs were the highest validated assumption we made. Inline demonstrations were the second highest. During that collection, we also heard that version control with updated documents was often a pain point they experienced on other platforms. From this, we made 10 empathy maps that explored the 4 feature requests in journey maps.

Empathy Maps
User Journey
Part d —
the Process


The process is applying what we learned from the research phase — starting with iterating lo-fi to hi-fi wireframes — testing early with Adobe XD navigational user testing — analyzing what we learned from our assumptions that either proved true or false then applying that knowledge later to visual designs.


Wireframe: Stage 1

Taking what we learned from requirement gathering from the stakeholders and developers we met and created our first set of wireframes. We both contributed, but Sheetal leads the development of the early stage.

Wireframe: Stage 2

We presented stage 1, and based on the feedback Sheetal, and I created our versions of stage two. Screen 2 (Myself) and 3 (Sheetal) feature some of the same basic ideas just presented differently. One of the challenges of wireframing is to keep each design as high level as we can without trying to flesh out design ideas. After discussion with our stakeholders, we implemented the second wireframe because they wanted to focus less on Firebolt Native and more on Spark.


& Visual

Part a —

Initial Design

Purposed Design

Purposed Design

In final rounds of consideration

Spec hardware certification branding mark

Part b —
Style Guide
Primary Background

RGB(255, 255, 255)

Primary Action

RGB(0, 169, 157)

Secondary Background

RGB(26, 26, 26)

Action Background, Primary Text

RGB(255, 127, 80))

Part c —
Visual Design
Visual Design: Home
Visual Design: Build Apps
Visual Design: Journal
Visual Design: Downloads