Software is not just a tool, a way to automate work that used to be done manually (ie. calculator, word processor, electronic mail). For a lot of people, the pain of investment required to set up automation just isn't worth it. (ie. task lists, mail filters)

How can we make software useful for everyone. How can software transcend automation?

Software complements the human brain.

Software is the tangible instantiation of ideas and concepts.

Software should be a system, meaning it should have built-in feedback loops, help users answer questions, set users up to enter and manage information in such a way that they actually gain insight into their lives.

An email client isn't just a mailbox for receiving and sending messages. It should be an active system that actually improves inter-personal communications and faciliates a deeper understanding of the information that is flying back and forth.

---

Balancing generic and simple with clear and usable.

In the physical world, when things are specific, you know what to do with them. When they're not, you're at a lost. Push and pull affordances. Generic Lego blocks v. pre-fab Legos with pieces for Bathroom, Bedroom, Kitchen, LR, DR, etc.

This requires understanding the fundamental building blocks of how human beings structure information, which is always going to be one or two levels more specific than the way computers need to structure information.

Figure out the grammar of human knowledge in order to come up with an information architecture that complements the way we conceptualize information.

Figure out the questions people are struggling to answer with their information? aka Identifying use cases. But this is not limited to what people already try to do with software today. Instead, what are people trying to do with information they have today? What are the problems they run up against.

Identifying more than just feature needs, but user goals, workflows and mental constructs. (ie. I want to be able to color code my messages v. I need a better way to set and keep track of my priorities so I don't lose sight of the things that are really important to me.)

Does the implementation model necessarily need to mirror the user mental model?

For example: Differentiating between Read and Unread email is a feature that maps closely to the technology: Either an email has been clicked on and viewed in the preview pane or it hasn't. So, even if the user has the preview pane completely minimized, the client marks the email as Read. Even if the preview pane is only 50 pixels high and the user can only see the message header, the message is marked as Read.

Our user-centered way to model message status is to introduce an orthogonal attribute: triage status as a way for users to explicitly assign message status:

Now, Done and Later in combination with Read and Unread:

• Unread and Now: never looked at
• Read and Now: glanced at, but still needs more reading
• Unread and Later: never looked at, need to deal with later
• Read and Later: glaced at, but still needs more reading later
• Unread and Done: don't care about
• Read and Done: done with

A more literal interpretation of this might have been to simply add more options to the Read, Unread message status attribute: Unread, Glanced at, Need to read some more, Read. However, this wouldn't have actually solved the user's problem of needing to not only differentiate between all the various stages of message digestion, but also whether they want to continue dealing with the message Now or Later. It would have also added a lot of cruft to the user experience that really only applied to email, whereas the notion of triage status is universal and applies to information items of all kinds.

Our goal is to not only to figure out how users think but to identify patterns in user constructs across all workflows such that the user experience consists of only a few simply concepts.

The measure of success for any design is: what is the ratio of use cases solved to features added How many use cases does triage status solve?

---

Methodology

Observing the way people already work.

Interviewing people and listening carefully to the way they talk about the information in their lives. What words and concepts do they use. What parts of speech do they use to describe certain things.

For example, people often describe their projects as being either a conceptual portion of some oganizational goal (ie. marketing campaign), a person (ie. a manager or someone you manage) or a phase of a project (ie. R&D).

People almost always describe an action in conjunction with information types (ie. Scheduling on my calendar.)

People need something more than just Todo and Done. They need to be able to Defer things to be done later.

Simplifying the various notions of status into a single scheme.

Coming up with a grammar with which to model the different ways people categorize and group things: Kinds v. Projects v. Status

Coming up with a communications structure: capital N v. lower-case n notifications. Distinguishing between people who Need to know v. Good to know v. Only if you want to know. etc.

Using Email as a Verb rather than as a noun.

Unifying different notions of communication: Email v. Item sharing v. IM v. IRC

Unifying different notions of syndication: mailing lists v. RSS v. newsletters

Modeling the world in a user-centered way as opposed to a technology-centered way.

Once you understand the basic grammar and how the language of human knowledge is structured, then you figure out how to best convey that structure in the UI with clear visual and interaction semantics.