DC UNIVERSE
UI/UX Product Designer & Programmer, Warner Bros Digital Labs
June 2016 – November 2018
OVERVIEW
After Dramafever’s acquisition by Warner Bros, WBDL sought to cement its position in the WB Family with a project demonstrating its ability to handle large scale projects. DC Universe was pitched to be the “prime digital streaming experience for fans” that DC was looking for, the key that would spearhead the company’s dive into the digital market. With plans to juggle both comics and videos while engaging users on a social and interactive level, this would be a project that would demand our full scope of experience, insight, and resources in order to be properly mapped out and executed.
INITIAL PLANNING
When we started, clarity on who our userbase would be and what content we would be receiving from DC was sparse. Because of how vast DC’s library was and understandable anxiety from stakeholders over the nature of this ambitious app, we had many holes to fill.
Taking advantage of WB’s own research labs, we interviewed fans and digital comic readers to isolate key user preferences and behaviors. We referenced our own familiarity with fandom and media-driven communities, examining habits we could observe from Dramafever as well as other platforms/indsutries such as book retail, fashion, and e-commerce.
From there, we created various user personas to better visualize our potential audience and mapped out appropriate user flows. Though there were conflicts as to who exactly we should cater to (casual fan vs super fan), as well as a struggle due to various problems to secure all the content we needed from DC for a more robust experience, we finally created a jumping off point for the many views and features we would need to make up the app.
ESTABLISHING STRUCTURE – HUBS & “SPOTLIGHT”
After much discussion about site structure, we brainstormed many ways we could approach this new app’s site structure via rapid paper sketches (Crazy-8s) and several low to mid fidelity layouts. Our earliest structure was built off of DC Comics’s original hierarchy, where content was divided between hubs of different content types. We had to establish how comics and videos related to each other in a greater content hiearchy, as they are accessed by users in differing ways. Comics are more commonly accessed through an individual book level than a series level, while TV episodes are more likely to be accessed from a series level over an individual episode level.
Later, however, we ran into the a problem - how to feature our content proudly without revealing how little we had in our actual library (especially at the start, when we would not be receiving that many titles). We did not want to disappoint users who expected us to be Netflix when in reality, we were much closer to FX and Amazon Prime in terms of content that would be available without requiring more from the user past registration and subscription. Because of our lack of content, our Home view became incredibly redundant with our Hubs and we did not have enough to create an impression of abundancy.
As a solution, our team proposed to adopt a “Spotlight” model for our native app experience, one that focused more on individual features and dynamically driving relevant content to useres instead of our original monotonous rows-of-content approach. Because native apps have a more streamlined flow compared to web, where you can access any part of a site via a direct link or URL input, we would have more control over guiding users to the content they would actually want to see.
To achieve this, registered users ideally would be able to build their own feed depending on factors like topics they followed or content items they liked and receive curated and dynamic content suggestions immedietly after opening the app. Alternatively, they could go into a less prioritized Browse where they could examine what they would like to engage in more content type specific areas. To support this, our ideal navigation would be along the lines of Spotlight, Browse, Library, and Profile, based on the idea of content that is “For You”, “By You”, and “Is You”. All of this would tie back into fueling the suggestions pulled into the dynamic feed in Spotlight, and would simplify where a user could go instead of needing to list out every hub in a bottom navigation.
"Spotlight" Phone
"Spotlight" Tablet
"Browse" Flow
QC ASSET TOOL (WBDL INTERNAL)
During a lull in the design phase of DC Universe, I was asked to develop an internal VueJS based tool to aid in the creation of assets.
This tool was to be a solve for the sheer amount of [comic] assets we were missing and the lack of manpower needed to manually create all of them in all the resolutions and sizes required for each item on the service. This included the creation of mastheads, key art, thumbnail art, and other various contexts.
The goal of this tool was not only to be functional, but also be easy to operate by the person looking to bulk create assets, with the eventual goal to take this foundation and make this all automated.
PLANNING THE QC TOOL
This tool was to be hooked up to our internal comics database, an application containing a thorough amount of information and images already associated with each book in the service. There were a number of asks of varying priority that were provided at the time:
- A user should also be able to upload images locally to crop
- A user should also be able to pull down images from a book to crop by inputting one or multiple comic book ID numbers (also known as T-Numbers)
- A user should be able to adjust the crop area, image ratio, and position
- A user should be able to export the crop, either to an external area or to the associated book within the database
- A user should be able to do all this in bulk
Not all the asks could be met at the time, as the QC Database as a whole was still being ironed out when I started contributing. Regardless, it was important to create a smooth and usable experience with the resources that were available. With this in mind, I mocked up my ideal flow and, after consulting both product and engineering teams about priorities around this tool, determined what was doable from there.
BUILDING THE QC TOOL
The resulting program addressed what was evaluated to be the main priorities of the tool - cropping any form of image data that it receives. Once the source is determined – local upload, T-Number search, or otherwise – the tool automatically creates a live preview crop of the image based on a set of dimensions a user inputs. The user can then adjust the generated crop further if needed, either by typing in new X/Y coordinates and dimensions, by dragging the bounding box around the canvas area, or using keyboard shortcuts and inputs associated with various actions the editing view can do (locking bounding box ratio, zooming in/out, resetting the origin point, etc.). The user can then export the resulting asset to be saved locally or to an associated book within the database using a T-Number.
To build all this, I worked closely with one of our senior tech leads and learned how to navigate our existing code environment using Vue.JS and Gulp. Over the course of a few months, I made many code contributions to the QC Tool repo, hooking up file uploading/exporting and a growing library of different image editing tools to the designated canvas tag I set up for this feature. Though I was moved back to doing product design work after all the base features were done, I continued to work alongside our engineering team to evolve the QC Tool further into an authoring tool, which is now being used to isolate comic book panel data for our comic book reader.
IMPLEMENTING ABSTRACT
As time went on and this project became increasingly more demanding in terms of asks, deliverables, and conflicting interests from stakeholders, we ended up with many versions of views and components which snowballed into a swamp of inconsistency and disorganization.
In response, I proposed to source control our designs based on my experience working on the development team. Though it would take a lot of time and work to get our files in order, ideally it would unite our team and help us work better in the long run by keeping us on the same page, as well as provide accountability and references for past, current, and future designs. With the cooperation of one other coworker to help me convert all of our work so far into components for a design system, we implemented the use of Abstract within our team, applying this work to all of our designs in order to standardize them and be consistent.
To assist this effort further, I coordinated and documented the source control process and how it applied specifically to design files, one that was mapped very similarly with my time spent with Git. Team members would not only be able to see what their fellow cohorts would be doing, but they would also be able to create their own branches that they could design freely in without fear of “damaging” master designs until it was time for review. This created a formal space for experimentation and critique, allowing room for designers to provide input on in-progress work before those decisions became official. With Abstract’s built in inspect and export tools, it also equipped us to better guide developers and other stakeholders through our designs. By allowing designers to be accountable and take ownership over their features, and with visual progress associated with our work, this helped us to identify who was the best person to speak about certain views and gave us all needed confidence in our work. Abstract helped smooth out our volatile process tremendously and kept us together through turbulent design cycles up until launch.
