Improving Team Efficiency by Creating a UC Style Guide


2016 - Current

Recognizing when I can Help

Being the only designer on my team at UCOP (University of California, Office of the President), I have a ton of day to day work on projects. But, in addition to my project work, I see a big part of the value I provide as using design tools and methods to help improve our work processes. In my first year on the job, I noticed several issues in our process that could be made more efficient by implementing a style guide and eventually developing it into a full design system:


  • Tough time and budget constraints caused features to not always be developed as designed.
  • I do not work on every project my team takes on, however some of those projects still involve UI design that should be consistent with the rest of our projects.
  • Documenting and specifying both interaction and visual design would take too much time and money from our budget


  • UI elements with standard interaction and visual design abstract away a layer of specification that needs to be done, making it much less likely elements are implemented incorrectly
  • Developers have consistent frameworks and components to work from if I am not included on the project
  • Less time is needed to create documentation around basic behavior and more time can be spent specifying the overall experience


When you are the only designer on your team, a lot of evangelization and education is key to establish good practices. I needed to get buy in by convincing both management and my teammates of the value of a design system. Luckily, my manager was quite receptive to the idea of building a design system when I explained its benefits to our business. We integrated building a UI style guide into my goals for the year as a first step in the process of getting to a design system. I also gave a presentation to my teammates to introduce them to the concept of a design system and what it could do to make our lives easier. When I made the argument for a design system from that perspective, my teammates were happy to endorse the initiative and also help where they can. I also have meetings with them as the design process goes on so I can get their feedback and keep the project transparent.


At this point in time, I have designed the components in the style guide and am using them in my design work on every new project I work on. I’m also working towards documenting the style guide and writing the HTML, CSS, and JavaScript necessary to make the components easily accessible for the developers on my team. The goal is to treat the developers on my team like my customers and make it as frictionless as possible for us to have well-designed products.

I built the style guide components in Sketch. While the elements are not yet implemented in code, at least in this form, I have a reusable tool to save time designing any new projects I work on.
I also produced a more polished version of the style guide elements to make them more approachable for others who are not as informed about design systems.
These are some sample slides from the presentation I gave my team to persuade them about why we should build a style guide, the benefits it would offer our particular team, and a roadmap to eventually develop a design system.

Built by KeVon Ticer (with CSS Grid) in the late 20-teens.