How to Create an Enterprise UI Toolkit

The benefits of a UI toolkit are numerous, and they are created in a number of different ways, but there are no ultimate rules stating what they should include, which can be somewhat confusing.

Over the past few years I have worked at two different fortune 500 companies and we have created various versions of UI toolkits for online software products. (The most recent toolkit was a mini-application built in the same code base as the primary application, and it has proven to be invaluable.)

An enterprise UI toolkit can't be as simple as just leveraging Twitter Bootstrap and calling it a day, because there are many more factors to consider for large software products than there may be for other types of applications. I’d like to give you insight on the types of toolkits that my teams and I have created in the hope that you can reference them for your own team.

What are They, Really?

An enterprise UI toolkit is essentially a mini-application that serves as a living library of the patterns, visual standards, and interaction behaviors as well as the framework and code samples for the actual front end of the user interface. My team is taking it one step further right now and working with the developers to extend eusable code beyond just the HTML and CSS.

This brings the team a bit closer together than using dispersed libraries of code and wikis of information. The toolkit does not house all of our work, such as wireframes and prototypes, user journeys, personas, user research, and other documentation, which we keep that on the company’s server.

The most common UI Toolkits freely available today vary from being focused on a framework of code—as with Twitter Bootstrap or ZURB Foundation—to a pattern library. My teams combine all of these goodies into one enterprise UI toolkit customized for our company’s needs. This gives us the ability to rapidly prototype and consistently implement the intended design of an application.

The biggest benefits of the enterprise UI toolkit are:

Allows for shared understanding of design and front end development best practices

Allows re-use of assets in the application

Allows the designers and developers to standardize a consistent set of patterns throughout the application

Allows for sketchy wireframes to serve as final deliverables in many cases

Allows you to move away from repetitive specification documentation by just referencing your patterns

Supports the growth of the product over time

How They're Built

Just like you do with your products, the first thing to define when creating a UI toolkit is your audience. This has caused quite a bit of circular conversation for my teams in the past. In order to work in agile development, you have to have shared understanding across the whole team, so the audience must rightfully be the entire team: designers, developers, QA, and product owners.

Keeping this in mind, your different personas will have differing needs of the toolkit. Designers will mostly reference the interaction and visual patterns, developers will be most interested in code samples, and product owners and QA will want to understand the whole picture so that they can ensure the product is being built as intended. I've been working with remotely disbursed teams from the U.S. and around the world—not in-person only. The toolkit still holds value and is even more useful as a communication tool for remote teams.

During my initial research, I referenced examples such as the Fireworks/Evernote library, Patternry, and various other online options. I also created one on WordPress using very little programming code and a few plugins for the form submission and viewing. The creation of the toolkit can be done in-house or externally, depending on your company’s needs, budget, and time constraints.

Chances are if you are in a large company, you will want to build something internally and perhaps even leverage it across different products. If you decide to design one yourself, be careful to start lean, just as you might for your products. Part of the reason that UI toolkits can be troublesome to create is because, as designers, we can find ourselves striving for perfection.

Treat it like a product and add to it as you go, incorporating feedback from the users and letting developers or other team members know when something is ready for use as it gets released.

How to Create Your Own Internal Enterprise UI Toolkit App

Here are some tips for building a successful enterprise UI toolkit that I've picked up working with my teams:

Design a very basic layout with a simple taxonomy for grouping your patterns on the left hand side of the page and a list of your actual patterns on the right in grid or image display.

Be clear on the naming convention for your patterns right away. This is what you reference in your specifications in all of your wireframe or prototype work so you don’t want to change them in the future. (We kept the standard Bootstrap layout at first for our header and added basic admin functions to that menu.)

Create very basic roles for administration of the site and viewing or editing. We created two states for the patterns: draft and published. Non-admins only view the published patterns.

Have a form for creating patterns that includes, at minimum, the name, the category, and image(s), as well as information on when to use, how to use, CSS (or SASS, LESS etc), and HTML examples displayed with HighlightJS or similar. We also provide a link to working example code. All of this information turns into the individual pattern page. Your users can then view the full list of patterns or drill down for details and code examples.

Pushed the SASS and any visual assets directly to the development team’s source code, so they didn’t need to go find it. We continue to improve communication on best practices being followed within the SASS as comments on the toolkit.

Add the ability to show dates of recent updates, recent changes, or archived patterns that have been replaced with new ones.

Add the option to link related patterns since some patterns such as form controls are often contained within parent patterns.

Style the UI toolkit the same way that you would style the real application, to re-enforce working examples of your standards.

If you have more than 20 patterns, make sure they are searchable.

We’ve added the option for HTML only pages so that we can list, for example, the SASS names for the base colors and examples of them.

Consider making the toolkit interactive and add video recordings of how to use the patterns for remotely dispersed teams.

Ideally, you can build your UI toolkit using the same technology and code repository for assets as you would for your application. If there are barriers to doing this, get it as close as possible to ensure that you can at least easily transport your CSS to the development teams.

Conclusion

I’ve worked with companies that are afraid to create and maintain this type of interface, especially when it comes to the front-end code. A common question is: “What happens when you re-do the design?” Our answer is that you revisit the toolkit and either make minor adjustments or entirely re-vamp it to be updated with your current design paradigms. You can also separate and archive your old toolkit if you are supporting older versions of your application and still need to have it as a reference.

Variations of the UI toolkit I’ve outlined are already common at Microsoft, Apple, Google, and other companies that depend on developer APIs to expand their platforms. When the toolkits become irrelevant, team members stop using them and they get replaced with a newer version.

You could argue that this is too much documentation for purist agile and lean thinking. If you are on a smaller team or can communicate your design to one person doing all the work, you won’t need this level of documentation. However, if you’re running a bigger program with lots of hands in the pot, the toolkit becomes a living and useful tool worthy of its creation and maintenance.

My teams have had great success with enterprise UI toolkits, but their adoption relies on the entire team, not just the design folks. Evangelizing the toolkit and integrating it into your workflow are an important part of the process. If you do it right, this can be a huge asset to your company and your web software products.

ABOUT THE AUTHOR(S)

Ariel Grace Snapp is an Experience Design Strategist and creative professional. Continuously praised for her work on websites and web software, she presently leads a creative design team creating stellar user experiences for multimillion dollar enterprise software. She also helps people unlock creativity in order to feel happier, tell better stories, and make a larger impact on the world. For more information visit: ArielSnapp.com

Add new comment

Login via:

Your name *

E-mail *

The content of this field is kept private and will not be shown publicly.

Comment *

Because of problems with spam comments, HTML in comments is not permitted. URLs are allowed, but they will not be rendered as click-able links.

Comments

what's with all the thumbs down on all the comments? you guys having problems with bots? personally I think I'm going to jump into bootstrap.. I only know HTML/CSS and a bit of PHP.. and it seems easy enough for me to build out a really nice UI. Chrischayes.ca

Check out Tapestry - A free app (MIT license) that gives you an interface to store and manage your front-end patterns. We created the app to make it easy for both agencies and internal teams to manage UI patterns.

I generally call these Live Style Guides, since they're not only useful for enterprise environments. Also as per my definition, they may extend in either direction (containing static guides like redlines as well as back end code) but always at least contain some "live" mixture of working visual examples and code samples, tied to the code base.

UI toolkits or patterns, or standards. They go by many names. Useful till they are done correctly. With appropriate guidelines to use. And validated with enough user testing in the context of real products

Hi and thanks for the great article. At our company, we've created our own UI toolkit very similar to how you've described. We're now considering leveraging Twitter's Bootstrap instead to cut down on documentation and maintenance, and to have a common and familiar UI language for new folks joining our company as well as for people that customize on top of our product.

Do you have any experience or anecdotes on how to work in tandem with existing frameworks? Is it a "fork and keep separate" strategy or can you keep your own toolkit Bootstrap-compatible, for example, while building your own patterns on top of it? Thanks.

Hi great question - Either way works. Our current project leverages bootstrap but b/c we did custom SASS we made it our own and won't upgrade - it is much cleaner code this way also and decreases download times client side. We also leverage kendo ui and for that are commited to keeping it upgrade compatible - but that has its pros and cons. So, I think it depends on which 3rd party tools you use.

Hi Grace what are the enterprise Ui toolkit available. I have scene a problem in maintaining own toolkit for organise. A company I worked for use to maintain it's own MVC. FRAMEWORK, but its has to allocate several resources, later they abandoned internal framework and started developing on an open source framework which did freed few resources resulted in more enterprise applications. I agree with u that no framework is perfect and enterprise need to have consistency in UX, what's your opinion about dojo?

Maintenance is definitely part of the commitment to starting one of these. This is really geared at the front-end UI patterns more than the framework of the application. That being said, you could potentially house pattern and references that the development team would usually keep on their wiki or other areas for documentation.