Interface Design Principles

Administrator — Tue, 08 Jan 2008 21:41:15 +0000

Good user interface design is mischievously hard. “Simplicity” is the fad these days, thanks to Apple and indie software teams such as 37signals. But simplicity follows complexity, and wading through complexity requires separating vital things from everything else. Do you think that it’s easy to identify important ideas and fastidiously adhere to them? Stop smoking. Don’t lust. Call your mother daily. Don’t be mean. Simple doesn’t mean easy.

Here are several principles that have emerged from my reading over the last few weeks. Remember that methodologies only supply the raw material for good design: feature sets, response requirements, accessibility needs, etc. Making a design come together requires practice, taste, and a little luck.

Form follows function-Good interfaces result from a comprehensive understanding of the user’s objectives. Paradoxically, the user often does not know his objective, especially in a new, “brand-defining” design. This is a historical critique of usage-centered design. Developers will use an activity-based approach to design.
Maximize Server-side transclusion-The developer can significantly alter page content and layout during the server-side, pre-render process. Content pages and the QueryString are two common ways of adding parameterized content to generic pages. Shared content pages between sites facilitate both code reuse and a seamless user experience.
Keep it simple (to an extent)-Screens should not be “busy” or contain “fluff.” These are qualitative descriptions of elusive aesthetic end products. Good interfaces contain just enough detail, but not more. At the same time, extensive detail may at times be required (for example, on an administrative configuration panel). The developer should use intuition as a guide and always pity the user.
Use “accelerators”-As his proficiency increases, a user may want to access certain functions and information outside of the normal task flow (keyboard shortcuts are an obvious example). Developers can hide detail behind context sensitive displays and menus or provide deep linking into alternate work flows (for example, going from a performance graph to work scheduling). Think EMACS.
Adhere to W3C standards-IE6 is a recent tragedy for which IE7 has not atoned. Although a requirement does not currently exist for cross-browser support, the user will eventually appreciate a compliant interface. Therefore, the development model should be “test in Firefox, hack for IE.”
Accommodate the evolving user-The user’s objectives and information needs will evolve over FSS’s lifecycle. Developers should fastidiously separate data from presentation. In ASP.NET, for example, GridView control may be attached to a data source. The data source “shapes” Tier 2 information into an ADO.NET structure, which is then styled by the GridView declarative syntax.

Reflections on Interface Design

Administrator — Fri, 14 Dec 2007 15:03:28 +0000

Like many programmers, I have long considered interface design an artistic activity best reserved for aesthetes who cannot design sort functions. One of my working software theories has been, “Programmers don’t design interfaces. Interface designers design interfaces.” My recent foray into graphical design has caused me to revise this axiom: “Programmers can design interfaces if they study interface design.” This is where I found myself several weeks ago.

During the first week of my research, I petitioned my manager for access to “the User.” After all, “enlightened” interface design teams pity the user, right? Not always. I spent several days building prototype screens and realized that not only did I not understand the user, but also that the user did not understand himself. My current project is a new system that will require new processes, training procedures, and internal organizations. Staffing needs are uncertain. Roles are uncertain. Even the system’s features are fluid. Therefore, “the User” does not yet exist. It occured to me that “Usage-centered design” fails in such a scenario, as observed by Don Norman:

The historical record contains numerous examples of successful devices that required people to adapt to and learn the devices. People were expected to acquire a good understanding of the activities to be performed and of the operation of the technology. None of this “tools adapt to the people” nonsense — people adapt to the tools.

Think about that last point. A fundamental corollary to the principle of Human-Centered Design has always been that technology should adapt to people, not people to the technology. Is this really true?

Frustrated, I called a friend who currently studies design under Norman at Northwestern. As with most leaps into new technical fields, I found that the conventional knowledge was about a decade out of date (a revelation consistent with Steve McConnell’s assertion that software ideas take 10 years or more to percolate from academia to industry). “Activity-based” design is the new model. Activities are user objectives that consist of tasks, which are user actions. Discovering activities and tasks yields insight into the user’s ultimate goals. Good interfaces result from a comprehensive understanding of these goals.

Whether “activity-based” design will survive The Next Big Thing remains unclear. The approach has intuitive merits, for Norman rightly observes that useful tools like pens and musical instruments require educating the user. One can hardly imagine that Les Paul held user forums while developing the electric guitar (possible questionnaire: “Does this device help you shred more?”). At the same time, the concept of activities and tasks falls squarely into the faddish realm of process thinking characterized Enterprise Architecture, ERP systems, and BPM. But a processes are like algorithms, which have been studied for millenia. The salient insight is that most people don’t think in terms of algorithms, but most useful activities require them. With only a hint of elitism, I therefore suggest that interface designers first try to clearly state what needs to be done, approaching the user after the heavy intellectual lifting has been accomplished.

Interface Design Tools that I’m using now:
NickFinck wireframe stencils
UML2.0 stencils
Dimensioning stencils
The Gimp

spencegreen.com » Design

Interface Design Principles

Reflections on Interface Design