Creativity is my trade as a designer. It thrives in moderate chaos; being overly organised kills my ability to think outside boxes and shift angles to come up with original solutions. “To think the unthinkable one’s mind needs to wander freely.” I know how that sounds, but it’s true nonetheless. I am blessed to work with people that make up for my lack of organization. Colleagues that have the patience to put up with my chaos and turn my designs into actual products. But in writing UI guidelines I’m on my own.
Although writing is in itself a creative process, you need to know what you want to say before you can start writing. Before I can write UI guidelines I need to analyse my own design process and decisions. It is sometimes a bit worrying that for some design decisions the only thing that seems to come to mind is “this solution just felt right to me.” Of course I can’t write that down. I have to backtrack my (mostly intuitive) design process to find out why I took those decisions. I have to turn intuition into reasoning.
Having written and contributed to multiple UI guidelines I found that sticking to these following 6 rules enables me to write a decent guideline, bypassing my lack of organizational skills.
- Design a guideline like you would design any other product.
A UI guideline is a utility; it is intended for a specific task and for a specific type of people. In order to know what to write and how to publish your writing, you first need to know who you are writing for and how these people will use your guideline. In that respect a guideline is not different from any other product I design. It helps a lot to involve the intended audience into your writing process. Ask them what they expect and need. Try to find out what they already know. Let them review and comment on your work.
- A guideline is never complete, so focus on doing enough.
You can go on forever in describing every little UI detail and the harmony of it all, but you have to stop at some point. It is a tricky balance: write too little and people will not have enough to hold on to, write too much and people will not be able to grasp the big picture or how to apply the separate parts. My advise is to start small, see how it is understood and applied and then add more if needed.
- A guideline is a living thing, facilitate the process.
New things will get added in the future, things will get changed. Common solutions today might be deprecated tomorrow. You need a solid process in writing and maintaining the guideline to keep ensuring it’s quality in the future. Make sure users can comment on (parts of) the guideline and suggest changes or additions. Keep users posted on new versions of the guideline and what has changed.
- Not just write the rules, but also the reasoning.
You can’t cover everything in a limited set of rules. You need to make your audience smart enough to come up with solutions for unforeseen situations. So back up every rule with design principles. These design principles are what connects your rules, patterns and elements with the product vision. Also: spending an hour or two face-to-face with your intended audience to explain the basic UI concept can be more effective than weeks of writing.
- Write guidelines while you are designing.
Design principles and patterns emerge during the process of designing a user interface, so you best frame them when you identify them. Framing design principles and patterns also helps you in designing a better, more coherent product, even if you are not intending to write actual guidelines for the product.
- Add examples. Lots of them.
Because examples really show how the separate parts of your guideline come together and make a user interface. It makes your guideline more accessible and if done right really proves the value of your design efforts. You could even add your own design files so they can be used as design templates to get people up and running fast.