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.