User interface toolkits are helpful for ensuring consistent quality in your web software products and encouraging rapid prototyping in agile software environments.
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.
The first thing to define when creating a UI toolkit is your audience
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.)
- Leverage your existing styles/layouts or Twitter Bootstrap/ZURB Foundation to jumpstart the code base.
- 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.
Image of screw bits courtesy Shutterstock.
