User experience interaction design how to design a good user experience

It's simple to say, but every point here is profound. Although we can write each article, we only give a short explanation. The missing details and examples are to be filled with your own experience.

Grasping basic functions

Core usage Scenarios--The main reason people use your Windows vista® program--far more important than those in the corner corner--is that people might do something they might not. Hold on to something basic! (If you do this, users can tolerate problems that happen at the corners.) )

Make a color out of STH

Think about how a "real" user (not a marketing or PR person) will describe your program. Find out who your target users are and make sure they say, "I love this program!" It's A, B, C is great! " If the user doesn't say that about your program, what does it mean? Now, "Just good" is no longer good enough-to let users fall in love with your program.

You don't have to be happy with everyone.

Satisfying your target audience will make your program more successful rather than trying to satisfy everyone.

Make a difficult decision

Are these features, commands, or options really necessary? If so, do it well. If not, just get rid of it! Don't make everything optional or configurable to avoid this difficult choice.

The experience of giving people is like a friendly conversation.

Think of your UI as a conversation between you and your target audience. Let's say you're next to the user and he asks you, "What am I supposed to do now?" Think about how you would explain: what steps, what order, what you would say and how to explain, and so on. And think about the things you don't say. This is how your UI should look--like a conversation between friends--and not something inscrutable that users can't understand.

Perform the correct action by default

Of course, you can list a row of options for the user to choose from, but why? You should choose a reliable, secure, and convenient default. Also, make the right experience the default experience for your target users. Do not assume that users will not configure bad initial experiences in the way they want them to.

Let it work.

People want to use your program instead of doing a bunch of setup or learning a bunch of stuff. Do the initial configuration so that the most frequently used and most important tasks are at a glance and enable your program to begin work immediately.

Careful questioning

Avoid using modal dialogs to ask questions that are not necessarily an issue--you should use a modeless dialog box. If you have to ask questions in the UI, the presentation should be based on the user's goals and tasks rather than technology. Provide the options that the user understands (again emphasizing, based on the user's goals and tasks, rather than technology), and distinct from each other. Ensure that sufficient information is provided to enable the user to make a choice.

Make it good to use.

Make sure your program is well placed to achieve its goals, include the right features, and put these functions in the right place. Pay attention to the details.

Make it look great

You should use a standard Windows Vista appearance, including standard window borders, fonts, system colors, common controls and dialog boxes, and standard layouts. Avoid customizing the UI and using a restricted branding image. Whenever possible (and legitimate!), you should use standard Windows Vista icons, graphics, and animations. If you need to use your own graphics and icons, you should use a professional designer. (If you can't afford it, just use a few simple graphics--or simply don't.) )

Do not assume that providing skin can compensate for those generalized appearances. Most users don't worry about that, and having a great look is more impressive than having a bunch of generalized looks.

Make it respond in time

Your program's response is critical to the overall user experience-users will find that unnecessary slowness and unresponsive programs are not available. For each performance feature that becomes a problem, you should first understand your users ' goals and expectations, and then choose the lightweight design that will achieve their goals. Generally, more than 10 seconds of tasks require more feedback and should be able to be canceled. Remember that the user's perception of speed is as important as the actual speed, and that the speed perception is largely determined by how quickly the program responds.

Keep it simple

Try to make the simplest design under the premise of being able to complete the task well. Extend the design to just "necessary". If one method can do things right, do not use three methods. Avoid or reduce those useless things!

Avoid a bad experience

It's easier said than done, but the overall impression that the user has on your program is more from the quality of the bad experience than the good experience.

Design for FAQ

Is your design great-unless the user makes a mistake or the network connection is interrupted? Anticipate common problems, user errors, and other errors and design for the base. Consider situations such as slow or unavailable network speeds, devices that are not installed or unavailable, and users who have made incorrect entries or skipped some steps. At each step of your program, ask yourself: What happens in the worst cases? And then see if the behavior of your program is good enough when it does happen. Ensure that all error messages have a clear explanation of the problem and provide a workable solution.

Don't get bored.

Typically, anything that a user ignores directly without taking any action should be redesigned or deleted. This is especially true for things that users will see repeatedly, such as error messages, warning messages, confirmation messages, and notifications. Sound should be used with great care. The UI associated with security and legal issues, such as licensing may be an exception.

Reduce energy, knowledge and thinking

To reduce the amount of energy, knowledge, and thinking you need to use your program:

Explicit is better than an implicit. Put the information users need to know directly on the screen. Carefully examine the main caption descriptions on the window or page to clearly express the purpose of the interface.

It's better to be brief than wordy. Put the information on the screen, but be brief. Grab the gist! Design text for browsing, not immersion reading. Use Help links for helpful, complementary, but not basic, information.

A constraint is better than no constraint. When you select a control, the control that is able to constrain valid input is usually the best choice.

Better than disabled for use. Disabled controls are often confusing, so you can use them only when the user can easily infer why the control is disabled. Otherwise, you should remove the controls that are not applicable or keep them available and provide helpful feedback.

It's better to have feedback than not to react. Provide clear feedback to indicate whether a task is executing or failing. Don't let the user guess.

Follow this design specification

Of course! The UX specification should be viewed as the minimum quality and uniformity requirements based on Windows Vista programs. Use it to follow success stories, make regular decisions, and make your work easier. Focus your creativity on the important things-no matter what your program does-not the routine. Don't create those weird programs that no one can figure out how to use. Follow this design specification to make your experience stand out.

Test your user interface

Before you use real-world target users for usability research, you won't know if you're doing the right thing. It is likely that you will be surprised (with dismay) at the result. Be happy to be critical of your user interface-it is necessary for you to do your job best. Also ensure that feedback is collected after your program is released.

Article Source: http://www.zhujunpeng.com/?post=84