If you’re working for a multi-person organization, you’re probably used to following rules: submitting timesheets, requesting time off, or following a project process are just a few.
But what about rules that guide the work you do? If you’re a designer, you may be accustomed to following a style guide. Developers might have a set of coding practices they’re asked to abide by. Do you have any rules—or standards—like this that you’re asked to follow? If so—and be honest!—how often do you follow them?
Based on my own experience, I’d bet that you don’t follow them as often as you should. Or, if you do follow your standards, you probably feel that others don’t. Does this sound familiar?
From large corporations to small consultancies, a lack of standards and standards-compliance impedes Web development progress. Why is this? And what can be done to solve this problem?
Let’s assume that you already have some sort of standards—design or technical—in place. If you asked people why they don’t follow the documented standards, what would they tell you (FIGURE 5.1)?
While it may seem that the people are negative, it’s important for a manager to deduce the deeper problems (FIGURE 5.2).
What’s standing in the way of success is timely updates, regular communication, and constant reinforcement, so what you need is a strategy for maintaining the standards, communicating them appropriately, and ensuring their correct use.
And what if you don’t have any standards? You may have more inertia to overcome than an organization that has something in place, but the same process will help you get in gear.
You may be skeptical, but I know from experience that change is possible. I saw it happen at AOL, where I worked on standards for five years. Its situation a few years ago may not be unlike yours today. AOL had some standards documented but they weren’t complete, nor were they regularly updated. There was some management support for them, but that support was inconsistent. And there was little communication about the standards, which meant that only a fraction of the people were even aware of them.
All of that changed, thanks to the Circle of Standards.
Instituting standards and getting people to embrace them is all about change. As any business student will tell you, effectively instituting change is all about managing organizational behavior. And what’s the best way to manage change in organizational behavior? The answer is process.
The Circle of Standards (FIGURE 5.3) is a three-stage cycle that enables the successful adoption and continued implementation of standards by addressing their management, training and communication, and continual review—all of the problem points identified above.
To get things started, the standards process itself must have a champion within an organization. At the outset it’s not always possible for the champion to devote full time to this role, but as standards become more and more important to the organization, it becomes increasingly important to the organization’s management team to put someone in charge of standards—a standards manager.
Depending on the size and reporting structure of an organization, it’s possible to have one person fulfill this role; however, I usually suggest a team of at least two people, even in the smallest organizations, for greater morale, workload balancing, and redundancy.
Putting together a standards-management team is especially necessary when managing standards for multiple disciplines (such as design and development). Having more than one person addressing standards allows each individual to focus on the standards that are most closely related to their area of expertise.
Here are a couple of sample organization charts for standards-management teams (FIGURE 5.4):
The first and most important phase of this process is, of course, the creation and documentation of standards. The success of the training and review phases depends on this.
Merriam-Webster’s online dictionary defines standard as “established by authority, custom, or general consent”; so some standards will be dictated (like branding), some will document current practices (like page layouts or choice of DOCTYPE), and the rest will be determined by interested parties who sit down to resolve issues (like whether to indent code with tabs or spaces).
Standards are best set by the appropriate party or decision process and then thoroughly documented by someone who pays excellent attention to detail.
If you want a complete set of standards, look at your organization from various perspectives, seeking to document the organization’s needs from every angle, such as user experience and design (including user interface design, interaction design, and visual design); technical implementation (including front-end, middle-tier, and back-end coding); and potentially others including content (language style, imagery, and photography) and marketing.
Tip
The Web Style Guide, 2nd Edition by Patrick Lynch and Sarah Horton is a great reference that has an outline many companies and sites start with and build on (http://www.webstyleguide.com).
To help an entire organization to at least start from the same baseline of standards, it’s helpful to give everyone the same basic goals and rules. TABLE 5.1 provides a brief checklist of suggested content for both design and technical portions of a project.
Table 5.1. A Standards-Based Content Checklist
For a design style guide | For front-end technical standards |
|---|---|
Browser support matrix | Browser support matrix |
Accessibility policy | Accessibility policy |
Optimization guidelines | Optimization guidelines |
Creative vision statement | Coding rules (syntax and style) for each language, including HTML, CSS, and JavaScript |
Branding, including logo usage rules | Naming conventions and semantic model |
Grids, page layouts, and dimensions | Standardized code snippets for common UI elements |
Persistent page objects (like header, navigation, and footer) | Information on shared code libraries and APIs |
Color palette and typography | Best-practice coding techniques |
Content layouts and standard image sizes | |
Interactive elements (links, forms, menus, wizards, dialog boxes, etc.) | |
Multimedia design information | |
Advertising considerations |
Note that the first three standards are shared between design and technical scenarios.
Getting started with creating and documenting standards can be easy or hard—all depending on where your organization stands currently with respect to standards. Here are a few scenarios:
Everyone in your organization is pretty much on the same page (FIGURE 5.5). Overall, there is clear creative direction and good code consistency. What are you waiting for? Just do it! Start documenting the institutional knowledge. Peer reviews of the documentation can catch most problems, and a final review by a creative director or technical manager can garner the necessary management signoff. Post the information online and/or print it out, and your standards are official.
Most people in your organization care about standards and want to be on the same page, but things are a mess and no one knows where to start (FIGURE 5.6). Outsourcing would be beneficial in this case. Find a consultant who has experience in creating guidelines and standards documentation; he or she will ask the right questions to help your organization determine what standards are needed. If you have the budget, the consultant could also create your initial documentation, so you start with solid groundwork.
Only a few people in your organization care about standards (FIGURE 5.7). There’s a lack of creative vision or code consistency, and leadership isn’t doing anything to help. In this case, pull together the most talented, engaged people you can find and start doing whatever you can. Evangelize your work to peers; demonstrate the benefits to management. As more and more people buy in to even small portions of your work, you’ll find that they’ll start to expect more. With that support, you can grow into one of the other two scenarios!
A Note About Outsourcing
Even in cases where documenting standards in-house could be done very rapidly, sometimes it can still be easier to outsource the production of a standards resource. I don’t say this as a former standards consultant—I say this as a standards manager. While the consultant is busy writing documentation, you can work to prepare the organization for what’s coming by building and training a team of evangelists. On the other hand, if there’s no budget for a consultant, you can engender support for the standards by divvying up smaller tasks, such as creating figures, code samples, and downloadable templates, among a group of designers or developers to lessen your workload.
As important as the standards themselves is the process by which your organization plans to keep them updated. Standards need to be updated on a regular basis—for example, as rebranding or redesign efforts take place or as new interaction models or technologies are implemented.
To figure out how to manage standards updates, think about the rate of change and the size of your organization.
In a large organization, change typically takes time, so quarterly updates may be all you need. In a smaller organization that is changing rapidly, you may need to manage monthly or biweekly updates. Plan for both best- and worst-case scenarios, and you’ll be prepared for whatever happens.
As the standards start to take shape, be in constant communication with your audience about what’s taking place: Send periodic newsletters, cross-communicate among disciplines, meet with managers, conduct Q&A sessions, and report upwards.
During the early stages, you may be able to experiment a bit with formats and frequency, but try to establish a pattern of communication that can be maintained for the long term. Eventually, you’ll have people trained to expect updates!
Planning for training programs can also begin as the content outline for the standards is finalized. There are three kinds of training curricula that need to be planned:
Staff training—. Level-setting intensive introductory training, required for all staff as soon as possible following the completion of the standards. The goal is to rapidly get everyone who has some functional relationship with the standards up to speed with what’s in them. Functional relationships include people managers, project managers, and product managers, so make sure the content is customized for their needs as well the needs of the design and technical staff.
Individual training—. For newcomers to the project/team/organization, offered when the need arises. This may end up being the same curriculum as in staff training, but may be presented in a different format (such as computer-based training or video) to accommodate small groups of people.
Routine training—. Periodic refresher classes or updated training modules. While the content of these courses won’t be determined at the outset, planning now will help set expectations for the future (and avoid unwelcome surprises). Devise a tentative plan that addresses frequency, expected content, delivery format, and recommended participation levels. Make sure that people managers are aware of your schedule so they can plan for their teams’ participation.
As with the standards themselves, outsourcing the development of training programs can speed up the creation of coursework and presentation materials; it’s also an excellent path when a large organization has few qualified trainers in-house. A training consultant can also coach individuals within the organization to prepare for future training efforts.
If the size of the organization doesn’t warrant bringing in consultants, or if the budget isn’t available to make this possible, finding individuals in-house to help develop and deliver the training program is key. You want to find people who can rapidly learn and apply the standards and who have strong presentation and/or written communication skills.
In both communications and training, be honest about the process by which the standards were created and open about processes for updating and adding new standards. Transparency into the process of how standards are made will demystify them and make it easier for people to use them.
Once the standards have been created and everyone has been educated about them, people should not simply return to their work and assume all is well.
Every project needs to be reviewed at specific milestones to ensure that the standards are being adhered to as well as to keep an eye out for new standards that need to be documented.
Designers may be familiar with the design review process, which usually involves a review by the person who owns the creative direction of the product. Other aspects of the design review process vary from organization to organization. In some but not all companies, peer and/or managerial reviews must be conducted before the creative director will review a design.
On the technical side, developers may be accustomed to documenting their development plans in a technical design document (TDD), which undergoes peer and/or managerial review before work commences. In smaller organizations or on smaller projects, the TDD may be skipped. A peer code review is probably more common, to help developers find and resolve bugs.
Design and code reviews make for a good start, but aren’t enough to ensure adherence to the standards. Why not? Unless your creative director crafts all of the design standards and is thus intimately familiar with them, details are bound to be missed. Peer code reviews are useful in cases where everyone’s a control freak, but friends will sometimes go easy on one another and not call out inconsistencies. You need a separate standards-compliance review as shown in FIGURE 5.8, conducted by the standards manager, to ensure total compliance.
In the quality review process as shown in FIGURE 5.9, peer reviews help individuals prepare for standards-compliance reviews, and standards-compliance reviews are required before creative or launch approval can be given.
For those already operating with some sort of review process, an additional standards-compliance review may sound like extra work that will slow operations. But if standards-compliance reviews are conducted regularly or on demand, the overall time required is negligible. More importantly, in some cases, they can garner huge gains, because the standards-compliance review may find potential issues that can be fixed before any time is wasted waiting on the approval end.
These review processes work well when designers and developers are implementing based on existing standards, but what happens when something new, for which there is no standard, needs to be implemented? One of two things can happen:
The standard can be driven by the project team, closely monitored by the standards manager, who will need to keep up with the project team on every decision or execution point to ensure that a true standard can be derived from the project work.
The project team can hand off the standards-related work to the standards manager, who then produces both the standard and the deliverable(s) needed for the project.
Which way is better? I’m of two minds about this: I think the first scenario works better for design projects and standards, and the second scenario works better for development projects and standards. However, I’ve seen both work equally well for each discipline, given the right level of involvement and communication. If you devise a plan to handle both scenarios, you’ll be able to decide which will work better for any given project.
Now that you’ve learned about the Circle of Standards, how do you put it into practice? First, find willing, strategic allies who can help you gather information and from whom you can learn about aspects of the organization you’re not familiar with.
If your organization has an operations manager or team, contact them and let them in on what you’re trying to do. Seek out people in operations, as they tend to be kindred spirits when it comes to instituting standards and modifying processes to accommodate those standards.
Next, get organized! Inventory what standards you have, if any, and start a list of what’s missing. Review current training materials to determine where they fall short on evangelizing the standards. Iterate through your product development life cycle (PDLC) to determine where reviews are or ought to be happening and where standards could come into play.
Figure out who you need to sell on this methodology and how best to enlist their support. Document your findings in a slideshow deck or manifesto, practice your pitch, and set up a meeting to engage your targets. If you get some pushback or even an outright dismissal, don’t give up. Persistence is crucial in standards evangelism. Take a step back, restrategize, and try again.
All the while, keep working on crafting your standards and evangelizing them. Grassroots work is just as important and effective as setting top-down policies.
Sometimes being a standards manager can seem like thankless work—relentlessly pursuing stodgy executives, dealing with complaints from cranky designers and developers—what’s the point? The point is to ensure that your organization produces consistent, high-quality work, which it wouldn’t be able to do without you. Make sure the organization takes time to celebrate every success—every product launch, every new standard, and every standards conversion. By recognizing the projects and teams that implement the standards, people will come to realize that standards are the key to success.
To keep up momentum, maintain a rotation of volunteers who work with the standards manager. If you have representatives from different teams or disciplines working with you, give them a break from time to time—not to discourage or punish them, but as a reprieve from working an extra job! Finding additional volunteers helps build support for the standards by including more people, and giving people a short break from “imposing” the standards ensures they come back to the effort energized and ready to do more.
If you’re able to have a whole standards team, make sure there’s variety in each person’s work. Simply reviewing others’ work and writing documentation isn’t enough to keep someone engaged, so offer them the chance to participate in design or development work, to keep their skills up to date. Have them expand their skill sets by giving talks or conducting training sessions. And always make sure your team is having fun.
Standards evangelism is exciting work, but it’s also difficult work when you don’t have a plan for making standards a reality. Process management might seem boring, but it’s a very useful tool in successfully changing organizational behavior. The combination of the two—believe me—makes for dynamic, rewarding work.