There doesn’t seem to be a lot of information about the challenges of building and maintaining large Web sites available. Much of the industry seems to be geared toward smaller units/contracts of work. But there is a sizable number of people who work for large dot coms over many months or years.
Working on a large sites with large teams has different challenges than small shops. Dealing with the enormous effort of developing many projects concurrently, and the on-going maintenance that is necessary can seem overwhelming at times. So I thought I’d write down some of my thoughts based on many years of experience at a large dot com in the hopes that it may help somebody.
Well defined Style Guide and/or Patterns Library (design doc)
This is the fundamental key to success on a large site. Whether to use a Style Guide, Patterns Library or a mixture of both is not as critical. The important thing is that you have a very well defined design doc that everything can extend from. It’s impossible to effectively run a large site without it! Let me repeat that. It’s impossible to effectively run a large site without it!
Don’t get too carried away with your definitions of patterns or styles. One of your goals of a good design doc should be to create consistent experiences for the user. Every designer shouldn’t feel a need to put their own personal fingerprint on every project that comes their way. Keep an eye toward extendibility and consistency. Do you really need 37 shades of gray backgrounds and borders, 17 different font sizes and nested borders with drop-shadows and gradients? Probably not.
It’s very important to have a design that can be managed well in the code. You want to be able to stick with good, structural, semantic markup as much as possible. Adding a bunch of extraneous code to pull off detailed design has many impacts; pages download and render more slowly for the user, people with disabilities (think screen readers) have to wade through more “noise” to get to the content, as well as search engines. Also, on a large site, bandwidth is very expensive and should always be a consideration.
My point is that the design doc should not be created and maintained only by visual designers or coders, but a combination of both — a true partnership. Visual people need to understand that the vast majority of people aren’t going to pay attention to the same level of detail as them. And coders need to understand that sometimes they may need to add some non-semantic markup to pull off certain effects. Try to work on the KISS rule — Keep It Simple Stupid. There’s a balance between under-designing and over-designing, and finding that balance is easier when you work on the KISS principle.
Designers should spend their energy maintaining the vision and branding of the site by smartly evolving the design doc over time to keep it current and consistent. This frees them up from designing every new project, big or small. Instead, they just leverage the design doc to quickly give direction — no detailed comps needed for everything. This speeds up the day to day project life cycle tremendously, and keeps the user happy with a consistent experience.
So why is it so incredibly important? Everything in the entire project life cycle depends upon it! Designers and developers can quickly assemble new products and feature. QA can quickly and efficiently test against a formal document. Developers can create a more effective cascade, leading to smaller downloads and quicker page rendering for the user. In the end, it’s all about the user and their experience.
Danger! If you don’t start off with a very good design doc, your site will become very unmanageable VERY quickly. These checks and balances need to be in place to ensure that every individual designer and developer doesn’t put their own personal influence into the process. This WILL happen in the absence of a formalized design doc and process. The result will be many, unmanageable style sheets with a broken cascade and a poor, inconsistent experience for the user.
Well defined components
Now that you have a very well defined design doc, go ahead and create your basic layout templates and setup all of the global styles. Headings and paragraphs look like this, my four-column grid is put together like that, etc. You want to get as much built and defined in the master style sheet(s) as possible. All colors, typography, borders, etc. should be taken care of.
Now you can go ahead and create all of your components or widgets or whatever you want to call them. Since every piece of content needs to be addressed in the design doc, it should be easy to predefine some basic rules of these components. Of course, I’m assuming you’re using some reasonable technology (basic scripting language or good framework) that allows you to easily do this.
These components should be built in such a way that they can just be extended from anywhere within your site. Yes, this means using the same component of code in many places. For example, you may have an information box that is used in several places. The rules of the box are the same, just the content changes. So you can create a component that sets up the container; you know that it’s always going to have a 1px border with 10px padding and a subtle background image. Once you’ve created this component and the styles that rule it, you can just use it wherever you need it, just changing out the content. Now, if you decide that box needs to be treated slightly different, you can change the one component and all instances of it change throughout the site.
Planning this all out is not always simple, and requires a great deal of thought and understanding. This is where you want your most experienced developers. You can’t build a high-rise without a carefully planned foundation.
Make sure that all of these components are being created properly, using the cascade effectively — always defining your CSS rules as far up the cascade as possible. These definitions should go into your master CSS file. Once everything is defined from a style perspective, any new features or products (assuming they adhere to the design doc) should have no need to make any modifications to the master CSS. This enables us to create a very robust approach to our CSS that is very easy to maintain over time.
From my experience, in a large, fast-paced environment, the timeline rules all projects. Developers rarely have time to trace problems down and rework general implementations to suit their needs. Without a great foundation in place, they’ll likely end up undermining the cascade by adding a class to handle their specific need. Months and years of this behavior make managing maintenance and development more and more difficult. You eventually end up with a cascade that doesn’t, and very bad classitis and divitis.
Division of labor
Large development organizations are never staffed with only top talent. There is almost always a very large gap in skills, from very junior, to hopefully very senior. The approach I’ve outlined lends itself very well to this environment. You have your senior people (perhaps working with intermediate people) defining and creating reusable components and managing global style sheets. The more junior people can then implement those components, only having to worry about basic layout principles like component sizes and page placements.
It creates a natural evolution path for developers. As people become more skilled, they take on bigger challenges, ultimately ending up in more of an architectural role, setting direction. It gives people incentive to acquire more skill to get more interesting and impactful work. If some people don’t evolve as expected, and since you work in a large environment it’s often very hard to terminate people, you just keep them in the implementation role, where it’s difficult to mess things up too terribly. After all, people doing the implementation shouldn’t be messing around with the master CSS file since they shouldn’t be doing any styling that involves overall color, typography, component padding, etc., etc.
It’s very important that the more senior people in the organization also police the output to ensure compliance. Code reviews should be performed regularly, to keep the site in constantly good shape. Hopefully, companies recognize that senior people shouldn’t be allocated to purely tactical roles and budget accordingly to free up resources to tackle strategic vision.
Benefits
- Improved Consistency: The user experience is much improved because the system is kept in tact. Your users make easier transitions through your site, and actually stick around longer as a result.
- Increased Productivity: Designers don’t have to spend weeks putting their fingerprint on it, or develop lots of visual comps. Coders don’t have to spend weeks trying to override other styles in the 20 other style sheets in the cascade. QA doesn’t have to track down visual comps and pixel-punch us to death.
- Enhanced Adaptability: Easier to make cross-site changes rapidly and consistently.
- Better Partnership Management: If you engage a partner to help you build products, or partners to host certain parts of your site using your branding, you can deliver the design doc for them to follow — very simple, very formal. No more random implementations.
- Decreased Arbitration: By this I mean there is no constant squabbling between design and development because there is a clear, respected document to refer to if somebody tries to stray from consistency.
- Measurable Coding: You have a better plan to measure development efforts against.
Key Factors for Success
- If it’s not defined in the design doc then it doesn’t go on the site.
- New products or changes to existing products must adhere to the design doc. Any deviation is fine… as long as it goes through a formal review/evaluation/change control process. There is no free license taken with it, ever. If it’s worth changing for a project, then it’s worth the effort.
- The design doc needs to be in an easily available format and changes need to be well communicated.
- Everybody in all groups must adhere to the design doc and abide by the processes.