Archiv der Kategorie ‘Interface Design‘


Life long dedication to forms

Filling in the Blanks

Web Form Design: Filling in the Blanks

Great book from Luke Wroblewski, but man, how can you stay focused on forms for that long…

“Forms make or break the most crucial online interactions: checkout (commerce), registration (community), data input (participation and sharing), and any task requiring information entry. In Web Form Design, Luke Wroblewski draws on original research, his considerable experience at Yahoo! and eBay, and the perspectives of many of the field’s leading designers to show you everything you need to know about designing effective and engaging Web forms.” See Complete Description…

Go to Source

Job Trends in Usability

Go to Source

Not The User’s Fault Manifesto

What Jono DiCarlo of Mozilla Labs thinks of software development and user-interface design…

1. Why write code?

Software is for humans, not for computers.

Software is only as good as the improvement it makes to a human being’s life.

Are we making someone’s job easier? Letting them have more fun? Helping them learn? Helping them keep in touch with friends and family?

Are we making the world a better place?

2. What do people want?

Most people do not want a computer.

They don’t even want software.

For us software developers, this is a painful truth.

If people don’t want a computer, why do they use one?

The computer is merely an intermediary. A poor and frustrating one. It is a necessary evil that people put up with in order to get what they want.

What they want is a better way to talk to each other.

3. Why does software succeed or fail?

We software developers, being not exactly social creatures by nature, must work extra hard to understand the social impact our software will have. If the social effect is not what people want, the software goes unused.

We software developers, being not exactly average users, must work extra hard to understand how average users will relate to our software. We see the trees, they see the forest.

We software developers have often been confused and frustrated when a clearly superior technology fails, while a clearly inferior technology spreads like wildfire and takes over the world.

We were surprised because we want each technology to be judged only by its cleverness, its raw power, the cleanliness of its architecture, the purity of its ideas. We were blind to the user experience, to what each technology meant in the bigger picture of a person’s life.

To the people buying and using the “clearly inferior” technology, exactly the opposite was true.

To the user, the interface is the product.

4. Why is there not more Linux on the desktop?

For open source software to take over the world, we’re going to have to do a lot better at user interfaces than we have been doing.

How do I know?

Open source has already taken over the invisible parts of the world: the servers, the infrastructure, the things users need not touch directly.

Mozilla, the most user-experience-focused of open-source companies, has the most adoption by end-users.

People say things to me like, “Linux is only free if the value of my time is zero.”

These are not coincidences.

At one time, the way of open-source software development was thought impossible. But the techniques were invented. The way became possible; then it became successful. Now the techniques are becoming widely known.

The way to make open-source UI design successful is still unclear. We must invent the techniques.

5. Are users dumb?

User interface design is not about dumbing things down for the poor stupid user.

We software developers, understanding the software as we do, find it easy to look down upon those who lack our understanding.

This is wrong.

Users aren’t dumb. They just have better things to do with their lives than memorizing the internal data model of our screwy software.

When software is hard to use, don’t make excuses for it. Improve it.

When a user makes a mistake, don’t blame the user. Ask how the software misled them. Then fix it.

The user’s time is more valuable than ours. Respect it.

Good UI design is humble.

6. Is UI design marketing?

User interface design is not marketing.

Software developers loathe marketing, so if they think that UI design is marketing, then they will loathe UI design.

The qualities of software that make for a good advertisement or computer-store demo are not the same qualities that make software usable and pleasant to work with long-term, day-in day-out. Often these qualities are opposites.

A shopper may choose the microwave with more buttons, because it seems “more powerful”. However, the shopper will soon find out that it does the same thing as any other microwave, you just have to spend longer figuring out which button to push.

It is easy to fool people into buying something that is against their own best interest.

Don’t do that.

7. What is the task of the UI designer?

Let us talk about that microwave some more.

The microwave with the most buttons may be most popular, but it is not the best microwave.

The best microwave has no buttons at all.

It doesn’t need any buttons because it already knows how long you want your food cooked and how hot. You never need to set the clock, either: it’s just always right.

The no-button microwave may not be reachable, but like a guiding star it shows us the direction we should travel.

Users do not know what interface they want. Users do not know what features they want.

Users know the tasks they want to do, and the problems they have.

We learn more by watching the user work than by asking the user.

The job of the UI designer is to provide what the users need, not what the users say they need.

It is to make tasks easier, not to provide features.

8. Where is the science?

User interface design can be approached scientifically. But usually isn’t.

Until we observe people using our software for real, our design is guesswork and superstition.

These things can be measured and given numbers:

An interface’s efficiency and learnability are empirically determinable quantities.

They are not matters of opinion.

Every user is different, but that’s why we have statistical methods.

The science of design can tell us that interface foo is X% more efficient than interface bar, but bar is Y% more learnable than foo.

Choosing between foo and bar — that’s where the science ends and the art begins.

9. Is change good or bad?

Change has a cost. Change disrupts the user’s habits. Change forces the user to learn something new.

Sometimes the new UI is so much better than the old one that the change is worth the cost.

Sometimes it isn’t.

The trick is knowing when change is worth it.

10. What is the evil of the bad interface?

It is a sin to waste the user’s time, break the user’s train of thought, or lose the user’s work.

Bad user interfaces do all three. Frequently.

Most interfaces are bad.

I do not use the word “sin” lightly.

Because of bad user interfaces, an action taken based on a reasonable assumption or out of habit often results in broken trains of thought, wasted time, and lost work. This is called “user error”, but it isn’t. It is programmer or designer error.

When we blame the user, we teach them that technology is perfect and that the errors are their own. Because technology is hard to use, we are teaching a generation to be afraid of technology. We are teaching a generation to believe in their own stupidity. This is a sin, too.

It’s not the user’s fault.

Go to Source

Major Revolution Announcement

I have posted a major announcement regarding Revolution and it’s future. Please take a moment to read it over on my site.

Go to Source

User Interface Design

User Interface Design


1. The Golden rule


These golden rules actually form the basis for a set of user interface design principles that guide this important software design activity.


1.1     Place the User in control


Most interface constraints and restriction that are imposed by a designer are intended to simplify the mode of interaction. The designer might introduce constraints and limitations to simplify the implementation of the interface. The result may be an interface that is easy to build, but frustrating to use.


Design principles:


ü        Define interaction modes in a way that does not face a user into unnecessary or undesired actions.

ü        Provide for flexible interaction

ü        Allow user interaction to be interruptible and undoable.

ü        Streamline interaction as skill levels advance and allow the interaction to be customized.

ü        Hide technical internals from the casual user.

ü        Design for direct interaction with objects that appear on the screen.


1.2     Reduce the User’s Memory Load


A well designed user interface does not tax the user’s memory. Whenever possible, the system should “remember” pertinent information and assist the user with an interaction scenario that assists recall.


Design principles to reduce the user’s memory load:


ü        Reduce demand on short-term memory. The interface should be designed to reduce the requirements to remember past actions and results.  This can be accomplished by providing visual cues that enable a user to recognize past actions, rather than having to recall them.

ü        Establish meaningful defaults.

ü        Define shortcuts that are intuitive.

ü        The visual layout of the interface should be based on a real world metaphor.

ü        Disclose information in a progressive fashion.


1.3     Make the Interface consistent


The interface should present and acquire information in a consistent fashion. This implies that

(1)     all visual information is organized according to a design standard that is maintained throughout all screen displays,

(2)     input mechanisms are constrained to a limited set that are used consistently throughout the application, and

(3)     mechanism for navigating from task to task are consistently defined and implemented.


Design principles to Make the Interface consistent:


ü        Allow the user to put the current task into a meaningful context. It’s important to provide indicators that enable the user to know the context of the work at hand.

ü        Maintain consistency across a family of applications. A set of applications should all implement the same design rules so that consistency is maintained for all interaction.

ü        If past interactive models have created user expectation, do not make changes unless there is a compelling reason to do so.


2. User Interface Design


The overall process for designing a user interface begins with the creation of different models of system function. The human and computer oriented tasks that are required to achieve system function are then delineated; design issues that apply to all interface designs are considered; tools are used to prototype and ultimately implement the design model; and the result is evaluated for quality.


2.1 Interface Design Models


Four different models come into play when a user interface is to be designed. The software engineer creates a design model, a human engineer establishes a user model, the end-user develops a mental image that is often called the user’s model or the system perception, and the implementers of the system create a system image.


A design model of the entire system incorporates data, architectural, interface, and procedural representations of the software. The requirements specification may establish certain constraints that help to define the user of the system, but the interface design is often only incidental to the design model. The user model establishes the profile of end-user of the system. Users can be categorized as:

ü        Novices. No syntactic knowledge of the system and little semantic knowledge of the application or computer usage in general

ü        Knowledgeable, intermittent users. Reasonable semantic knowledge of the application but relatively low recall of syntactic information necessary to use the interface.

ü        Knowledgeable, frequent users. Good semantic and syntactic knowledge that often leads to the “power-user syndrome”; that is individuals who look for shortcuts and abbreviated modes of interaction.


The system perception is the image of the system that end-users carry in their heads. The system image combines the outward manifestation of the computer-based system, coupled with all supporting information that describes system syntax and semantics. The mode described “abstractions of what the user is doing or thinks he is doing or what somebody else thinks he ought to be doing when he uses an interactive system”.


2.2 The User Interface Design Process


The design process for user interfaces is iterative and can be represented using a spiral model. The user interface design process encompasses four distinct framework activities.

1.        User, task, and environment analysis and modeling

2.        Interface design

3.        Interface construction

4.        Interface validation


The initial analysis activity focuses on the profile of the users who will interact with the system. Once general requirements have been defined, a more detailed task analysis is conducted. Those tasks that the user performs to accomplish the goals of the system are identified, described, and elaborated. The analysis of the user environment focuses on the physical work environment.


ü  Where will the interface be located physically?

ü  Will the user sitting, standing, or performing other tasks unrelated to the interface?

ü  Does the interface hardware accommodate space, light, or noise constraints?

ü  Are there special human factors consideration driven by environment factors?


The information gathered as part of the analysis activity is used to create an analysis model for the interface. Using this model as a basis, the design activity commences.

The goal of interface design is to define a set of interface objects and actions that enable a user to perform all defined tasks in a manner that meets every usability goal defined for the system. The implementation activity normally begins with the creation of a prototype that enables usage scenarios to be evaluated.


3. Interface Design Activities


Once task analysis has been completed, all tasks required by the end-user have been identified in detail and the interface design activity commences.


ü  Establish the goals and intentions for each task.

ü  Map each goal and intention to a sequence of specific actions.

ü  Specify the action sequence of tasks and subtasks, also called a user scenario, as it will be executed at the interface level.

ü  Indicate the state of the system; i.e. what does the interface look like at the time that a user scenario is performed?

ü  Define control mechanisms; i.e. the objects and actions available to the user to alter the system state.

ü  Show how control mechanisms affect the state of the system.

ü  Indicate how the user interprets the state of the system from information provided through the interface.


3.1 Defining Interface Objects and Actions


Once the objects and actions have been defined and elaborated iteratively, they are categorized by type. A Source object is dragged and dropped onto a target object. The implication of this action is to create a hard –copy report. An application object represents application-specific data that is not directly manipulated as part of screen interaction. When the designer is satisfied that all important objects and actions have been defined. Screen layout is performed. Like other interface design activities, screen layout is an interactive process in which graphical design and placement of icons, definition of descriptive screen text, specification and titling for windows, and definition of major and minor menu items is conducted.


3.2 Design Issues


The design of a user interface evolves, four common design issues almost always surface; system response, user help facilities, error information handling, and command labeling. System response time is primary complaint for many interactive applications. System response time is measured from the point at which the user performs some control action until the software response with desired output or action.

System response time has two important characteristics: length and variability. If the length of system response is too long, user frustration and stress is the inevitable result. A very brief response time can also be detrimental if the user is being paced by the interface. A rapid response may force the user to rush and therefore make mistakes.


Variability refers to the deviation from average response time, and in many ways, it is the most important response time characteristic. Low variability enables the user to establish an interaction rhythm, even if response time is relatively long.

Go to Source

A new face for the bowels of big BT

I got back from holiday at the beginning of last week and, since then, I’ve been working for a meeting we had yesterday with some folks in HR Systems. We have, er, a certain dislike for the interface to our internal expenses system, so we’d decided to make a better one and show it to some friends in big BT.

Whilst the demo was very simple and contained only an idea of what the interface could look like, along with showing that we were able to create a new expense claim programatically, it was received enthusiastically. The development team there is involved in a related project and it felt like there was a lot of code we could share.

Really this meeting is a cover-up for the good-natured brainwashing that it is our responsibility to carry out: Creating “tear-off” interfaces for foreign systems, customisable and shareable by the people that use them, is a big goal for us. If we can remove responsibility for deciding how to use a system from the vendors that peddle these products and put it in the hands of the people who use them, this can teach us a lot about what people really want out of a system; and moreover, how this varies across different groups of people. (Enterprise wonks may recognise this as “requirements gathering”.) If this gives us a clue about how better to personalise products, big BT will be a very happy chap.

The methods we develop are applicable on the web. Web designers have long championed the separation of data structure and visual representation. As the idea that a web application has many more entry points than just the HTML website gains some traction (not to mention that your website is your API), letting your customers dictate their own interface into your site is a much more realistic proposition, since the unchangeable becomes the internal data structure instead of the external skin.

At the very least, when we save BT £1m of custom interface redesign work from A. N. Other big supplier, that ought to get us some cred.

Go to Source

Era of the Gesture?

In reference to a recent NY Times article on the Apple iPhone breakthrough use of multi-touch (, I am wondering if the ‘era of the gesture’ so to speak is really upon us.  This is a significant input modality shift from the handheld mobile devices of the recent past and, in some circles, may represent more of a shift toward wearable computing devices than specifically a breakthrough for multi-touch.  As for the application of multi-touch in medicine which has been in action for some time now in the ‘dashboard’ concept as well as in the tablet PC (in a different form really–for written documentation), for busy clinicians, it is easy to imagine how much more intuitive multi-touch is than the trackball, stylus or rollerball of now more primitive devices.

Related to this ‘so-called’ breakthrough are two items of particular interest:

Will multi-touch now make its way back into desktop and laptop devices? {And does multi-touch alone solve any problems that small form factor devices are used for?)


Will wearable devices with internal sensors get a jumpstart from this trendsetting example or will we spend another 5-10 years looking at various mutations of multi-touch devices?

One thing I do know, the fomite issue remains unsolved in the case of the iPhone. In fact, the hand-screen contact has been significantly increased with the advent of multi-touch, a problem that won’t go unnoticed in the hospital based setting.

Go to Source

Microsoft & Ford: Breaking Monopolies Using Consumer Learning

When the automobile emerged on to the mass market at the beginning of the last century, the dominate manufacturer was Ford. The company pioneered many of the principles behind mass production, one of which was to standardise every part of the production line. This heavy standardisation introduced predictablity in to the production line and resulted in one model of car being produced for all individuals. Driving a car was a skill that was specific to the model you were driving, so in the early days, if you could drive a car you could were talking about a Ford.

Later on, GM began to compete with Ford using a different strategy. GM president Alfred Sloan used advanced account techniques to segment the company in to various divisions that could be controlled at a high-level by central management. In other words, Sloan managed to delegate responsibility to each division whilst retaining centralised control. The effect of a modular company architecture was that GM were able to re-use components and skills whilst creating a broad range of automobiles, from Chevrolet to Cadillac. Eventually, GM were able to offer a model to suite most ages, tastes and incomes.

In this condensed story of the automobile industry, you can crudely substitute the Ford automobile with Microsoft Windows, and GMs range with Linux. What do I mean by this? Ford (read: Microsoft) created a product for the mass market that initially determined the basic skill set required to operate the product, quite simply, because it created the market. GM (read: Linux community) create a competing product using modular components that can be reused across different models, by making use of a decentralised structure to facilitate flexibility and autonomous initiative.

As we know today, the operation of an automobile is, on the whole, universal across all manufacturers. The controls and dashboard on the car have evolved in to a standard model, so that you can drive a Ford, Fiat or Ferrari with the same basic skills. In other words, the user can reuse their operational skills because they are abstracted away from the implementation of the system.

The same skill reuse, to some extent, present in personal computing. This is partly because, today, people are generally more computer literate than ever-before, and have come to understand the “Windows”-style interface present in Microsoft Windows, Apple’s Mac OS, and many Linux varieties.

The convergence in the patterns and practices that are used for interface design will continue until desktop operating systems have a standard method of use accross all vendors and price-ranges. This will create increased market competition between all operating systems vendors, even between propriety and open-source products, allowing mainstream computer users to benefit from broader choices and lower costs when deciding which product they should use to operate their personal computer.

Go to Source

Text to visual

As we move from written and spoken explanation to visual communication by showing, here is another way to look at the text of a lecture handout on the design process.

It’s a data map generated from the lecture notes.


User Experience

User Experience

Go to Source

Open for comments

Comments throughout the blog are now open to guests. An email address is required, but not prior approval.

This is an experiment to see if readers want a discussion space. Readers can also be participants. The blog is mainly intended for students attending the course but we have a wider readership, who have offered helpful links  and constructive criticism.

It is intended as a small test case to help us see where the boundary between course membership and guest participation should be drawn. Do students want a public forum, or do they want a more private space? Do we all gain from a conversation which includes visitor comments, or is it too difficult to keep contributions relevant?

More fundamentally, are comment threads and forums  solutions looking for a problem to solve? We need to think about defining the problem to which this is the solution.

To add your comments about comments, head over to the Comments Welcome page.

Participating users need to add the Comments(RSS) feed to their feedreader. In this template it is at the bottom of every page.

Go to Source