Usability / UI Design / UX, etc. - documenting for a project

Question

Hi all,

I'm a software developer, and I'm going onto a project now that involves implementing a website using ASP.NET (3.5 / 2008, using the Web Client Software Factory). I've been tasked at creating a UI / UX Design Document for the project, however I don't really know where to start.

I've been on one project in 3 years where there was a formal UI design document, which included layout and style guidelines/rules (e.g. the application has a header, navigation, etc., links must be colour A, buttons for positive actions must be on the right, etc. etc.). It was pretty useful in hindsight, I appreciated that someone went into that much effort too - even defining the CSS classes in the document. However, the doc was based on an existing application and conformed to the business' overall corporate identity.

The current project is a new project, which at the moment doesn't have clearly defined requirements (yes, I know... how do you design when there aren't many requirements... I digress). It is hard to know what functionality exactly will be needed. There are two different user types / personas, but no formal research will be performed on them for this document. Also, I'm not sure of the corporate identity, apart from that the business has some rules regarding use of their logo, which I'll only get further clarification on in a few days time.

So I'm slightly in the dark, throwing paint at a canvas, hoping I get a pretty picture at the end (if only I were Jackson Pollock).

What would you include in this document? It is aimed at the business (the client), as well as the developers. I can think of only the below:

1. Layout - header, footer, content, navigation
2. Styles - colour palette and styles of the different expected components
3. User Interactions - when a user performs an action and must wait they are notified by a modal dialog, validation is done using AJAX, navigation should be contextual, tasks should be performed with a minimum amount of clicking / navigation, etc. etc.

Has anyone got any experience in creating such a document, or any known, tried and tested process for UI design?

Thanks,

James

Answer 1

The Wikipedia article for Human Interface Guidlines has some great links that I was going to suggest. Some of them may have far more information than you require, but they should give you a good idea as to what types of things you should add.

I have always found Apple's guidelines very complete and useful, but they are definitely very complete and require a lot of reading.

Answer 2

There' all sorts of elements that could be included in such a set of documentation:

• visual style guidelines (colors, typefaces, sizes, icons, etc)
• branding guidelines (corporate logos, colors, messaging, etc.)
• copyrighting style guide (terminology, proper messaging, proper voice, etc.)
• persona/demographic targetting
• page layout guidelines
• CSS guidelines/standards
• JS guidelines/standards
• use cases
• accessibility issues
• usability issues
• example implementations
• IA path flows
• Wireframe components
• etc.

I'd pick up this book if you can to give you a start on thinking about this:

http://www.amazon.com/Web-Anatomy-Interaction-Frameworks-ebook/dp/B002ZY5FCW/ref=sr_1_2?ie=UTF8&s=books&qid=1262983955&sr=8-2

Answer 3

Along with all the other obvious components of your planning document, it would be a good idea to sketch portions of the UI along with an accompanying narrative of the specific use cases illustrated.

I've had issues in the past when attempting to communicate UI ideas. It is often useful to make sketches of dialog boxes and sequences of actions. If those sketches look too "real", then there is a tendency for them to become the spec for the final product.

To mitigate this, I've been playing with Balsamiq Mockups. It has the nice property that it is an editable back of a napkin, and deliberately renders all objects and screen layouts with a hand-drawn feel. I like the results I've achieved with it for small, internal projects. I haven't (yet) had the chance to use it for a large project with many external stakeholders.