Wow, I’m a little stunned by the general lack of reaction to Monday’s post about the long decline in the quality of design style manuals. Maybe I was under some hallucination that this is an issue that many (if not most) designers will encounter many times in their careers, and that those designers would generally find the tortured motivations of style manuals to be a worrying state of affairs. Even so, it was one of my favorite pieces so far; I took out more time to write it than I do most pieces, and I think it represents a novel perspective on what it is exactly that designers deliver to clients.
At any rate, I’m undeterred in my pursuit of this subject. Never let it be said that I’m guided solely by comment count! As it happens, the second part of my rant on this subject is considerably less ambitious — it works off of the premise that the climate of client-designer expectations is one that’s unlikely to change anytime soon. For the time being, designers are stuck with these particular circumstances when it comes to style manuals: a high bar for comprehensiveness and a low threshold for time and for fees devoted to documentation — resulting in a lot of labor producing little value.
A Broken Idea
Given that situation, it’s reasonable to say that something about the entire style manual concept is broken. With so much effort going into so little result, it seems there must be a better way to do this. For a while, my own personal view was that the solution was simply to move away from the idea of these manuals as tomes, monolithic documents delivered in print form and intended to sit in someone’s file cabinet somewhere.
Producing these tomes usually entails a designer, often working without a proper copywriter, creating meticulous and pointless pages full of rote specifications with a program like QuarkXPress or Adobe InDesign. A lot of hours are spent creating an aesthetically pleasing presentation of numbers and facts. Once output in hard copy form, the effect is attractive and it can be very impressive, but it’s also often full of errors and always inflexible in the face of unforeseen contingencies.
That last point is crucial: a printed style manual is infinitely less adaptable than a digital version, and so for the past few major projects I’ve worked on myself, I’ve produced documentation in the form of a small Web site, using a mix of XHTML, CSS and PHP to provide a simple, centralized resource that can be shared with anyone. Instead of a printed document, what’s delivered is a micro-site that can reside on a client’s server or a password-protected external server.
This method is dramatically faster than using a page layout program, and allows for relatively painless updates, even major ones, because there’s no problem with maintaining multiple versions of a document, and no problem managing the distribution of those versions. In digital form, the manual can also provide direct access to source files. By making Photoshop files, Illustrator art and snippets of code available from directly within the HTML, it often precludes the need to painstakingly diagram the minutiae of a design solution.
Again, nothing in these style manuals, whether in print or digital form, could ever substitute for a full-fledged designer, nor can they anticipate every scenario that might arise. But at least in digital form the manuals are more pliable to the changing wills of project stakeholders.
Wikis to the Rescue
These style manuals I did were hand-coded, and I considered attaching some simple Web publishing tool to the back-end to automate their production, but the effort seemed to outweigh the benefits. That is, until I really put two and two together and realized that wikis, by their nature, are ideal for the production of style manuals: they make the authoring process markedly easier (if no less awkward) by eschewing XHTML for an even simpler set of markup tags that almost anyone can learn. They also allow simple, on-the-fly creation of new pages, which in turn allows for a more organic evolution of a manual’s content structure: style rules can be written almost at the same time as they are developed, and then later re-organized into a more coherent table of contents with little penalty.
Best of all, a wiki-driven style manual can be continually updated by its intended users, which is really what is called for when there’s little or no budget allotted for design documentation, or when a client lacks truly dedicated design staff. With a wiki, anyone can amend and append the manual as necessary to suit the particulars of their own needs and design experience; it relieves the design team of the pressure of creating an all-knowing manual (though not of the responsibility of creating thorough documentation), and instead asks them only to provide the building blocks of such a system.
It’s true that turning to wiki software to address this come-down in our expectations for style manuals is a bit of a cop-out. There’s really nothing inherent in the wiki mode of thinking that will necessarily encourage a return to the narrative, instructional quality of the masters’ style manuals, and that’s a shame. In one sense, by giving up on truly comprehensive style manuals in favor of group-edited manuals, we are driving an additional nail into the idea of design authorship. But in another sense, wiki-driven style manuals are truer to the often touted idea that the best design solutions are in fact living systems that can grow and adapt with changing needs. It’s the 21st Century, after all, and we should be documenting our design in a 21st Century fashion.
+
Great write-up!
Do you have any examples of online style guides that you can share?
Now that’s a solution! When you unviled wikis as a use for style guides, I smacked my head (figuratively) and thought, “Damn, that is indeed almost perfect”.
For web-generated style guides, that is indeed pretty good in keeping up an up-to-date scalable documents that allow a group of people to edit on the fly and when needed. A great call there.
As for narrative and whatnot, I’ve seen wikis used for countless things and I think that you can give a wiki a touch of the masters’ style guides by designing it as so and laying a few simple ground rules.
In the end, I think it’s those rules (the style guide for the style guide) that’s necessary in shaping the style guide.
For what it’s worth, I nodded along vigorously with the last post (on the internet, noone can see you nodding vigorously). I especially agree that style guides are 90% justification for expensive fees. “Look how much bound paper you got. Clearly it was worth it.”
Wikis are nice for keeping things organically up to date, and removing some of the resistance to adaptation, but it still doesn’t solve the problem of many client’s lack of long-term investment in design. They hire the “designer” to swoop in and do a quick fix, but they want the secretary or the intern squad to maintain the site or document or newsletter over time. The best design systems are always going to be broken in the hands of people who don’t understand why the system works in the first place.
I really like the idea of putting the style guide up as a wiki. In my current position, the style guide was originally a monolithic PDF, then was converted to static HTML pages a couple of years later. The guide has languished over the years as ad hoc “improvements” to the original design have been implemented at the request of the clients, to the point where the style guide is a very poor reflection of the current state of the site (and was when I joined the group three years ago).
I would suggest that we convert to a wiki in the process of updating our style guide if it weren’t for the fact that the site is undergoing a total redesign right now that will result in the current style guide and the group I belong to being discarded….
Khoi (or anyone reading here), what’s your take on *internal* style guides?
Most of this discussion has centered around delivering style guides to clients. But it seems there is at least some value in developing internal style guides, no matter how big or small an organization is.
We’ve been using wiki as a tool for maintaining requirements and specifications for the project we are working in the last few months. The wiki allows for quick addition of new content (use cases, requirements, entity and interface descriptions etc.) and an easy way to link all that content in a way that really works. The wiki is accesible by all team members and by the client in the same time and everybody is able to make changes and add new items when needed. The wiki keeps track of all changes and if an idea proofs to be bad, we’re simply reverting to a previous version of the spec. It also helps for documenting the design process as it shows how the system evolves.
I thought it would be a good idea to use the information in the wiki not only during the development phase but also after teh lunch as a documentation and help resource. It would be indeed something like a style guide where everyone interested would see why a feature is in the product, how the feature evolved and what is its intended use. Much like the Paul Rands work you mentioned in the previous post.
Very intersting thoughts Khoi. Keep them comming 🙂
I totally agree with Wilson on this. If the clients both desired and demanded documentation, they’d get it. It’s the fault of the client that is unwilling to invest either the time or the money to have that documentation created. My assumption is, the design firms that cut documentation and therefore come in at a lower bid are getting many of the contracts nowadays.
It just goes to show you that the bottom line isn’t always the bottom line.
For internal style guides, Wikis are definitely a great solution. It inspires a document-as-you-go mentality that means documentation actually gets written. With our internal wiki, sometimes all you need to do is start a page with a rough outline and somebody else will be inspired to fill in the details. It’s like the local Lazy Web.
John Zeratsky: I think these same thoughts apply to internal style manuals. An internal design team has just as much incentive to do a good job with a style manual because it helps communicate the value of their work to other groups. Plus, using a wiki is a great method to improve collaboration with those other groups.
George: wikis make great project management hubs — Basecamp and Backpack, for example, work so well because they share a lot of coimmon attributes with wikis. But I think that the style manual really needs to be something apart from the running documentation of the project. The style manual should be a living document on the use of a design solution, and it shouldn’t be confused with a document of the development of a design solution. This helps clean out all of the messy work that leads up to the completed design, and it helps establish the manual as something that should be tweaked and modified freely, but with the idea that its contents are definitive. That’s my take anyway.
Khoi: I didn’t mean that project specifications should replace style guide. I just wanted to point the similarity in the approach to the problem of developing specifiations / style guides. Similarity which is rooted in the need for a flexible environment for our documentation.
Khoi: We’re in the process of growing our design team right now, and especially as we’re starting to work across several parallel but distinct products, I’m feeling the need for some type of internal design documentation.
I love the idea of using a wiki for this. We can build on our docs incrementally and continue to prune as our team and our product line grows. Thanks for the idea!
As a former client recently turned designer in Italy, I think the sorry state of affairs is partly due to the fact that a lot of us designers, no matter how much they pay us, only want to design something “beautiful”. We don’t really want to go and hang around the factory for days to see why the 15cm logo we’ve created can’t be lasered by a machine that only moves 10cm; why the new swingticket means that the production line stands still for 20 seconds per product which adds up to thousands of man-hours at the end of the year; why the corporate font won’t work on monospaced AS400-generated documents; why the 8x5cm labels need to hold 3 bar codes for export; why the aesthetically-pleasing new box size amounts to an 40 full pallets in an overloaded warehouse. And if this is true, most clients are probably right not to invest much in the manual – most of what it says is going to prove wrong anyway, and we’re only hiding the inadequacies behind over-specific point sizes, grids and pantone references desperately hoping the real shortcomings don’t hit the fan too messily or too soon.
It’s funny that the original post mentions “design improving profits” and the “value of graphic design” – I think this is normally taken by designers as some kind of intangible “in the future” rise in profits and value as a result of the marketplace being impressed by the company’s new corporate ID compared to the competition’s lacklustre old logo. When I was a client, I was one of a team managing three ID revisions on three manufacturing brands in an industrial group, with three different external design agencies – all very good ones, and yet I didn’t meet a single designer who even asked whether the identity he/she was working on could help the company save money/time/warehouse space. Nor did any designer bother to pay attention to the line manager on the factory floor, the MD’s secretary or the accounts department staff. I don’t think any document we designers produce – be it a pdf or a wiki – can convince the people who really implement the identity on a day to day basis of its worth unless we design with and for them (clue: they’re not in the marketing department). Nor, probably, can we get them to consult or update a wiki anyway, especially if company policy means they don’t even have access to a terminal except for the one running the ERP in greenscreen. Nor will the printed manual end up in their lowly hands, so they won’t even read the lovely narrative backdrop to the new identity or see how it fits so perfectly between design heritage and bleeding-edge trend.
On the other hand, if we do go and speak to these people who are handling the identity in a strictly practical way, yet aren’t designers, and if we collaborate with them on the specifics of the designs, elements and layouts so that our work really helps to cut out the confusion and clutter from their own tasks, and make them a fundamental part of the process, then the company won’t need the manual anyway. If we start our work from the roots of the company and solve problems rather than creating them, we might even (gasp) help the company to save money immediately.
What about putting a clause in our contract that says that if our work helps reduce costs or simplify tasks for the company, then we get extra euros/pounds/dollars to work on the manual – at this point, just to have it in our portfolio.
Thomas: Wow, I’m not in agreement with some of what you said there, but you make some powerful points. It’s probably true to say that many designers don’t think adequately about the business impact of their work. I might also venture to say that’s a case that occurs more often in print design than digital design.
As a matter of course, I spend almost all day thinking about the business impact of the work we do at the design group at The New York Times, both because I want to produce meaningful, usable work with an impact on the bottom line, and also because it’s absolutely necessary to think in terms of business and journalistic ramifications in order for design to be listened to.
That said, I think there’s a flaw in your logic there: you say clients don’t want to hire designers to do good documentation because designers tend to just produce aesthetically-focused but business-deaf solutions. Well, in that case, why hire a designer at all? Clearly, clients see some value in the work that a design team can do for them.
Maybe the best way to characterize it is to say that clients will trust a designer only so far — far enough so that a designer will deliver a look, far enough to satisfy a business need to achieve a superficial design solution, after which point the client is no longer interested in the input. Whether this is a condition arising from a poor tradition of holistically minded designers or arising from client disinterest in the full value of design is hard to say. It’s a bit like a chicken or the egg quandary really: who really is responsible for the dumbing of design?
If it seems like I was laying the blame for this at the feet of clients only in this and my earlier post, then it’s my mistake. I didn’t mean to, or at least I shouldn’t have. We’re all complicit in the state of design today, just as we’re all responsible for where it goes tomorrow.
Ill just jump in here to say this was a pleasant read on a number of levels.
A) This was a great follow up post to the first installment and:
B) I’m glad to see this post generate feedback (although I felt the first installment was equally informative and warranted a full discussion, but understood it might take a few posts to get things going)
Full disclosure: I am not a designer but simply an implementer of design. Hence my interest in a style guide..or should I say, an “informed” style guide
This is where a wiki becomes key, in the relationship of client/service provider.
A well-maintained Wiki truly does become a living document arising out of the delivery of a “style guide” and shows a truly invested client in the new digital age.
It allows a forum for the client to grapple with issues either not fully covered by the style guide or issues that arise out of a faithful implementation of the style guide.
Wikis also speak to true open source development in some ways.
Well-structured Wikis can be “opened up” or re-broadcast to serve the development/design community as a whole.
If these broadcasts evolve out of a discussion from a well intentioned client, trying to implement a style guide faithfully, they can serve as incredibly informative “information sharing” devices that shed light on the digital design process as a whole and the ramifications of certain decisions made during it.
Again, a motivated client is key here. As a Wiki can also easily become a static document, much like a style guide itself, that only speaks to a “snapshot” of the design implementation process, if the client is not fully invested, as was alluded to in an earlier post.
But at their best, rebroadcasts of well informed wikis can be “guiding lights” that speak to, as was mentioned, the idea that the style guide can truly become a “living document” in the digital age, as it relates to interactive design.
Kudos x2
Khoi: yes, I guess I’m talking more about manufacturing industries or print-dependent businesses than web companies. But then again, offline companies are the ones you talked about in your posts: IBM, National Parks, NY Times (albeit not your division). The issues in online design are undoubtedly different – usability, accessibility, and so on.
I also think being inside the client or outside in an agency has a large influence on how much you consider the business impact of design – inside you will be directly subject to the ramifications of your decisions, and you will have the opportunity to get to grips with the guts of the company in a way an outsider probably won’t – that should mean insider design is more business-aware, offset perhaps by the fact that from inside, one misses out on the advantages of designing for many different clients and facing different problems, the solutions to which can cross-pollinate.
I think most clients have very valid reasons to go to a designer, and almost all rightly see value in what the designer will do for them – no-one wants to throw money away. But few companies see a value in design for its own sake, and they’re probably right.
Also, clients working with outside agencies, in my limited experience, don’t evaluate how much the decision to change or renew an identity will impact or cost beyond the figure on the bottom of the designer’s invoice – the tip of the iceberg. The real cost of a design overhaul is something they’ll face gradually as they begin to implement it, and it may anyway remain very hard to quantify. I don’t think most clients expect the designer to even consider ways of saving them money or streamlining their operations (and there are lots of ways of doing it), which is lucky, because a lot of designers don’t see it as their problem. And if this is the case, the client is right to only trust the designer so far – it’s damage limitation.
Getting back to the style manual, perhaps there are analogies with software products. If the techie mantra the world over is RTFM, it must say something about how much notice is paid of written documentation (printed or not). In the end, if someone sits down and explains or shows you how to do something and why, it sinks in faster and better. And that perhaps takes us back to the point about designing not alongside the marketing department, but alongside the real end users of the new identity. Make sure we’re paid enough to cover the on-site time it takes to do this, and tell them the manual will be 5 pages long and free – I suspect they’d be happier and the results would be more fruitful for both designer and client.
by the way, I just found this site which might be an interesting reference on the subject of print, pdf and online identity manuals: cidoc.net. Not much about wikis yet – keep them posted!
A question for you Khoi. I seem to remember reading somewhere that The New York Times newspaper has never used a styleguide. Do you know if this is true or false?
Hal: For some reason I have a feeling what you heard was that the Times editorial team does not use a style manual, which as you can see from this Amazon.com listing isn’t true. On the other hand, if you did hear a rumor with regard to no brand style manual in use at the paper, that’s not true either, though I can’t point you to an Amazon link to prove it.
In retrospect the comment may have only been in regards to the Times front page–perhaps that there is no set grid…
In any case, I’m very glad to see you bringing up the issue of design style manuals. I wholeheartedly agree with your point that these documents have become outmoded.
But perhaps there is more to this than just the manner in which we “document our design”? As you pointed out, design guidelines and manuals were a product of the Modernist program. As such, their purpose was not only aesthetic and utilitarian, but also ideological.
In other words, the value that we as designers now place on the importance of consistency, and “design integrity” are derivatives of the grander intentions of Modernism–the attempt to create a “universal” design language, etc.
My question is this: if we have abandoned the ideological program of Modernism, then why do we hold onto the aesthetic aspects? Or put more bluntly, is consistency necessarily a good thing?
Perhaps as the creators of “living systems” we need to reevaluate some of these ideas that we tend to take for granted?
Khoi, Thanks for both parts of this article. It was seeing photographs of corporate ID systems in design annuals as a child that made me want to become a graphic designer.
The fact of the matter is that in many organizations today, the distributed nature of publishing prevents the general effectiveness of such guides.
Both the guidelines and the logos for my organization’s identity are available through the institutions’ intranet, and yet the logo is constantly abused much to the organization’s detriment.
The availability of guidelines whether print or electronic are only a small check against squandering good design.
I am beginning to suspect that manuals are actually less important than a sound design philosophy and set of simple rules easily memorized by everybody from the shipping department to the corner office. These in turn founded on a deep committment from management to build and preserve the identity and depth of documentation for those who want to pursue more detail.
Designers need to consider that part of the design requirement may be to create brand marks and design elements that can be easily implemented by niave users without good tools and with no training.
Perhaps part of the new concept of ID manual is that the design itself is somehow instructive?
Thanks again for the article.
Jon
Hello Khoi. I am presently a design student in Canada and stumbled on to your site. In fact we are supposed to find a blog we like and follow it. I chose this blog for many reasons. The diverse amount of topics allows me to cruise one site and join in discussions amongst like minded people. It allows me to learn about many of the topics that interest me. You seem like a designer at the pulse of current events and trends who has a knowledgable point of view.
Also you seemed very approachable to this newbie designer/blogger. (this is my first post)
The design style guide topic interests me. Most of the graphic design programs touch on the need for ‘design style guides’ but by no means go into detail about what they contain.
It seems like the problem with the style guides may be that they are not reaching
the people that are implementing the design.
When creating an identity, should it not be part of the design contract to train the employees on the design guidelines and also make available to all new employees as a part of their orientation. (at a fee of course)
Jon Whipple’s post makes sense to me… “I am beginning to suspect that manuals are actually less important than a sound design philosophy and set of simple rules easily memorized by everybody from the shipping department to the corner office. These in turn founded on a deep committment from management to build and preserve the identity and depth of documentation for those who want to pursue more detail.”
But you guys are the experts. I’ll sit back and listen for now. Any good links to docs/contracts would be helpful too.
thanks, Michele
Yes, consistency is important, independent of any Modernist ideological programme. See Nielsen et al.
I would even say that to Nielsen, there is almost a universal design language, it is merely that it is defined in a different way from that of Kandinsky et al.
Also, who said we’d given up on Modernism?
Hal: Have we abandoned Modernism’s ideological program?
And, of course, the notions of consistency are not confined to Modernism as an ideology, and, in fact, are highly valued in UI design. (See practically any discussion of `brushed metal’, the `spatial’ Finder, and you’ll see consistency invoked).
UI designers don’t like consistency because of any ideological agenda; they like consistency because of the empirical benefits to the user, and often to the client.
Indeed, I would say that some of Nielsen’s work tends towards a notion of a `universal’ design language. Of course, his notion of universal is different from that of Kandinsky et al. For one thing, Nielsen’s universe consists of users, and preferably paying users.
Yes usability is important, but it is only one piece of the user-experience puzzle.
And in regards to Khoi’s point, I have no doubt that Wikis will be an improvement in the production of design style manuals.
But what of the content of style manuals? There are other questions to ask. How do we document surprise? How do we annotate delight? How do we index transformation?
These ideas–and others like them–are all critical aspects of the user-experience, but they are relatively new to us as designers. They are not part of tradition of style manuals.