This was one of my favorite sessions from this years IA Summit. Dan Brown (twitter) delivered a very thorough and practical guide on how to develop and use design rules for a project. The following are my tweets from the session:

Design Rules are not commandments, but rules about recommendations and what gets recommended.

What is a rule? It is how a screen changes for different circumstances.

Rules come up as needed to full in the holes in a particular UX.

Rules are not recipes, they don’t provide steps to follow in order to accomplish something.

A rule is like an editor, that crafts the message out of a pile of footage.

An IA needs to take rule world content and fit them into a defined digital system.

A machine will make the decision about what content gets displayed, but we need to give the machine a clear set of guidelines.

Faceted based navigation follows the same rules between overall categories, even though the content is different.

Based on user selections the path they follow changes based on the business rules behind it.

Rules are not patterns, at least not how we define patterns.

There are patterns of rules that can be used in order to make a service/product successful.

You need to be able to take a pattern and define the rules necessary to be able to use that pattern successfully.

IA is a web site’s ‘language’, rules use that language in order to manufacture a user experience.

Content rules develop the pool of all the content that can be displayed.

Filters take the pool and decide the exact pieces of content that get chosen to be displayed

If the filter rules fail, have a fall back default that the system can use.

The effect of the rules need to be displayed to the user when they are invoked. I think of the Kayak.com filters with this.

Using pseudo-code as annotations is a method that can be understand by both business and technical team members.

Wireframes can also display what the content, scope, filters, and format will end up looking like.

What makes a good rule? #1 Those that are User-Centered. Getting a recommendations on stuff you care about.

Rules are unambiguous, they need to be clear about the choices that come out of them.

Rules need to be feasible, if you are not collecting the information you want to display, then the rule isn’t feasible.

The responsibility of the rule needs to be specified, is it a human or a machine making the decision?

Rules need to be able to degrade gracefully, this is where a set of defaults come into play.

We need to take our rules seriously, they govern how our products behave in front of our customers.

How are the rules documented to ensure that people follow them when implementing a product?

Creating documentation that is readable, informative, and fun is a big part of getting the rules implemented correctly.

Is it better to have a stakeholder to enforce the rules, or have an authoritative figure to enforce the rules.

Part of the feasibility of a rule is if it can be enforced or not, regardless if it is a human or machine that manage the rule

What happens if you use the rules to reverse engineer the IA from the desired rules?

It is easy to get caught up in the details of what we do, In the end we need to start with the UX and have that drive the rule

This session was great because it highlights a step in the process that happens regardless if the designer purposely defines the rules. By pointing out the importance of using Design Rules, a designer can focus on ensuring that the rules that get put into place enhance the overall user experience. This is definitely something I hope to incorporate in my own personal design process going forward.

Designing Rules ~ IA Summit 2009

View more presentations from Daniel Brown.