top of page
1
COMPILING INDUSTRY KNOWLEDGE
The 3 main tasks for this step include:
Researching OTT industry:
-
Researching why Echostar should invest in a skinnable OTT (Over the Top) framework and why cable's "TV Everywhere" (STB's online frontend) is not the future streaming service model.
-
Over the past 5 years, with the exception of Boomers, all generations have either unsubscribed, never subscribed or scaled back packages within their tradition TV subscriptions while opting for OTT entertainment services instead.
Researching OTT competitors:
-
Researching competitor OTT services like Netflix, Hulu, YouTube, etc. Identifying both feature architectures and UX/UI standards shared by all platforms across all services.
-
Since these titans have already done their internal research and consumer testing, the final public facing services already determined OTT industry standards.
Analyzing the DISH STB frontend project:
-
While researching the above tasks, reviewing the entire DISH STB online streaming site to help both product owners and developers who would eventually create Echostar's OTT service by identifying pitfalls to avoid when producing our own service.
2
CLARIFYING PROJECT NECESSITIES
The two main objectives for Echostar Live frontend:
Create a modular architecture:
-
Gives the sales team a foundation for selling optional modules to potential clients. Clients can either add or subtract modules base on their consumer analytics at anytime with a flip of a switch.
-
Up front modules include: ondemand, cloud recording, rentals, purchases, sports center, news center, etc. Future up-sell modules would eventually be added, including cloud storage, at anytime without issue due to this new modular system.
-
Along with the modular architecture, skinning features include not only the ability to change themes, but options like carousel instead of bucket functionality within the modular control panel.
Consistency:
-
Due to inconsistencies within the DISH STB streaming app, my concern to force the importance of consistency which is always high on my requirement list. Consistency is key! Using common components across all platforms and using the same code base for all instances; called globally. Buttons, modals, etc. have the exact same functionality and look. A record button on one screen should look and act the exact same way on another.
-
Consistency allows users to know what action will happen EVERYTIME without fail and without confusion. It allows developers to code once and only once. Lastly, it simplifies QA's role in testing the apps accurately. It's a win for everyone.
3
CREATING PROCESS FLOWS
The majority of standard features on the streaming app that a user can interact with are already known from previous work on the DISH app/site, as well as, information gathered from step 1.
The first undertaking at this stage involves mapping the user decision making process from available actions into the most streamlined and economical flows as possible while still retaining industry standards.
For example, if the user's intent is to play via the search feature, what asset types do we offer the user for playback:
​
-
Open app/site
-
Locate search feature on UI
-
Enter a direct search entry
-
Select title from auto-suggest entry
After redirection, does the selected title have an available ondemand asset, recorded DVR asset or is current airing?
​
-
NO: Nothing playable; need to offer alternative action like a future record option when airing becomes available (e.g. currently off season title). END ACTION
-
YES:
​
Is ondemand available?
​
-
YES: Ondemand is presented to user over all other options as this is the highest quality playback a user can receive. END ACTION
-
NO:
​
Is a recording available?
​
-
YES: Recorded asset is presented to user for playback.
-
NO:
​
Is this title currently airing?
​
-
YES: Live airing is presented to user for playback.
-
NO: See 1st decision marker - nothing playable; need to offer alternative action. END ACTION
4
WIREFRAMING UX/UI COMPONENTS
Frameworking begins with all process flows from step 3 and the new feature architectures outlined in step 2. This step not only determines the finer functionality details of UX/UI components of the new OTT service, but possible layouts of the new site architecture, including a browsing area, a "my" space section and a dedicated spot for watching live linear TV with guide.
Examples of some component wireframeing:
​​
-
Play functionalities when redirected from specific features across the platform
-
Direct and auto-suggestion search functionalities
-
Browsing features
-
Recording and recording options wireframing
-
Payment processes
-
Persistent but temporary watchlist repository along with standard watchlist functionality
-
Thumbnail and overlay options wireframing
By reviewing past decisions, tweaking components and architectures as necessary and combining both with increasingly improved layouts, this modular OTT service really starts to take shape in this step, enough to proceed to step 5.
5
FRAMEWORK DEMOS & FEEDBACK
Demoing to direct managers that have a vested interest in the project by walking through overarching frameworks and the reasoning behind all decisions.
Including:
-
Up-sellable modules
-
General navigation
-
Partitioning of information to be more customer friendly
-
User friendly UX/UI modals and components
-
New playback features
-
Resolving of non-actionable dead-end screens
-
And much more
Managers proceed to give signoff for creating a rapid prototype along with useful and constructive feedback associated with higher level architecture. From this success, the process goes forwards to the next step.
6
CREATING RAPID PROTOTYPES
Taking the previous frameworks created in step 5, creating rapid prototypes begins in webflow for the executive demo. The reasoning behind choosing this platform for my prototyping needs stems from other software limitations on creating a much more dynamic demo. I need to quickly "show" the proposed OTT service framework without excessive verbal "tell". Presenting time is quite limited and I need to present a great deal of information in the shortest amount of time. While I have worked with other prototyping software including Sketch and Figma, webflow gave me the ability to quickly add custom CSS, animations, custom Javascript code and graphics/data population while giving the extra "wow" factor to ensure a success.
Further refinement of the frameworks and layouts also occur at this step. Since the first potential customer was a "sports" OTT service provider, heavy prototyping of the "sports hub" module took precedence over standard common components.
Since work in steps 1 thru 4 finished, the prototype build out took approximately two weeks from start to finish, ready for the executives.
7
PRESENTING FINAL PRODUCT
Finally, onto presenting the working prototype to executives. This final step within the prototyping process flow reflects a solid two months of both tireless effort and great satisfaction. Explaining the higher level ideas and associated requirements, simulating user experience and pumping up the execs for potential up-sell capabilities gave me a great sense of achievement. The word "GO" from top Echostar executives to produce "Echostar Live" as a viable React/React Native website, mobile and 10ft app meant the prototype itself was a huge success.
bottom of page