Making Offshore Design Work

Posted on:

When companies first start off-shoring, they usually send the “low level” implementation work overseas first, to work out the process kinks and manage risk. Over time, your valued, domain-aware developers will perceive a lack of career opportunities with this limited role. Naturally, you will want to consider sending design work […]

Measuring the ROI of Design

Posted on:

Measuring the return on investments in design may be the hardest ROI calculation you can do. It certainly is one of the rarest. To measure ROI, you have to be able to determine what would happen without the investment, and what happens with the investment. The difference between them is […]

APR: Information Architecture – Faceted Navigation

Posted on:

In our previous article in the series on the development of nexus, we discussed navigation and information architecture. We identified the challenge of filtering articles by category and by level of experience (beginner / expert), while also viewing the articles along a characteristic (most-viewed, highest-rated, etc). Between both url-creation and […]

APR: Thoughts on Ratings

Posted on:

Our agile project is to create a site that lets you rate articles. In our corporate goals, we defined the goal to make it easier for people to find and read great content. Last night I was doing some research on social networks and thinking about the nature of our […]

Don’t Make Your Products Too Simple

Posted on:

Joshua Ledwell wrote a short article expressing his perspective on designing software that is neither too simple nor too complex. He also links to some excellent other articles on the topic.

Goal Driven Upgrades

Posted on:

Kathy Sierra writes (another) great article at Creating Passionate Users. This time, she talks about why users don’t upgrade and presents ways to get users to install the latest version. We focus in this article on one way in particular – using goal-driven documentation to encourage upgrading.

Use Case Driven Documentation

Posted on:

Yesterday we wrote about focusing our documentation on what our users are trying to accomplish. With a structured requirements approach, or with an interaction-design driven approach, we’ve already solved half the problem – determining what to document.