Case study - UTV – UTV Player

Technical product management for the responsive redevelopment of


From late 2013 to the start of 2014, I worked with UTV and Ostmodern on the redevelopment of UTV’s Player site – an online catch-up TV on demand service for Northern Ireland, and the sister site to ITV Player and STV Player.

Responsive screen shots of the UTV Player site

Homepage of the new UTV Player site

Above: screenshots of the re-launched UTV Player site. Thanks to for the top one.

Ostmodern were providing all UX, design, and strategic services, as well as the front-end build, and the creation of iOS and Android apps for mobile and tablet. UTV’s in-house .NET developers were responsible for the integration of the Ostmodern code into their CMS, scheduling ingest and editorial management.

My role was as Product Manager within the Ostmodern team, working as a liaison between the client, technical, design, UX teams and third parties, undertaking technical analysis and planning, defining the evolving scope of the product, and planning sprints. My work involved the following:

The project

The Player project involved the re-branding, and responsive redevelopment of the entire microsite, as well as the creation of new apps for iOS and Android phones and tablets. These were included due to mandatory requirements from UTV/ITV around DRM, but used much of the responsive website’s core code.

Features included:

Software and processes

Due to the fact that some of the Ostmodern team, myself included, never met UTV’s developers in person (one of them was based in Portugal for much of the project), communication was key. We had internal daily stand-ups, daily communication with the client, and weekly calls to demo the week’s progress. In addition there were regular calls with Brightcove, who were providing brand new SDKs for the apps, and which were going through a process of Alpha/Beta testing. These included additional support for DFP IMA functionality required by ITV/UTV.

The project was run using Google Drive, Trello, and Pivotal Tracker, with code held within a GitHub repo and documentation done through GitHub wikis. Jekyll was used to build out our fragments into full page templates to pass over to the .NET developers (they had requested full pages), and we used Sass/Compass/Bourbon to enhance our front-end productivity, along with Jenkins for CI and git-flow as a workflow. The UX team had previously created documentation in Axure, broken down into responsive components, which were also demonstrated with designed mock-ups.

The apps were created using the core responsive codebase, with conditional elements loaded depending on the platform, including the relevant Brightcove SDKs. They were wrapped using Cordova.


This project involved a lot of new things for me. It was the first proper video on demand project I’d worked on, and as such there were a lot of new acronyms to learn! I had to get to grips with the workings of elements like ad delivery, including delving into the world of VAST 2 specifications, the Brightcove API and player capabilities (on various platforms), ad server requests, and more.

I’d never worked with Jekyll previously, and whilst at the end we were really pushing its intended use, it was a great introduction to just how creative you can get with static site generators, components and templates.

I wanted to try to encourage the Ostmodern team to use wiki functionality, and to break documentation down into related, small chunks. They weren’t currently using any other software, so rather than introduce something new, we used a GitHub wiki to sit alongside our code. We used this as a project hub, linking out to documentation that had been created before I’d started on the project, but also adding new, contextual information, such as release notes, integration specifications for sharing with UTV’s developers (for JSON exchange with the back-end etc), and for other annotations that needed recording.

On my very first day I was challenged with the fact that the plan was to have a doorslam mobile experience, and to point the users in the direction of apps. This is something that I usually strongly disagree with – I think that it’s a poor experience to be immediately presented with, it ‘breaks’ the web and sharing, and I’m not a fan of forcing app downloads on anyone. However, this was something that I had come to terms with due to the nature of certain DRM and advertising requirements, and the fact that if we’d have ‘opened up’ the full responsive site to devices, Apple’s App Store would likely not have approved the iOS app because of ‘duplication of content’. Coming from a non-VOD background, I still think the broadcast industry has a long way to go to update their processes to help this progress, but I also understand that open web technologies have certain limitations for this industry too. It was a good experience for me to have, and one which made me see another perspective.

Contact me

If you'd like any more information about what I did on this project, or would like to talk to me about doing something similar in the future, please get in touch.