A bunch has been written about front-end style guides. Anna Debenham has provided the most on the subject. Her site, styleguides.io, is the best place for style guide resources. I have a perspective on style guides at huge, old companies. It’s one you may have heard before, but I think it’s worth sharing. Implementing a style guide is hard.
To explore why style guides are so difficult we’ll look at a theoretical time line for a Fortune 100 financial services company. Suppose the company that has been around for 200 years. 200 years of sales, accounting, and management. Around 60 years ago those tasks started to be done with a computer. Then, 47 years ago, things on the computer got a little easier thanks to the graphical user interface. Those working using computers started to get used to the metaphors and interactions introduced in those early systems. 30 years ago, assumptions on how computers should work expanded to nearly everyone. The web became a thing 24 years ago, in 1991. Finally, intranets gained popularity in 1996.
50 years of history can be felt every day at old, large companies. That is not a reason to run from these types of institutions. Battling technical debt and legacy systems should be part of the design challenge. This might be controversial, but I think creating an all-inclusive style guide at a company of immense size and system history is impossible. At the very least it’s not worth trying to do. Companies that have a history that dates back to the first computer are using systems that couldn’t benefit from a style guide. I hate to say it, but HOST systems are too far gone. The text-based systems likely have very strong patterns that are taught to the users. Companies who have these systems know it is technical debt. If you have to help design something that must be implemented on these systems, do your best and move on.
So far the bad, but obvious news is that we can’t build a style guide for a text-based system. Desktop applications are a little weird too, but there use a GUI that we’re used to so it should be a little easier to implement style guidelines, right? Right? At this point I would start thinking a little smaller. The web! HOST is toast, desktop is at a rest stop, but the web. I know the web. I love the web! Surely we can build something that wrangles in the spaghetti styles and implementations across the different web properties.
Let’s take a quick inventory of the previously mentioned hypothetical companies web properties:
- An intranet built on an old CMS no one has heard of but each
<div>has in-lined styles
- A separate “web portal” for legal, finance, marketing, operations, etc. (times five for the different product lines) all built on different platforms
- A public internet site with 20 separate sites for customers to service one thing or another
- Microsoft SharePoint
So where do you start? I think the best place to start is the future. Because there are so old systems at these types of companies, it also means there are probably a ton of new projects. Redesign, rewrites, “reimagining,” whatever you want to call them. It’s these nearly greenfield projects (at least on the front-end) that you should focus on. I also think that the project should be something of scale and priority. Some may disagree but I think building the style guide shouldn’t be easy. Creating a style guide for one new site for one small department will feel like a style guide for a tiny blog (like this one). If you want this thing to last you have to have the fights and make tough decisions. Maintenance of the project is only going to get tougher. Do something that works well, but makes you really work as a team.
The other benefit to hitching onto a big project is that there is likely more room for scope and budget. Some of the approaches to building the guides are better than others, at least conceptually. Ian Feather’s post, A Maintainable Style Guide, is a compelling way to get the benefit of the style guide without loosing any development hours. However, getting buy-in isn’t going to be easy. There is never enough time, budget, or scope on any project. I’ll write more about approaches to getting buy-in, but for now let’s just say that the larger project is where you should start.
Quick aside, you can try to do this off the side-of-your-desk, I know Mark Otto did, but it’s going to be really hard to get it right. The challenge with this approach is time and resources. On my first attempt at this stuff I was able to get a decent static style guide built and launched internally. However, there was no budget and the priority was low. If you go with the Mark Otto approach, make sure you build up a team of people who are as passionate about it as you are. You’ll need a small army to support the project in their valuable free time if you don’t have a budget. Let me know if you do try it and actually get a maintainable work flow.
So you’ve gotten buy-in from the project stakeholders, the style guide development is being included in the project estimates, and you’ve studied like crazy to ensure the style guide gets built in the best way possible. Be sure to get a seat at the table early in project planning. If you don’t feel like you have the authority to have your voice heard, change your attitude. You’re reading about this stuff and have listened to dozens of others talk about their experience with this same type of effort. Work with your team. You probably have the best knowledge of how others have approached development with front-end style guides. Listen to your team though. They have had experiences with different projects and likely different companies. If they’re negative about something, get to the root-cause of their concern. If they have an idea for a different approach to development, understand why they feel that way and share your opinion.
These types of exercises have been going on for 50 years. You will be having a new and old conversation at the same time. Learn as much as you can and learn fast. Parts of how your organization implements this system might not work. Hard work now will make for much easier development and maintenance in the future.
Good luck! Check back here as I’ll be writing about some more specifics around style guide-driven front-end development. Also, let me know if you notice any grammar or spelling mistakes. The best place to get in touch is tweeting me @BenJoyceCT.