Archive of UX Articles

When defining requirements, you always start in the context of a goal – either a user goal or a corporate goal.  You need to be aware of both.  Having a positive user experience is important, and requires a user-centered understanding.  Achieving your corporate goals might be in conflict with some user goals.

Read the rest of the article…

Blue Ocean Strategy provides an interesting reactive analysis of companies and markets.  Personas are used to understand your customer’s needs.  Combining the two provides powerful proactive insights when positioning your product for market success.

Read the rest of the article…

Netlife Research brings us the 2009 Bad Usability calendar.  Get it while it’s hot.

Learning how to write use cases can be tough, but it is simple compared to the balancing act of determining which use cases to write and how to manage the expectations of all the stakeholders that are involved. It can be a difficult balancing act to prioritize use cases to assure that you meet the goals of the business while satisfying the needs of the users.

Netlife Research (company website in Norwegian) has done it again. Their 2008 Bad Usability Calendar is here and it is great. So great that it is hard to pick a favorite. Download it here. 2007 has more great examples.

[Note: This is a short post- just got back from the Velvet Revolver concert at Stubb's. Living in Austin rocks!]

You want your software to be used, not to sit on the shelf. You can’t achieve the ROI of your software if people don’t use it. And you can’t achieve the ROI of your software by forcing people to use it either.  Some will fail to achieve the benefits, and others will delay using it or refuse to use it entirely.  You have to make them want to use it, and you have to design the software for the users who must use it.  Otherwise, you won’t achieve the ROI.

No matter how good your quality process is, you are introducing bugs. This article reviews the places where bugs are introduced in the software development process (from stakeholders to users), and reviews ways to address those bugs.

We use actor hierarchies to organize the different users of a system. Different people play different roles, and thus do different jobs. We use different actors to identify and organize those people. When deploying a system globally, we usually discover people that do the same jobs, but do them differently. Incorporating the notion of personas lets us deal with this.

A couple weeks ago we wrote about Outside-in Software Development, by Carl Kessler and John Sweitzer. One of their ideas about stakeholders and goals has got us thinking about traceability.

A heuristic evaluation (or heuristic analysis) is a quick, low-cost usability analysis of the design of a user interface. Pareto’s rule tells us that we can get 80% of the results from 20% of the effort. And that’s where discount usability tests like a heuristic evaluation come in to play. Formal, and more detailed usability studies yield better results – but cost more and take more time. A small investment can pay off big with a heuristic evaluation.