Using Atomic Design Principles



The Problem

HBO's two streaming apps are available on roughly a dozen and a half platforms across desktop, mobile, and connected TV devices. Adding a new feature typically requires creating designs, redlines, and bespoke code for the dozens of different experience variations, as well as extensive cross-discipline interaction during production. Is there a more efficient approach, and can that approach ultimately be more consistent and reliable?

My Role

In 2016 I did initial investigation and outlined the possibilities with one other UX designer. More recently I worked with a team of four UX designers (two with a visual design focus) to flesh out how Atomic Design principles could apply and to begin socializing the concepts across the organization. Specifically, I took part in much of the brainstorming and then created graphics to express the concepts as clearly as possible.


About eight weeks, while each of us was simultaneously working on other projects as well.


Research & Discovery

The first step was to familiarize ourselves with Brad Frost's work on the subject and to theorize how his principles might relate to our current design and engineering pipeline. In short: they wouldn't, at least not without significant pain. But things changed this year when we switched from internal tools and started using the more robust, friendly, and universally understood React for implementing UI code. We were then able to more easily see how designing a system of components could work within our code stack.

Credit: Brad Frost

Credit: Brad Frost

We quickly became aware of the need to socialize this potentially large change properly. First off, we would likely be proposing a new style of software development and would want engineers to be part of the process from day one. Also, another department within HBO had just completed a move to a "lite" version of atomic design and were making it clear the jury was still out on whether it was worth it. We had several discussions with people involved and reviewed their project, and came to the conclusion they were at a point where they'd taken their "3-steps back" and hadn't yet taken much of a step forward. We believed their approach still had potential and that gains would be more obvious in the future. Also, their lite approach wasn't coupled with a comprehensive visual design language so in the end their different Lego pieces snapped together fairly well but did not create a totally pleasing whole. 

The actual result (L) differs from the original vision (R).

The actual result (L) differs from the original vision (R).


Project Definition

We proposed creating a presentation and a mini road show for key stakeholders, leadership groups, and other appropriate audiences as an initial deliverable for this epic project. The presentation would be tailored to each specific audience and would start the conversation about how we develop our products in the future. The goal would be to gather more feedback, uncover any unforeseen obstacles and concerns, and to ensure all participants are heard and feel heard.

Design & Build

We first figured out which core concepts of Atomic Design were applicable to our product development life cycle and made the theoretical more practical to our application (e.g. atoms and molecules are essential, organisms feels forced, templates and pages don't apply). I will only speak in general terms about our actual proposal but it's basically a conceptual switch to avoid inheritance ambiguity and clutter in the UI code, towards a system of common code and design libraries whose elements are assembled into dynamic compositions.

We then outlined our story. The narrative was simply: define "atomic", define each component and relate them to those we currently use, explain what atomic design could allow us to do, and then explain how it would be implemented across Design and Engineering. The aim was to remain as factual as possible without hard-selling and promising miracle solutions. We believed if we were clear enough people could see for themselves how practical the solution is and also visualize potential improvements in areas important to them. This also confirmed we were taking a collaborative approach.


Deliver & Test

An initial round of talks has been scheduled and the first ones have been completed. Feedback has been extremely positive, and while questions are being raised there is a definite sense that people are on board and tentatively excited about a future implementation. Most importantly, dialog has started and discussions have been promisingly constructive. 

Next Steps

More ambitious slides are being designed and included in some variants of the deck. These are meant to tackle more knotty problems and concepts as well as address some of the common feedback we gathered. Additionally, we expect to start working with a Product Manager to gather initial business requirements and to pencil out a rough roadmap with scope and priorities. An audit of current styles and components will identify a starting point for prototyping and proof of concept.