I have to think much harder when I design rich interfaces than when I work on standard Web applicaitons. With the increased flexibility and more components comes a higher risk of making silly mistakes. If I use a component inappropriately, users can't figure out what to do, even though the components may look cool.
For UX designers, some of the most exciting projects to work on are new-to-the-world or breakthrough products that solve real problems people didn't even realize they had. Get them right and they may be hugely successful in the marketplace, but they're also the riskiest projects. While user-centered design (UCD) techniques can sometimes be valuable on new-product projects, more often, they don't seem to work particularly well when designing breakthrough products. Here are some lessons I've learned from my own work on new-product projects.
It's not that people resist change whole-scale. They just hate losing control and feeling stupid. When we make critical changes, we risk putting our users in that position. We must take care to ensure that we've considered the process of change as much as we've considered the technology changes themselves. Only then will we end up with changes that our users embrace.
Whenever we design something, we confront the problem of how to account for differences in our audience's needs, skills, and background. We accept that audiences are diverse and include people with widely varying skill levels, physical abilities, background knowledge, and cultural differences. They range from power users--who could teach us something about the product--to the greenest of neophytes. Some have significant visual or other limitations. Some can understand the most abstract concepts, whereas others wouldn't recognize a metaphor if it bit them. And some come from very different cultures, such as the gap that divides Macintosh and Windows users. Unfortunately, our knowledge of the more obvious differences sometimes leads us to make ridiculous assumptions, such as considering women and men to be different audiences, or believing that it's impossible to produce something that works equally well for experienced and new users.
As with other interactive media, touch-screen kiosks are designed for many different types of uses - from art piece installations to bus timetables and just about everything in between. But the practice of design for such kiosks demonstrates the importance of understanding hardware considerations and restraints before embarking on interface development. There are aspects to touch-screen technology that make their design fundamentally different to that of desktop applications. Most of these differences revolve around the nature of the input or controlling device. Touch screen kiosks are controlled directly by the user's finger whereas desktop applications are controlled remotely by devices like a mouse or keyboard. Users' fingers and hands vary in size and shape unlike a mouse cursor that stays more or less the same size from machine to machine. This is the primary consideration for design. For the purposes of this article we will concentrate on the touch-screen and the users' interaction with the content of the kiosk. Issues as to the design and usability of the kiosk's hardware or casing (such as height and location) will not be addressed. Before the designer can begin to think what the user might want in terms of content there are more basic concerns.
Over the past few years, I have come to appreciate the power patterns have as a shorthand that lets software engineers communicate their design intentions. Being able to discuss an Observer or Factory pattern with other engineers quickly moves the design discussion to more substantive concerns.
When forms give users the option to continue in two or more alternative directions, such as registering as a new customer or signing in as a returning one, unfortunate users will take the wrong turn if it isn't unmistakably obvious which way they should go. In this article, we'll take a look at a few intersection flows that have caused users problems.
Designing a user interface using minimalist principles for guided exploration can reduce the amount of paper and text necessary to document the system. Graphics in the interface can help the user grasp the concepts of the system, while dialog boxes, status information, and error messages can aid in recognition of success and recovery from errors. Online help can then be used as a backup for users if they get stuck. Reducing text and paper can reduce translation and printing costs, making this process very attractive.
Most companies are moving quickly beyond their local market to succeed on a large global market. Companies are developing mass market products instead of products for a single customer. All this poises new challenges to everyone in the company. This panel will address the following.
Many web sites and applications include a search feature. Often they provide an extremely simple search interface consisting of a single text box and a "Go" button. Sometimes, however, the users' tasks call for more sophistication, and guidelines for complex search interfaces are difficult to find. This paper details four levels of search interface, and it provides heuristics (guidelines) to use when designing complex search interfaces. Different solutions are appropriate, depending on the users' motivation and knowledge of their subject, experience using search interfaces, and search goals. Finally, PubMed serves as a useful example to illustrate how these guidelines can be used to analyze existing search interfaces.
Interfaces are more than skin deep. To create a successful electronic documentation project the structure of the information, the navigation and the visual design must all work together. Research Publications' American Journey series of CD-ROMs on topics in American history is a good example of an interface designed from the inside out.
In the discussion of interface components we sometimes found it difficult to keep logical interface components separate from toolkit interface components. For example, a label is a logical interface component that describes another component. However, a label is also a toolkit interface component that is used to display non-interactive text and graphics. As such, a label may by used for other functions besides describing other components. For example, a label may be used to create a section header or to display some icons. Wherever possible, we tried to make the distinction between logical and toolkit interface component explicit.
Business Web application design is too often neglected. I see a lot of applications that don’t meet the needs of either businesses or users and thus contribute to a loss of profit and poor user experience. It even happens that designers are not involved in the process of creating applications at all, putting all of the responsibility on the shoulders of developers.
Developing an effective framework for a large collection of linked documents involves: creating an efficient hierarchy of information; mapping task flows through the information hierarchy; determining the best depth for the information space; and creating nodes of appropriate length. These four tasks should be undertaken in order. Each one depends on the outcomes of preceding tasks. Because these elements are interdependent, however, several good solutions to the first two should be developed so that problems with site depth and node length can be addressed.
This paper discusses the role of an information developer in defining application interface standards and ensuring compliance across all applications. An interface, such as an application screen or system-generated report, should be consistent to enhance ease-of-processing for the end users.
During my years as an interface designer, I've worked with lots of different development teams. From big companies to small startups, the interactions between me--the product designer--and developers have been pretty consistent. We work through what interactions and features are possible given our timeframe and resources. We discuss edge cases and clarify how specific interactions should work. We debate product strategy, information architecture, target audience, front-end technologies, and more. We also frequently encounter the same issue: the need to consider what's not there.
Watching DVDs can be a frustrating experience, because DVD menus often miss out on usability and are complex and difficult to navigate through. Similar to the early years of web development, there is a lack of design standards. In this paper, we show the development of user interface guidelines for DVD menus. These guidelines can be used to design and evaluate DVD menus. We built a prototype according to the guidelines, conducted usability tests with the prototype and evaluated other movie DVDs using the guidelines to show the applicability, utility and usability of the guidelines.
Traditionally, web applications are accessed via a single mode interface; information is presented and captured with text. However, one can additionally use a voice browser to navigate the Internet. One can navigate or access 'hands free' Internet applications from anywhere; you are not restricted to the desktop or a portable computer. VoiceXML is a language for Internet telephony applications and is based on the XML language. VoiceXML can 'speech-enable' an existing web application to be used through a conversational interface, providing a more natural way of interaction between users and Internet applications.
The Java programming language contains object-oriented features enabling the construction of interface-based application frameworks. Interfaces separate module implementation from core implementation, thus simplifying module development. The following article demonstrates how to take advantage of Java interfaces by designing and implementing a game playing application framework.
This question was raised on a programmer's group recently and I was intrigued. The programmer's point was that with many web applications these days there is no print documentation distributed to end users, and even if it existed, many users won't read it although this makes me wonder who's buying all those how-to books I see in the bookstore. The programmer suggested that applications should be designed without documentation and wondered about the impact that would have on design.
This article discusses turn signals and how they are used. Turn signals improve safety because they give people time to react and they reduce driving ambiguity. However, they are only effective when people actually use them. Several lessons are applied to web usability.
Normally I would write a traditional conference overview to inform people about the recent Designing for User Experiences conference (DUX) held in San Francisco, June 6-8. Instead, I would like to impart a few of the impressions I came away with and recommend that everyone go to the AIGA Case Study Archive to read the papers that were accepted.