Tag Archives: information architecture

30 important usability issues, terms, rules and principles which are usually forgotten, ignored or misunderstood.

That is probably the best long title ever. But usability is critical to success and smashingmagazine.com has put together one of the best one (scrolling) page overview of usability.

If you are new to usability, this is a great resource. If you are a practitioner, then it’s a fine reference page.

“In this article we present 30 important usability issues, terms, rules and principles which are usually forgotten, ignored or misunderstood. What is the difference between readability and legibility? What exactly does 80/20 or Pareto principle mean? What is meant with minesweeping and satisficing? And what is Progressive Enhancement and Graceful Degradation? OK, it’s time to dive in.”

>>Here’s the highly-usable link<<

Advertisements

6 Metrics for Managing UI Design (Russell Wilson)

Russel Wilson has written some very good guidelines that begin to address the question, What are the success metrics? I have managed and lead several large Digital Creative groups and this is ALWAYS a thorny issue. This is very helpful:

Full Article here.

“As part of a recent management summit at my company, we were asked to fill out an RMPT matrix for our departments (I head up Product Design).  An RMPT matrix consists of (R)esponsibilities, (M)etrics, (P)rocesses, and (T)ools.  I have been intending to develop better metrics for both measuring and guiding our design efforts, and this exercise served as a catalyst to get me started.  Bear in mind that metrics help you focus your efforts and measure your progress, but you are also held accountable to them.

For (R)esponsibilities I specified the following:
1) Improve our products & innovate
2) Provide the UI design for new features/functions/products
3) Approve any UI design work done outside of Product Design
4) Validate our UI designs and explore user needs through user testing

Given those responsibilities (and that’s important because your metrics are linked to them) I then came up with the following metrics and met with my team who helped to refine them:

For a given period (e.g. a business quarter):
1) Number of layouts delivered
2) Number of interactive prototypes created
3) Percentage of product design requests completed by commit date
4) Number of users tested
5) Number of product improvements made
6) Number of product insights documented