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++
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:
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:
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.
Next, we listed out our assumptions regarding what our users would want in their experience on our portal.
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:
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.
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.
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.
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.
In our first prototype we included icons for Search and Login along with grouping our main links to the left.
After testing the navigation with two participants:
In final rounds of consideration
Spec hardware certification branding mark
RGB(255, 255, 255)
RGB(0, 169, 157)
RGB(26, 26, 26)
RGB(255, 127, 80))