Russ / all, Unfortunately, I have no data I can share publicly on this subject. But I can share some lessons I've learned while building guidelines and leading teams that produced and consumed guidelines.
1. Treat design guidelines as a design problem in and of itself. Make the guidelines findable, learnable, usable (and memorable) for the intended consumers. This means you need to understand your users' needs. Some questions to ask yourself and your team are: - Do they need to know the *why* behind the guidelines, or do they just need to know *how* to be compliant? - Consider whether they (and therefore you) are constrained by the UI toolkit and available controls. That is, do they need implementation-specific guidelines? This is more typical for platform-specific software and certain web-delivered apps. Or do you have degrees of freedom more typical of web-based apps? 2. Make sure people can quickly and easily access the digital assets they'll need to successfully implement the guidelines. Provide links to the assets (i.e., images, controls, CSS, code snippets, etc.) that will help designers and devs to implement the guidelines. Put the relevant links as close as possible to the guideline. Basically, put on your Tufte hat. (What can I say, I'm almost done with "Beautiful Evidence" so I'm looking at everything through Tuftian lenses right now.) 3. Make it so people can discuss and annotate the guidelines. Also, it's constructive when the community can submit examples of how they've implemented or adapted guidelines. At some point you may find it useful to convert a community submission into a full guideline. 4. Examples examples examples. (And more examples.) It's often helpful to mock up one of your organization's existing applications to illustrate one or more guidelines. If nothing else, the team can then practice "cargo cult design" and just emulate your example. 5. Socialize the guidelines...but also socialize a release plan for future guideline changes. Design and dev teams absolutely hate to find out that they've complied with R1.0 of the guidelines, but you've rev'ed them to R1.1 or 2.0. If you're making changes to the guidelines, make sure people know *when* the changes will be rolled out. And of course provide as many sneak peaks as you can. 6. Make sure that you coordinate with the folks who own the visual aspects of your organization's brand. A little synergy here goes a long way. And they're usually a great source of brand digital assets. I'm sure others on the list have many other suggestions. IMO, M2c, YMMV, etc. -Paul - - - - - - - Paul Sherman, Principal, ShermanUX User Experience Research | Design | Strategy [email protected] www.ShermanUX.com +1.512.917.1942 - - - - - - - On Jan 7, 2010, at 9:19 AM, Russell Wilson wrote: I'd like to get people's opinions on the value of "company-wide" design guidelines (for software applications/websites)? In theory, design guidelines could help to remove design bottlenecks by empowering others to create and apply the guidelines... but in reality they can also be hard to implement, confusing, restrictive, etc. Is there any data on the successful use of design guidelines by non-designers? Are there better alternatives? Thx, Russ -------- Russell Wilson Vice President of User Experience, CA Blog: dexodesign.com, uitrends.com LinkedIn: http://www.linkedin.com/in/russwilson ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [email protected] Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [email protected] Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
