Hierarchy 1 of 3: The Information Hierarchy

People naturally categorise to make information more manageable.

Use a hierarchy to help people choose where to direct their attention - and how deep they want to go. An effective information hierarchy helps people know where to find things, and also what kinds of things there are to find.

Myth: "Users Will Only Make That Mistake Once"

Along with "We'll fix it in training", this is one of the laziest and most commonly employed excuses for an inadequate design.

In order to avoid the mistake next time, users must make an investment of cognitive effort. If the interaction can't be made simpler, at least be sure that this investment yields some net return, somewhere - such as improved task efficiency for the majority of users.

Interleave mundane tasks with creative and thinking tasks

There are a lot of procedural things that - as designers - we need to do.  Rippling main nav changes from one mock-up through all the other mock-ups, updating the design wall, compiling notes from the last user session etc.  Sprinkling these comparatively mundane tasks through the more creative or heavy thinking tasks (like say analysing findings and synthesising research results or mocking up a particularly tricky interaction challenge) helps to break up the load and reduce the chance of burning out before you reach the right answer.

Sometimes the answer comes more quickly when we stop thinking about the problem.

All the better if the procedural work engages manual dexterity.  Sticking the labels on cards for a card sort is a good example.

Of course, if you are in "the zone" on a design, nothing (except for perhaps an iPhone OS update) should shake from that zen-like state of enhanced creative productivity.

Landmarks help us know where we are going, and where we have been

When we explore a new city, landmarks break our journey into stages. At each landmark we stop, assess where we’ve been, reorient ourselves, and set out again.

Landmarks can help with any journey. On a web site, arriving at a page that is markedly different to others marks the end of a stage of the interaction, or the beginning of a new stage.

Memorable landmarks that stand out from their surrounds help us form a mental model of where we have been, and where else we can go.

Like buildings, applications break at the joins

It’s the journey between pages or screens, not the pages and screens themselves, that can cause the most problems for users. Plus - problems with the journey are the most expensive problems to fix.

Design the journey between states first, before designing the states.

Inspired by a suggestion from Dave Malouf (http://davemalouf.com/).

Balancing being right and being employed...

...can be a challenge.

Remember that - with perseverance - you can communicate the former by following the path of the latter.

To go the other way requires significant chutzpah and often leaves casualties in its wake.

Consider Content and Data from the Outset

When designing wireframes, content place-holders are good. However, displaying actual sample content and data  (de-identified if necessary) is always better. This gives an idea of how elements on the page blend with each other and "calls to action" can be placed appropriately. Take into account which content goes where and how much will appear. Don't leave content until the end, it does have implications for your design and layout.

Suggested by Isaac Sane http://force10x.com/blog/

Developer: "The worst part about designers is..."

"...that with a wave of their hand, they create hundreds of lines of code!"

The strategic design decisions that we make on a daily basis often have a significant effect on the amount of work that a developer needs to perform in order to realise the vision.  On projects where the requirements and design are completed before development starts, the effect of this is obscured from the developer's view and expectations are more easily managed.  However in more agile environments - where the design may be shifting while coding is happening - we need to be mindful that seemingly minor changes may have significant consequences.  This can upset the delicate balance of power that is shared between designer and developer.  Be aware of this and always act with humility and delicacy in such situations.

Be wary of projects with ill-defined scope

It could be argued that it is often our job to define scope.  Certainly, our efforts call into question elements of scope at times and our recommendations can help to tighten the focus on scope. Regardless, a project with ill-defined scope should ring loud alarm bells for the eager interaction designer.  If a client can't tell you what the strategic purpose of the solution is or how it will affect a business or user outcome, it is very difficult to know when you have finished doing your job as a User Experience practitioner. Seek an articulation of scope early. If it doesn't exist, be a part of creating it.

Play to your strengths and team up with complementary players

Designers come in many shades but it is pretty (in fact extremely) rare that they cover all 3 pillars required by most large projects:
- Behavioral
- Visual, and
- Technical
Understand which point(s) you are able to cover best and team up with talented people who shine in the other points.  Knowing where your abilities end and another's begin allows you to relinquish responsibility for things that you may not have had ultimate control over anyway.

People are good at recognising shapes

People generally identify shape outlines before they identify the detail within. Icons with different outline shapes will be quicker to tell apart than icons with the same outline shape.

Separation of action and reaction

The greater the distance between a user’s action and the system’s reaction, the more you need to emphasise the relationship between the action and the reaction.

Distance can be measured in space, or in time.

Play tricks, don't wait for a full-house

Deciding when your design is mature enough to put in front of a client is always difficult.  Unfortunately, there is a natural tendency to err on the side of holding off for longer than we should.
All other things being equal, you should expose your design earlier rather than later - in fact, earlier than you feel comfortable with.
Even if you have problems with aspects of the design, it is better to bring your stakeholders over to your side of the problem sooner.
To use an analogy from card games; play your design out in small "tricks" don't wait for a "full house", lest you be left with a hand full of great - but now useless - cards when the project moves on without you.

Butcher's paper is your friend

Lay it around your desk as you work.  Take notes, draw little diagrams.  Draw screen mock-ups.  Pin them on the wall.  They won't get lost like pages in your notebook if they are visible in your workplace.  Additionally, your process and progress will be visible to other teams.

Find a pen that you love drawing and writing with

A beautiful, well weighted pen that makes your sketches and scratchings look like the kind of thing found in the notepads of architects (rather than on the walls of a Mexican prison) is an inspiring tool to have in your kit-bag.

In addition to drawing envious glances from clients and designers alike, it will increase your desire to sketch and take notes.

Getting the pen moving early and freely circumvents one of the biggest barriers to completing a design... starting.

Fluffy clouds are your friends

In early iterations of the design, it is better to get a breadth-pass than to get bogged down in the depth of one particular detail.  Use fluffy clouds - unashamedly - to communicate that you simply don't know what will appear in that part of the design yet.  Better this approach than detailing an ill-thought out guess which might cause the kernel of a good idea to be tossed into the chaff-pile by a stakeholder with a critical eye for detail.

In times of trouble, ask "What is the user problem that we are trying to solve?"

Emphasis here on "...PROBLEM WE ARE TRYING TO SOLVE".  We easily get caught up in fitting buttons and fields on screens etc.  But often - even after requirements have been detailed - we loose sight of the fact that we are trying to solve business and human problems with the functions and information that we are designing.  Asking this question helps reorient the project back toward what is important. When elevated to a mantra, other teams on the project start asking the question and you know an attitude change has been affected.

Functionality is the enemy of usability

When you are handed a functional specification, it is easy to take it on face value, and then work hard to make that functionality as usable as possible. If you are really focussed on usability, then your job starts with critiquing the functionality itself.

Your design isn't finished until you can't take anything else away

...without sacrificing user or business needs

Similarity implies relationship

Visual designers tell us to use as few colours as possible (especially if we are novice designers). That may mean we apply the same colour to two (or more) items on a screen. Be careful, though, that the similar colour (or other treatment) does not imply a relationship you do not intend.

The level of detail in your mock-ups should reflect the level of confidence in your design

Mock-ups are prepared as a way of exploring a particular design problem, and in order to communicate your thoughts on a solution to important stakeholders (i.e. users, clients or developers).
In the early stages of design, mock-ups should communicate broad concepts and groupings of information or functions.  Keeping the details scant at these early stages allows you to progress through iterations quickly and keeps your stakeholders from throwing the baby out with the bath-water by quibbling over colours and button placement.
As you progress towards a final design, mock-ups should be rendered in increasingly higher fidelity so that the full detail of your approach is exposed.