Twitch Core UI Design System
Twitch’s design system includes a co-ordinated Figma component library for Designers and a production code component library for Engineers. These working in conjunction insure a smooth, consistent, accessible and scalable user experience on Twitch.tc.
I managed the Core UI Design team that maintained the Figma library.
Platforms: Figma, Web, Android, iOS
The implementation of Twitch’s Core UI Design System began shortly before I joined the company in 2017 as a Senior UX Designer. During my first four years, I was a consumer of the design system, watching it grow from the ground up and become more complete and flexible. Over time it matured to have a tight understanding of accessibility and evolved to adopt Figma component variants.
In 2021 I jumped at the opportunity to step into the management role on the Core UI Design team, taking on the responsibility of people managing three Designers (four at the time of my departure) and one UX Writer while also collaborating with the broader UX org to define and prioritize strategy at the start of each year.
Core UI arm of the UX Org Chart
Why Management?
When I became a UX Designer in 2008, I was happy being an individual contributor for the rest of my career. Too many managers became what they were because management was the “next rung on the ladder” with a suspicious lack of (or the desire for) anypeople management skills. I loved design, why would I want to become something else?
Over a decade into my career, I had seen a lot. Some good managers, more bad managers and countless struggling mentees. Mentoring had become one of the most rewarding avenues of my career, but my lack of ability to situationally change things around a mentee, only through them, had become immensely frustrating. I was finally starting to realize that maybe I did want to become a manager.
I became a UX Designer because I always want to help. I became a UX Manager because I wanted to help those who helped. I approach management the same way I do UX. What are the person’s motivations and goals? How did they get here and where do they want to go next? Stop and understand them as people before you jump into problem solving.
How Management?
My responsibilities as Design Manager of the Core UI team included the following:
Deep understanding of the Core UI Design System and the Figma components that represented it, how they were constructed and integrated into product designs.
Day to day remote people management of 4 UX Designers and 1 UX Writer, including removal of blockers, handling escalations and long term career planning
Prioritization and creation of yearly roadmaps in collaboration with the Core UI Engineering team as well as aligning to roadmaps across the Product teams.
Year-end people performance calibrations - Promoted two team members during my 2.5 years as a manager
Final Core UI sign off in Product Design Reviews
Running a weekly Workshop - Office hours to provide guidance on Core UI usage, intake proposed changes/updates to the system as well as design process and accessibility recommendations. Average total sign ups 1-2 hours a week.
Hiring the best - Made 3 different UX Designer hires for the Core UI team as well as contributing time to dozens of other Design Org interview loops
Example Process: Roadmapping
Before I joined the Core UI Team, each year they would create a roadmap at the start of the year. It would be a beautiful, visual piece, with an inspiring Vision Statement and broad promises. They would present it to the design org and then tuck it away until next year.
I am not particularly fond of symbols without substance. I tire of vision statements as morale exercises. I want my team and the org that I support to be excited because of the actionable things we are doing.
Each Product Design Team discussed key concerns around Core UI with me for an hour, with thoughts recorded in Figjam
Despite having been a user of Core UI for four years at that point, I knew I was still coming into the team with very little knowledge on the interworking of how the team operated and how the organization as a whole collaborated with the team. With that in mind I kicked off the Core UI Listening Tour, where I borrowed an hour from each of the Product Design teams to listen and understand how they communicated with Core UI. What did they and didn’t they use in the Library? What difficulties did they have during engineering handoff? What was their main Core UI resource to learn more about the system?
A snapshot of the Core UI Roadmap Brainstorm
This, along with similar interviews done by the engineering team and the roadmaps of the product teams became the seeds for brainstorming what would be next for Core UI. Over three mornings, the engineers and designers of Core UI gathered remotely in Figjam and determined a list of tasks that kept a balance between what we were the most excited to accomplish, what the product teams needed most from us, and what was most feasible to accomplish over the next year.
The engineering manager and I then synthesized the Figjam from the perspective of our respective areas, creating an official Core UI Roadmap in JIRA, with detailed timelines, owners and descriptions that we ensured to revisit every quarter to make sure as a team that we felt on track, that our planned tasks still made sense and adjusting the roadmap as needed while celebrating our accomplishments.
Teammates were asked to submit “Achievements” for others on the team via Google Form, to highlight
One thing I continued to remind my team every quarter was that our roadmap was a living document. Things change. Priorities shift. That is okay. If we didn’t get everything done in a quarter that we thought we would, what DID we get done? What happened in place of the things that didn’t? How do we account for these hurdles in the future? What expectations did the product teams have for us and were they managed correctly?
A roadmap isn’t a checklist with a binary pass or fail. It is exists to make plans, set expectations, and continually act as a point of conversation with partners. As long as we knew what we were doing, why we were doing it and communicated that to the appropriate parties, we succeeded in our quarter.
This is a great example of my management philosophy in general. Understand the situation, understand it may change minute to minute, and be flexible when those changes come through. There is no one perfect way to manage every employee. Hands on, hands off, documented checklist career planning, or continually flowing career conversations, to be a good manager, you have to be a good manager for that individual and their needs.