Looking to Horizon: Why We Built A Design System
Horizon Design System, Part 1
When I joined Twitter over two years ago, I discovered a group of devoted designers and engineers working on a Hack Week passion project called Feather. Feather became a web component library focused on serving Twitter’s internal and enterprise products.
Feather’s mission was to provide consistent and thoughtful experiences at scale. As the number of Feather’s components, patterns, and internal customers grew, this once-Hackathon passion project evolved into a well-supported team. Our group was committed to creating a quality component library that supported other teams by improving work performance and efficiency.
Meanwhile, the resources we were using to build the Twitter app were not as well defined. Despite everyone’s best intentions to create a cohesive experience with Sketch UI templates and office hours — informal sessions where feature designers confer with the Platform design team about best practices — the design team’s size was too large to maintain alignment and consistency.
To find out more about the lack of cohesion, a user researcher on our team, Wilson Chan, conducted numerous interviews amongst the design team looking for where we could make improvements. We will be sharing what we learned in a post here soon.
Based on the research collected, we assembled a team to create Horizon, our design system for all our Twitter consumer products. For Horizon to be successful, we knew it needed to be treated with the same effort as a product, with clearly identified goals, a roadmap, and — of course — swag.
Goal 1: Bring cohesion across platforms
One reliable way of introducing cohesion across platforms was through audits. Slight visual differences across platforms were easy to find, but with different teams dedicated to various initiatives, inconsistencies across UI elements and interactions were far too common.
The audit exercises helped us create an inventory of updates for us to make as resources become available or teams touch on related areas of the apps.
The best use of our audit findings was to take conflicting patterns and document the appropriate uses to guide towards unification. With this documentation, we finally had a resource to help prevent the same issues from arising again.
Goal 2: Provide trusted resources
Creating consistent documentation guidelines and distributing always-up-to-date .sketch assets as resources helped everyone begin to communicate verbally and visually in a unified way.
We wanted to make sure our team’s language for different elements and interpretations of appropriate usage wasn’t wildly different. Through naming exercises, interviews, and working sessions, we collaborated with designers and engineers across the team to craft an extensive set of usage guidelines.
Without this centralized documentation, our team couldn’t scale properly. Knowledge was confined to specific people, resulting in those individuals having to meet with others regularly to discuss the same topic over and over again. Our documentation created a single place for gathering the knowledge that team members gained while working on a product, allowing for a self-service model.
From the research conducted within the design team, a substantial amount of time was being spent recreating views in the product in Sketch. By providing a set of synced resources on each designer’s computer that contain up-to-date elements and screens, we are able to increase productivity and efficiency; we eliminated that tedious, recurring task (more to come about this in an upcoming post).
Goal 3: Look towards the future without recreating the wheel
Knowing how and when to evolve an existing component or interaction pattern can often be unclear. We are solving this by identifying a sequential exploration phase within our product design process: Utilization, Adaptation, then Creation.
Utilization of Horizon components allows us to leverage defined solutions for common design problems and needs. With our design system, we built strong foundations of existing UI elements and interaction patterns that we can use, and reuse, with little overhead and the least amount of friction. Using these elements supports creating a consistent experience across platforms requiring people to have to do less cognitive work to learn new interactions.
Adaptation of an element is an opportunity to refine and improve all current use cases. When an existing presentation or behavior doesn’t fully solve a problem, we can make adjustments to an element to accommodate the needs and have those changes propagate throughout the app.
Creation of new UI elements or interaction patterns is sometimes needed when the parts of our design system don’t solve a specific problem for people using Twitter. We try, whenever possible, to adhere to utilization and adaptation of our system, but recognize that in order to provide a great experience, new artifacts are sometimes needed to solve a problem. By going through this cycle, we can ensure that creation of a new element is beneficial to our system and the people using Twitter.
Conclusion
By identifying these goals early in our process, we are setting our sights on how we want to work and what we want to build.
We’re learning a lot throughout this process, through quarterly team feedback surveys and presentations, while evangelizing our mission throughout the organization.
This is the first blog post in the “Horizon Design System” series. We look forward to sharing more about our process and progress in future posts. In the meantime, if you have questions, leave us a reply. Or send us a Tweet!
Studio images courtesy of Josh Wilburne. Header illustration courtesy of Michie Cao.
