Archive of Interaction design Articles

There are 15 ways for someone to shutdown a laptop running Windows Vista. This adds unwarranted complexity to our software. How can we avoid the same problem in our software?

Johanna Rothman just wrote an article titled Implicit Requirements are Still Requirements. She points out that her expectations were not met, even though her needs might have been. Johanna also implicitly begs the question – how do we gather implicit requirement?

Michael Shrivathsan just wrote an article presenting five tips for creating products with great design.
Michael’s List

Start with the user interface. [Roger Cauvin adds, start with a working first iteration]
Work closely with UI designers.
Pay attention to details.
Simpler is better.
Be brave.

Our Thoughts
User centric design is the core of UX and interaction design. It is the most [...]

Mike Mace provides us with some great insight about market research – helping us to avoid ‘the blender’ and ‘the gap’. The gap is a reflection of the inability of most customers to innovate. The blender is the loss of useful market information into a homogenized input that pushes only the lowest common denominator – again stifling innovation. We have to avoid the blender and the gap to get useful data from our research.

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.

One of the ten big rules of writing a good MRD is writing valuable requirements. How do we determine what requirements are valuable? To whom are they valuable? When a requirement represents a continuum how much is enough? What is too fast, what is too scalable? To whom must the requirement be valuable?

How do we find out what someone wants when they don’t know what they want or what they can have? One of the best techniques for gathering requirements is to interview users. But which users?

Imagine aliens came to the planet and offered to solve our gasoline problem. How could we tell them what we wanted? We might say we wanted cars that run on clean renewable energy. The aliens might leave thinking “Oh well, I guess they didn’t want faster-than-light travel.”

Gartner has a research report available for $95, titled Agile Requirements Definition and Management Will Benefit Application Development (report #G00126310 Apr 2005). The report is 7 pages long and makes an interesting read. Gartner makes a set of predictions for 2009 about requirements definition and management (RDM) systems, and the software created with RDM tools. Gartner misattributes several benefits of good process to RDM tools. We give them a 3.5/7 for their analysis – check out the details here.

Different people approach the same goal very differently. When we don’t truly identify our users, we end up with software that dehumanizes, waters-down, and otherwise fails to succeed at anything more than grudgingly tolerated functionality. Even worse, we may ignore the needs of our key demographic, resulting in software failure. When we use personas instead of generic use cases, we can avoid both the misery of a failed product and mediocrity of marginal success.

Microsoft Office 2007 has a completely new user interaction paradigm.

The old interfaces for Microsoft Office 2003 (and earlier) organized the menu structures around features or capabilities. Each grouping represented tasks that appeared to be related in functionality. This, unfortunately, doesn’t help the user very much. The new interface is very task based, and organizes capabilities based upon the task the user is currently performing. What the Office team has done is innovate. And the innovations differentiate them from every other business application I’ve ever seen.