Building Twitter Bootstrap

A year-and-a-half ago, a small group of Twitter employees set out to improve our team’s internal analytical and administrative tools. After some early meetings around this one product, we set out with a higher ambition to create a toolkit for anyone to use within Twitter, and beyond. Thus, we set out to build a system that would help folks like us build new projects on top of it, and Bootstrap was conceived.

Made by myself and Jacob Thornton, Bootstrap is an open-source front-end toolkit created to help designers and developers quickly and efficiently build awesome stuff online. Our goal is to provide a refined, well-documented, and extensive library of flexible design components built with HTML, CSS, and JavaScript for others to build and innovate on. Today, it has grown to include dozens of components and has become the most popular project on GitHub with more than 13,000 watchers and 2,000 forks.

Here we’ll shed some light on how and why Bootstrap was made, the processes used to create it, and how it has grown as a design system.

Recognizing an opportunity#section2

Some of our early internal tools at Twitter lacked a refined and approachable design and we found it difficult to develop or iterate quickly. Folks from various teams recognized this problem and saw an amazing opportunity for this and future projects. Acknowledging this, we began to form a rough process by collaborating across Design and Engineering early on.

At a high level, our process began to look something like this:

1. A few internal tools developers worked with product managers and the potential users of each tool to identify key functionality and features.
2. I worked with developers to identify our needs and then design them in the browser to create a consistent visual language and explore interactions. After the first implementation, we debated each component and weighed other options and implementations carefully before moving on.
3. After that, we designed and coded isolated components for the new internal tools project we originally set out to create. During this time, we quickly implemented, tested, and iterated each new feature.
4. Lastly, as a follow-up, I took those same components from the internal tools project, and added them to a shared codebase (Bootstrap) to abstract and document them for other projects.

Ultimately this boiled down to one core concept: pairing designers with developers. Constant interaction with developers is what sparked Bootstrap and continues to drive its development over a year later. From whiteboarding ideas to coding rough prototypes, collaborating across disciplines is what made Bootstrap successful for internal use at Twitter. This process informed the development of nearly every feature in Bootstrap and has worked remarkably well over time.

Building Bootstrap in this way meant communication was key and most design work happened in code. Since the final deliverable for Bootstrap is always code, it made the most sense to work there as often as possible to communicate our ideas. This put one into the mindset of a good developer, encouraging succinct components, but with the visual polish and thoroughness one expects from a dedicated designer.

An example#section3

Let’s look at one feature of Bootstrap: dropdown menus. To help house information about the current session and bubble up other areas of the tool, we needed dropdowns. Everyone and their uncle has dropdown menus in their applications, each one with varying implementations, interactions, and visual design, so how would we do it? Following the outline above, here’s how the feature came to be in Bootstrap:

1. We recognized we had too many navigation links and actions in the fixed topbar we were using; extensive, multi-level dropdowns seemed like a solution.
2. We worked together to identify why so many links and actions needed to be there in the first place, and why we might need multi-level support.
3. After some debate, we resolved to rearrange the topbar to remove some links and implement the dropdowns, but without multi-level support. At the time, they meant extra code that complicated our implementation and we wanted to avoid that.
4. Next, we wrote the basic HTML and CSS for dropdowns on :hover. We refined the visual details within the tool’s codebase and then abstracted and documented them for Bootstrap.
5. As one last step during abstraction to Bootstrap, we opted to have the behavior triggered on click rather than on hover. We found this helped avoid user confusion and accidental clicks, providing a better experience.

Most components and many of the finer details surrounding them were designed and built by pairing designers with developers. Together, our process for each new feature or design component matured to ideation, debate and feature review, implementation, and lastly abstraction and documentation. It made the development of our internal tools rather smooth, helped us avoid feature creep and code bloat, and helped us to document not only how to use a component but why you should use that particular component in Bootstrap.

This naturally extends beyond new features and into existing ones. Should a feature we already have need to be modified or removed, we follow the same steps: ideation, review, implementation, and documentation. Continuing the example, we have received a great deal of feedback around dropdowns and may revisit multi-level support. Since web applications are behaving increasingly more like desktop counterparts—which do use multi-level dropdowns—it makes sense that we consider supporting them. Sure—we could simply back out of our earlier decisions—but this process keeps us honest, relevant, and accountable to our users and their needs.

Parallel development#section4

Our process carried us through nearly all our feature development and highlighted an important aspect of our decision to go beyond building just one tool. Parallel development meant we had to effectively communicate our work to others who had no exposure to the processes or insights of our work.

While we were busy working to create a product roadmap and determine a single project’s goals, we actively considered how others would use the same component. Abstracting and documenting components became part of our process for building this one tool and Bootstrap in tandem. Overall, we saved time and effort, more clearly debated the value of adding (and on occasion removing) features, and set ourselves up for tackling much larger projects in the future.

After the first few weeks of development, we began to refer to this living document as “a toolkit built in style guide form.” This achieved our goal to communicate our work through Bootstrap, which allowed Bootstrap to quickly grow and become usable by anyone.

Bootstrap as a style guide#section5

The decision to create Bootstrap as a style guide came naturally out of our design and development process. Bootstrap helps us document components with live examples as we build them, while serving as a living document powered by itself, the very components and templates it prescribes. It gave us a single point of reference to share guidance from designers and created a set of documentation for each living component.

Building Bootstrap as a style guide affected its development early on. It kept us honest about the features we wanted to implement by helping us look beyond one project. We didn’t want to limit ourselves to designing a single project—we had higher ambitions and didn’t want to pigeonhole ourselves or those who could benefit from such a tool. Our approach ensured we didn’t just build tools for Twitter, but one that could be used by any designer or developer.

Cater to all skill levels#section6

The living document approach gave us a chance to not only share the entire toolkit, but to also provide written and interactive documentation to anyone who wants to use Bootstrap. This approach catered to those of us at all skill levels, allowing anyone to clone or download the repo for the source code or use the Inspector or view source in the browser.

As development progressed, this became one of the guiding principles of our work, one encapsulated by the credo, “Help awesome people do awesome stuff.” This dovetailed with our goal to clearly articulate design and development decisions to those who had no insight into the original process or product. No matter the skill level or workflow, we needed folks to be able to open this living document and be able to use Bootstrap to quickly and easily build something they love.

Evolving through collaboration#section7

In the beginning, Bootstrap only included typography, tables and forms, a color guide, and some graphical assets. It was a presentational best-practice guide for how to use some of our company-wide design rules. At the time, we only needed a more personalized CSS reset and company resources to add a small amount of flair to development.

As more folks and prospective applications became involved, more features were requested. Over time we ended up with many more components, including a fixed topbar, tabbed navigation, dropdown menus, extensive forms, and more. Throughout the entire process, the collaboration between designer and developer resulted in each new component being added. The collaboration made for many rewarding and exciting conversations and features.

Today, Bootstrap includes dozens of components with many more planned, but only as their need and functionality are clearly identified using the process we established early on. Jacob and I iterate on the toolkit by managing feature requests and tracking issues and bugs. We work together to evaluate each new item to measure its usefulness to the community. We only implement a new feature if it doesn’t confuse users or unnecessarily inflate the framework. Having a process in place that allows folks to equally evaluate new features is incredibly powerful and necessary to the project. Our collaboration has extended well beyond the reach of a single project and into every one since then, especially Bootstrap.

Closing remarks#section8

Bootstrap had its first practical test in real-world use at Twitter’s first Hackweek. During the week, I helped a few folks use Bootstrap on their projects to speed up development, but had no idea how effective or widespread the toolkit would become. When all the teams got in front of the company to present their ideas, dozens of them were using Bootstrap. They had used Bootstrap to create projects that all felt like a family of ideas with a consistent design and implementation. A simple, well-designed, and documented toolkit saved countless hours with little to no help from a dedicated designer.

Put another way, it worked!

With the project now open-sourced and available to all on GitHub, our success continues as we help nerds everywhere accelerate their web development. Our development process for Bootstrap remains intact, but has evolved to make use of GitHub’s constant feedback cycle through issue tracking and wiki features to better communicate with those using the toolkit. Because of this, we’ve pushed out a number of releases and have more planned. Our next major release is v2, a larger effort to add a responsive grid system, extend the JavaScript plugins, close countless bugs, and improve our documentation.

Without parallel development and collaboration across teams, Bootstrap wouldn’t exist and we would have created another one-off tool. Internally, projects like Bootstrap began to change how we worked together. Questions began to change across teams from “make this look better” or “build this” to “how can we solve this problem”—and Bootstrap thrives on that. The collaborative process helped us work more efficiently and build a lot of trust among one other.

Thanks to the foresight and focus of a small group of designers and developers, we were able to evolve our development process, build an extensive front-end toolkit, and help thousands of others bootstrap the projects they love.