Decanter FAQs

Decanter is for developers and designers alike, both inside of Stanford or with external partners creating digital products.

Decanter Version 7 (Tailwind CSS): CSS Trick's Greg Sullivan has a great article about the ins and outs of adding a Tailwind CSS design system to a WordPress theme. Read it here.

Our core Decanter team is comprised of developers and designers, namely from within the Web Services team, who own the governance process for code and design. Most of the decision making is segregated to this group of experts who are also the core stewards of the code and design. Currently this works well and easily because the core team makeup a majority faction of the Decanter users. In the future, as more groups and projects begin using Decanter without Web Services involved, this will likely become more complex.

The web today has evolved to a point where generalized “components” are conventional and ubiquitous. Like the evolution of a book or newspaper, there aren’t many “new” graphic patterns to display content that influence this general library. With that in mind, our goal with Decanter is to keep the library as trim and foundational to this generalized set of patterns as possible. We build the lego blocks, but the users of Decanter assemble, and style those building blocks however they see fit. As a designer, I’ll want to make sure there is a button in a few sizes, and possibly provide solid and outlined button variants additionally, perhaps leading and trailing icons, but there isn’t much more we can (or want) to add to this foundational component. It’ll employ Stanford’s primary identity colors and typography, and “feel” like Stanford. There may be a few different types of hero banners to allow for consumers of Decanter to employ these components without building from scratch, but again, they tend to be basic in their implementation, and serve a generalized purpose. This works well for platforms like our Stanford Basic product on Drupal where the free service can employ Decanter out of the box, and partners who want something tailored to their visual aesthetic can style on top of this base layer.

• Accelerate the design/development process for teams in need of a systemic solution to their frontends and design
• Brand compliant
• Accessibility standards met for AA compliance

The original V1 of Decanter was designed and implemented by the then lead designer, John Holloman, and lead frontend developer, Kevin Garcia at the time when they were working on our University Communications team rebuilding the stanford.edu website in 2017. Following this project, our Web Services architect, Shea McKinney began to discuss the potential future for Decanter with John and Kevin, and the beginnings of V2 was born.

From there, the case was made to the leadership of both teams to continue evolving and maintaining both the codebase and the design system naming it’s mutually beneficial use cases for our own projects, and for projects across the University. Particularly, meeting accessibility standards (and reducing duplicative effort here for dozens of teams at Stanford) continues to be a primary driver in creating and maintaining Decanter. The Wordpress and Drupal platforms servicing thousands of websites across the University both began employing Decanter in 2019 (and still do today). From 2018-2019 designers and developers met bi-weekly to plan, enhance, and maintain code and design and while we also held bi-annual Decanter sprints with a team of about three designers, and five developers taking us to V4. Since then, devoted Decanter sprints haven’t been as necessary, as large “project-sponsors” have become the source of advancing design and development (not unlike the birth of the project).

We continue to meet regularly, with an open Decanter forum to discuss enhancements, learn what our community needs, and plan for upcoming work. We have an open Decanter Slack channel. And community members across Stanford are invited to participate in any way they’re supported to do so. But as the source of enhancements have shifted to project-based roadmaps, we’re currently in a period where Decanter is influenced largely by our project sponsors. Design and code decisions are led namely by the Web Services architects and implementors who are the primary users of Decanter V7 to keep the project evolving and reduce stagnation.

When the DS project started, how did you decide what was the original scope and what did you decide to tackle first? The initial scope was stanford.edu as the original source came from the last redesign of that property. We decided that since the Stanford Sites platform was “related” that it would be great if we could collaborate with the University Communications team (at the time) to ensure consistency as well as improve efficiency.

Original inspiration?

More recent inspiration includes the Rivet Design System and the Folwell Design System

Our team crosses functional units at the University, including Web Services, University Communications, University IT Communications, and the Office of Digital Accessibility. We are made up of front-end developers, accessibility specialists, and UX and visual designers.

We do not have consistent annual staffing for this project. It is cobbled together through a combination of project-specific work and donated time from staff members who believe in making this resource available.

We would love to do a better job of this! It would be great to be able to show the time and money saved by sharing design resources.

How do you communicate changes to the design system/get users on board with these changes? We communicate primarily through individual projects or through the project website (https://decanter.stanford.edu) and a Slack channel. Many of the changes come directly from University Communications as part of the brand guidelines, so those changes are communicated via the brand identity website (https://identity.stanford.edu)

The documentation lives on this website and on the Decanter repo on Github.

The code is completely public. The Figma assets do require some manual hand-off.

We have several team members who pitch in periodically to keep it up to date.

We follow this criteria for determining what should go in the system and what would be better to stay in individual projects/products:

Components should be:

• Reusable, content-agnostic
• Have a clear use case
• Expressly address accessibility and usability
• Considers evolving web trends

We hope that it is used for all administrative, departmental, school, lab and institute websites.