things you should know before you build your site

Created by

Topics

CUSTOMER-CENTERED WEB DESIGN

Why customer-centered web design

Applying customer-centered design

Three aspect of design

KEY SUCCESS FACTOR TO DESIGN A WEB SITE

1

Focus on the users and their tasks, not on the tech

Consider function first, presentation later

Conform to the users’ view of the task

Design for the common case

Don’t distract users from their goals

Facilitate learning

Deliver information, not just data

Design for responsiveness

Try it out on users, then fixing it

2

KEY MEASURABLE DESIGN INDICATOR

Key insight analysis

Solving for company and customer: win-win

DOCUMENTATIONS

Sitemap

Storyboard

Schematics

Topics - continue

3

4





1

Customer-Centered Web Design - More Than a Good Idea

Customer-Centered

Web Design

Ease of Use

PerformanceContent

Satisfaction Brand Value

With customer-centered design… you do the work up front to ensure that the web site has the features customers need, by determining and planning for the most important features and by making certain that those features are built in a way that customers will understand.

This method actually takes less time and money to implement in the long run. In short, customer-centered design helps you build the right web site and build the web site right!

Why Customer-Centered Web Design ?





1

Principles

Proc

esse

s

Patterns

Guide the entire design

process and help you to

stay focused

How you put the principles

into practices

Design patterns solves

recurring design problem

Applying Customer-Centered Design





1

GraphicDesign

InformationArchitecture

Navigation Design

Identifying, structuring and presenting

groups of related content in a logical

and coherent manner

Designing methods so that customer

can find their way around

Developing the visual communication of information

using elements such as color, images, typography,

and layout

Applying Customer-Centered designs into three aspects of design







Facilitate learning




2

1. Focus on the users and their tasks, not on the technology

2. Consider function first, presentation later

3. Conform to the users’ view of the task

4. Design for the common case

5. Don’t distract users from their goals

6. Facilitate learning

7. Deliver information, not just data

8. Design for responsiveness

9. Try it out on users, then fixing it!

Key success factor to design a web site







Facilitate learning




2

• For whom is this software being designed? Who are the intended users?• What is the software for? What activity is it intended to support? What problems will

it help users solve? What value will it provide?• What problems do the intended users have now? What do they like and dislike about

the way they work now?• What are the skills and knowledge of the intended users? Are they motivated to

learn? How? Are there different classes of users, with different skills. Knowledge, and motivation

• How do users conceptualize the data that the software will manage?• What are the intended users’ preferred ways of working? How will the software fit

into those ways? How will it change them?

It means starting a software development project by answering several questions:

Focus on the users and their tasks, not on the technology

• Decide who the intended user are

• Investigate characteristics of the intended

users

• Users: Not just novice vs. experienced

• Collaborate with the intended users to learn

about them

• Bringing it all together

Understand your customer

Decide who the intended users are

Choose a specific primary target population as the intended user base in order to focus your design and development efforts, even if you believe that the software will also have other types of user.In reaching this important decision, confirm that your target user base is aligned with your organization’s strategic goals.

Collaborate with the intended users to learn about them

Understanding the user is best accomplished by working with them as collaborators. Don’t treat users only as objects to be studied. Bring some of them onto your team. Treat them as experts, albeit a different kind of expert than the developers. They understand their job, experience, management structure, likes and dislikes, and motivation.They probably don’t understand programming and user interface design, but that’s OK – others on your team do. A useful slogan to keep in mind when designing software is:

“Software should be designed neither for users nor by them, but rather with them”

Investigate characteristics of the intended users

Making an effort to learn the relevant characteristics of potential users. Surveying potential users helps you find specific populations whose requirements and demographics make them attractive target market After identifying a primary user population, learn as much as possible about that population .

Users: Not just novice vs. experienced

Software developers often think of their intended user as varying on a continuum from computer “novice” to “expert.” People who have never used a computer are on the novice end; professional computer engineers are on the expert end. In that assumption, continuum is wrong. No such continuum exists. A more realistic and useful view is that the intended users can be placed along three independent knowledge dimensions:

General computer savvy - how much they know about computers in general

Task knowledge - how facile they are at performing the target task, e.g., accounting

Knowledge of the system - how well they know the specific software product, or ones like it

Knowledge in one of these dimensions does not imply knowledge in another. People can be high or low on any of these dimensions, Independently.

Decision Collaboration

The goal is to produce profiles that describe the primary intended users of the software. The profile should include information such as job description, job seniority, education, salary, hourly versus salaried, how their performance is rated, age, computer skill level, and relevant physical or social characteristics.

Investigation

Bring it all together

Understand the tasks

• Decide what set of tasks to support

• Investigate the intended tasks

• Collaborate with users to learn about the tasks

• Bringing it all together

Decide what set of tasks to support

• The organization’s strategic goals, reflecting the interest of its founders, top

management, and shareholders

• The expertise of its employees

• Its past history

• Its assets, processes, and infrastructure

• Its perception of market opportunities and niches

• New technologies developed by researchers

Investigate the intended task

Before starting to design anything, learn as much as you can about exactly how the intended users do the task that the software is supposed to support . This is called conducting a “task analysis”. The best way to conduct a task analysis is for you and other members of the development team to talk with and observe people who either will be user or are similar to the intended users.

For a task analysis of how people prepare slide presentations, we interviewed people in their offices, encouraging them to both talk about and demonstrate how they work.

1. What is your role in producing slide presentations?

1.1 Do you produce slides yourself or do you supervise others who do it?

1.2 How much of your total job involves producing slide presentations?

1.3 For whom do you produce these slide presentations?

2. What software do you use to create slide presentations?

2.1 Who decides what software you use for this?

2.2 Do you use one program or a collection of them?

Example: Task-analysis questions

Collaborate with users to learn about the task

Collaborating with users is even more important for understanding the tasks than it is for understanding the users. The limitations of both interviewed and observation make it risky to rely on upon conclusion obtained by either method alone. These limitations can be overcome by introducing two-way feedback into task discovery and analysis process. Don’t just collect data from users; present the preliminary analyses and conclusion to them to and solicit their reactions.

A well-done task analysis answers some fairly detailed questions.

They are: • What tasks does the person do that are relevant to the application’s target task are?

• Which tasks are common, and which ones are rare?

• Which tasks are most important, and which ones are least important?

• What are the steps of each tasks?

• What is the result and output of each task?

• Where does the information for each task come from , and how is the information that results from

each task used?

• Which people do which task?

• What tools are used to do each task?

• What problems, if any , do people have performing each task? What sorts of mistakes are common?

and What cause them? How damaging are mistakes?

• What terminology do people who do these tasks use?

• How are different tasks related?

• What communication with other people is required to do the tasks?

Bring it all together

Engineers often view what they are designing as if it were the only thing in the universe. They don’t consider the context in which the technology will be used or what the users’ total experience will be in using the technology in that context.

Consider the person who designs a car alarm or who buys one. The designer focuses on creating a device that signals when a car is being burglarized or vandalized. The consumer focuses on protecting his or her cars. Neither considers that the alarm has to work in an environment in which many other people have car alarms and in which things other than break-ins trigger the alarm. When an alarm sounds, it is difficult to know whose car it is and impossible to know if it signals a break-in. Only rarely will it be a brake-in. An otherwise good product idea fails to provide value because the designer and the consumer didn’t consider the larger picture.

Consider the context in which the software will function







Facilitate learning




2

• What concepts will be visible to users? Are they concepts that users will recognize from the task domain, or are they new? If new, can they be presented as extensions of familiar concepts, or are they foreign concepts imported from computer science

• What data will users create, view, or manipulate with the software? What information will users extract from the data? How? What steps will they use? Where will the data that users bring into the software come from, and where will the data produced in it be used?

• What options, choices, settings, and controls will the application provide? This is not about how to present controls (e.g., as radio buttons, menus, sliders). It is about their function, purpose, and role in the software (e.g., day of week, dollar amount, e-mail address, volume level). It is about what options the software provides

A software application embodies certain concepts and relationship between concepts. Designers should fully define the concepts and their relationships before they design how to present the concept to users. Don’t jump right into GUI layout. Before sketching screens, choosing and laying out controls, cutting foam prototypes, or writing code, developers should focus on answering the task-related question and then following questions:


Once a development team has answered the previous questions, it is important to capture and organize that knowledge in a way that aids UI design. A recommended way is to design a conceptual model for the software.

A conceptual model is the model of an application that the designers want users to understand. By using the software and perhaps reading its documentation, users build a model in their minds of how it works. It is best if the model that users build in their minds is like the one the designers intended. That is more likely if you design a clear conceptual model beforehand.

A conceptual model is not a user interface. It explains, abstractly, the function of the software and what concepts people need to be aware of in order to use it. The idea is that by carefully crafting an explicit conceptual model, and then designing a UI from that, the resulting software will be cleaner, simpler, and easier to understand.

Develop a conceptual model

Starting a design by devising a conceptual model has several benefits:

• Task focus: Devising a conceptual model focus designers to consider the relevance to the task of each user-visible concept and the relationships between objects. When these issues have been thought through before UI is designed, it will map more naturally onto users’ tasks.

• Consistency: Enumerating the objects and actions of an application’s supported task allows you to notice actions that are shared by many objects. The design can then use the same user interface for operations across those objects. This makes the UI simpler and more consistent and thus easier to learn.

• Importance: Listing all user-visible concepts allows you to rate their relative importance. This impacts both the UI design and the development priorities.

• Lexicon: A conceptual model provides a product lexicon, a dictionary of terms for each of the objects and actions embodied in the software. This fosters consistency of terminology, not only in the software, but also in the product documentation.

Benefits of developing a conceptual model

• Scenarios: A conceptual model allows the development team to write task domain-level scenarios of the product in use. Those scenarios are useful in checking the soundness of the designer and also in documentation, in functional reviews, and as scripts for usability tests.

• Kick-start development: An objects/actions analysis provides an initial object model- at least for objects that users encounter. Developers can start coding it even before the UI is designed.

• Focus team and process: The conceptual model serves as a focal point for all development team members and other stakeholders to discuss and continually evaluate the design .

Benefits of developing a conceptual model - continue







Facilitate learning




2

• Strive for naturalness• Imposing arbitrary restrictions• Use users’ vocabulary, not your own • Keep program internals inside the program• Find the correct point on the power or complexity trade-off

Software user interfaces should be designed from the users’ point of view. You cannot do that if you don’t know what the users’ point of view is. The best way to discover the users’ point of view is to follow “Focus on user and task”. Conforming to the users’ view has several sub principles as the following


Strive for naturalness

Don’t make users commit unnatural acts. Unnatural acts are steps users have to perform that have no obvious connection to their goal. Software that makes users commit unnatural acts strikes them as arbitrary, nonintuitive, and amateurish, because unnatural acts are difficult to learn, easy to forget, time consuming, and annoying. Too many software applications force users to commit unnatural acts

Another way in which software can violate users’ sense of naturalness and intuitiveness is by imposing arbitrary or seeming arbitrary restrictions on users.

Examples of such restrictions include:

• Limiting person names to 16 characters

• Allowing table rows to be sorted by at most three columns

• Providing Undo for only the last three actions

• Requiring a fax number in all address book entries even though some users

don’t have fax machines.

Imposing arbitrary restrictions

When writing text for the software or its documentation, avoid computer jargon. You should create a project lexicon. The lexicon should name every concept (object, action, or attribute)

Use users’ vocabulary, not your own

Keep program internals inside the program

Software users are not interested in how the software works. They just want to achieve their goals.

Software developers tend to believe “the more options, the more controls, the more power, the better.” In contrast, most people who use computer software just enough functionality to achieve their goals. Most people learn to use software only a few of the features of a software application and ignore the rest.

Once you know how much functionality users need, you can also use one or more of these design techniques for reducing complexity

• Sensible defaults: Make sure that every setting in an application has a default

value.

• Templates: Instead of making users start every task from scratch, provide partial

or complete solutions for user to start.

• Guided paths-wizards: Predefined sequences that guide users step-by-step

through complication process.

• Progressive disclosure: Hide detail and complexity until the user needs it.

• Generic commands: Use a small set of command to manipulate all types of data.

• Task-specific design: Offer user a small specialized programs to support one task.

• Customizability: Make the UI customizable.

Find the correct point on the power/complexity trade-off







Facilitate learning




2

• Make common results easy to achieve• Two types of “common” : “how many users?” vs. “how often?”• Design for core cases; don’t sweat “edge” cases

In any task domain, users will have goals ranging from common to rare. Design your application to recognize this range.


• The more frequently a feature will be used, the fewer clicks it should require

• The more users will use a feature, the more visible it should be

• Combinations ”frequent by many, frequent by few, infrequent by many, infrequent by few

Make common results easy to achieve

• How many users will need the feature? Will it be used by all or nearly all users, the majority, a significant minority, or almost none?

• How often will user need the feature? Will those people who need the feature use it every few seconds, minutes, hours, days, weeks, months, or years?

Two types of “common” : “how many users?” vs. “how often?”

Design for core cases; don’t sweat “edge” cases

Don’t spend inordinate amounts of time with the low priority feature.







Facilitate learning




2

• Don’t give users extra problems• Don’t make users reason by elimination

The human mind is very good at multitasking. We often do many tasks at once, for example, talking on the phone while beating an egg while keeping watch on our child, all while tapping a foot to a song we heard on the radio earlier this morning.


Don’t give users extra problems

People have plenty of their own problems in the domains of their work, their personal lives. That’s partly why they use computer product and services: to help them solve those problems and achieve their goals.

Don’t make users reason by elimination

Minimizing the need for problem solving in the domain of computer technology includes not requiring users to figure out how software works by a process of eliminations.







Facilitate learning




2

• Think “outside-in,” not “inside-out”• Consistency , consistency, consistency

A common complaint about software applications is that they are hard to learn. Learning takes time; the more a user has to learn in order to use a product or service, the longer it will be before that user can be productive. Time is money.

Facilitate learning

Software developers often design as if they assume that the users will automatically know what the developers intended. This is inside-out thinking. They assume that users perceive and understand everything the way the designer intended it to be perceived and understood.

The problem is, users don’t know what the designer knows about the software. When people first start using a software product, they know very little about how it works or what all stuff on the screen is supposed mean.

Think “outside-in,” not “inside-out”

User interfaces should foster the development of usage habits. When using interactive software and electronic appliances. They want to be able to ignore the software or device and focus on their work. The more consistent the software is, the easier it is for users to do that

Consistency , consistency, consistency







Facilitate learning




2

• Design displays carefully; get professional help• The screen belongs to the user• Preserve display inertia

Computer promise a fountain of information, but deliver mainly a glut of data most of it useless. Data is not information. People extract information from data.


• Visual order and user focus: A successful UI doesn’t just present. It directs users’ attention toward what is important.

• Scannability: Computer users rarely read the screen carefully. They usually scan it quickly looking for anything matching their goals.

• Match the medium: One mark of a poorly designed UI is failing to match the design to the limitations of the presentations medium.

• Attention to detail: Success is in the detail.

Design displays carefully; get professional help

Researchers discovered that it is usually a bad idea for software to unilaterally move controls and data around on the screen. This includes having the software:

• Jump or “wrap” the mouse pointer to new positions.

• Move controls to the pointer.

• Reposition, stretch, or shrink windows.

Such attempts to be helpful and efficient disorient and frustrate users more than they help. They interfere with users’ perception of the screen as being under their own control.

The screen belongs to the user

Preserve display inertia

If a user edits a field in a Web form or a word on a Wiki page, it would be poor UI design for the entire page to refresh.







Facilitate learning




2

• Designing for responsiveness

Responsiveness- a software application’s ability to keep up with users and not make them wait- is the most important factor in determining user satisfaction.


To be perceived by users as responsive, interactive software must:

• Acknowledge user actions instantly, even if returning the answer will take time.

• Let users know when it is busy and when it isn’t.

• Free user to do other things while waiting for a function to finish.

• Animate movement smoothly and clearly.

• Allow users to abort lengthy operations they don’t want

• Allow users to judge how much time operations will take

• Do its best to let users set their own work pace.

Designing for responsiveness







Facilitate learning




2

• Test results can surprise even experienced designers• How many users should you test• Schedule time to correct problems found by tests• Testing has two goals: Informational and social• There are tests for every time and purpose

Trying a product or service out on people who are like the intended users to see what problems they have in learning and using it. Such testing is extremely important for determining whether a design is successful, that is, whether it helps users more than it hinders them

Try it out on users, then fix it!

Developers can learn surprising things from usability tests. Sometimes the results can surprise even user interface experts.

Test results can surprise even experienced designers

How many users should you test?ONE TEST WITH 8 USERS

TWO TEST WITH 3 USERS

TOTAL PROBLEMS

FOUND: 5

TOTAL PROBLEMS

FOUND: 9

8 users

First test: 3 users Second test: 3 users

Eight users may find more problems in a single test.

But the worst problems will usually keep them from getting far enough to encounter some others.

Three users may not find as many problems in a single test.

But in the second test, with the first set of problems fixed, they’ll find problems they couldn’t have seen in the first test.

Of course, it isn’t enough just to test the usability of a product or service. Developers must also provide time in the development schedule to correct problems uncovered by testing. Otherwise, why test?

Schedule time to correct problems found by tests

Information goal: find the aspects of the user interface that cause users difficulty, and use exact nature of the problems to suggest improvements.

Social goal: It is at least as important as the informational goal. It is to convince developers that there are design problems that need correcting.

Testing has two goals: Informational and social

Test can be conducted before any code is written, when the software has been only partially implemented, or after the software is almost done.

There are tests for every time and purpose




3

Key measurable design indicator

Key performance indicator (KPI) can’t accommodate for strategic differences in business operations and execution. They have not been quite as helpful as one might have hoped for. To compete, we have now use Key insights analysis (KIA).

Key Insights Analysis (KIA)

1. Click Density Analysis: You can see what the difference in behavior is for different kinds of traffic to your website.

2. Visitor Primary Purpose: Conduct a survey, do phone interviews. Seek out real customers and ask them why they show up on your website.

3. Task completion Rates: Page view cannot measure the customer satisfaction.

4. Segmented Visitor Trends: ClickTracks and Visual Sciences (analysis tool) allow you to segment your customers and their behavior in a meaningful way that allows for a significantly richer understanding of their interaction with your website.

5. Multichannel Impact Analysis: Measuring the impact of your web site on other channels (how many people use your website but buy your product via retail or via your phone channel)




3

Actionable

Insights &

Metrics

Behavior

ExperienceOutcomes

ClickStream

Click Density Analysis

Segmentation

Key Metrics, Search

Intent Inferences

Research

Customer Satisfaction

A/B Testing

Heuristic Evaluations

Voice of Customer

Orders/Leads

Revenue: How, Why

Conversion rates

Problem Resolution

Nuances of Outcome

Leading to win-win Outcomes

Understanding

Explicitly Customer

Experience

To influence

optimal

Behavior

Solving for companies and customers: Win-Win

DOCUMENTATIONS

Sitemap

Storyboard

Schematics

4

Sitemaps

Sitemaps: is a high-level diagram showing the overall structure of a site. It is used primarily to reflect an understanding of information structure, or architecture, of the site as it is being built and, to a limited extent, the navigation structure.

DOCUMENTATIONS

Sitemap

Storyboard

Schematics

4

Storyboard

Storyboard is a sequence of Web pages depicting how a customer would accomplish a given task. Use storyboard to illustrate important interaction sequences, or flow through the site.

DOCUMENTATIONS

Sitemap

Storyboard

Schematics

4

Schematics

Schematics (wire frame): are representations of the layout and content that will appear on individual pages. The fonts, colors, and layout are often quite preliminary, not indicating a final decision.

References

1. Don't Make Me Think!: A Common Sense Approach to Web Usability, Steve Krug

2. The Design of Sites: Patterns for Creating Winning Websites, Douglas K. van Duyne

3. Prioritizing Web Usability, Jakob Nielsen

4. GUI Bloopers 2.0: Common User Interface Design Don’ts and Dos, Morgan Kaufmann

Thank you for watchingmy presentation

panu ausavasereelert

blog: http://panu.in.th

email: [email protected]

twitter: @panuinth

Created by

things you should know before you build your site

Technology

intended users users

different classes of

web sitefocus

web site1focus

right web site

web site right

web site key success

recurring design problem