Bid Ethiopia

Several forms of background research are used to uncover user needs: surveys, scenarios, competitive analysis, interviews, and focus groups.

These give us a better idea of our true user profile, user needs, and user preferences. Most of these methods are also very good at generating conceptual design ideas.

Designers don’t have to rely on their own ingenuity to solve design problems but can use background research to elicit the considerable knowledge and domain expertise of the target users.

With most of these methods, you’ll want to work closely with the marketing department, because of the large overlap of interests between usability concerns and marketing.

You’ll also find that there are some distinct interests: whereas marketing is interested in how much people are willing to pay, what magazines they read, and how they make purchasing decisions, the usability specialist is more interested in their disabilities, computer skills, and work practices.

As a result, while many of these techniques are also part of traditional marketing practice, such as competitive analysis, you’ll see that the way we carry them out is somewhat different than the traditional methods, stressing usability concerns.

The first method of background research that we’ll discuss is conducting a user survey. Since most people have answered a marketing survey at one time or another, this method is likely to be the most familiar.

What to Ask About
What kinds of information are surveys particularly good at collecting? Surveys work well for issues that are clear cut and easy to categorize, such as basic demographics. They should also focus on questions that directly resolve design dilemmas, helping to guide your design decisions.

Demographics
Surveys are a good way to collect the demographics of your users, especially to help uncover the breadth of diversity. A quick questionnaire can determine the target population’s general age, gender, profession, education, computer skill, type of computer, and nationally.

The first use of demographics is to verify that you have properly sampled your target population. The second use is to find out basic data about your audience’s skills, experience, and lifestyle.

For instance, if you are building a gaming site for young men, you can first check to make sure that your responses are actually from young men, and then you want to find out what those young men are like: what computers do they use, what games do they play, what types of game controllers do they have, what is their reading level, and how much time do they spend on internet gaming sites?

Needs and Preferences
Surveys explore people’s preferences with questions such as “What kinds of products would like to buy online?” Surveys explore the problems people have with web sites by asking questions such as “Which of these issues would you consider to be the worst aspect of browsing the Web: _ download speed, _ browser incompatibility, _ getting lost.” And surveys also explore the problems users have with the job task for which they are using the Web by asking questions such as “What are the most common problems you have with tracking inventory today?”

Design Impact
In crafting your survey, choose questions that will have a direct impact on your design. If you can’t decide how an answer would affect your design, then delete the question.

For instance if your design wouldn’t be affected by gender, don’t bother asking users to specify their gender.

And definitely do not depend on stereotypes of how gender should influence the design. Your stereotypes may be wrong, so rely on user data.

If you think men prefer black background on their web sites, you’re much better of asking “What background color do you prefer on web sites?” than asking their gender.

Similarly, don’t assume technical people want a design with elaborate technical wizardry or that children prefer talking animals before you’ve actually asked them.

While it may be interesting to ask about gender and find out how gender correlates with other responses, this is mostly useful if you’re trying to do long-term research rather than practical design.

For solving the design problem at hand, keep the survey short and the point, skipping questions you won’t apply directly, and design your web site to work across the spectrum of responses you get.

Occasionally, it may be useful to ask general questions to look at how users’ backgrounds may affect their responses.

This may lead you to broaden your survey sample if the pattern of responses suggests you had a biased sample, Form 3-3 is a sample survey template that can be modified according to the kind of information that is needed. (Download from http://www.mkp.com/uew/.)

Report This Post

When analyzing responses to your survey, you’ll generally look for the average or most common response.

You can count the total number of responses to a checked item. Low responses to an individual question may indicate that the question is unclear and the responses should be interpreted cautiously.

Surveys can provide extremely useful data, but remember to document the limitations to the data, such as a low response rate, sampling problems, or biases.

Exceptional responses should not be ignored. You’re not simply looking for an average response.

While it’s useful to know how an “average” person responds, it’s also very useful to understand the spectrum of responses.

How much do people vary in their responses? You may want to create a design that serves two or more divergent audiences.

Also, some outlier populations may be extremely important to your site design. For instance, 2 percent of your users may be millionaires, but they may buy your most expensive products and account for far more than a 2 percent potion of your profits.

And some small populations may require extra attention to serve more challenging needs, such as providing an accessible design for people with disabilities.

Report This Post

While functionality is sometimes considered outside the domain of the usability specialist, it’s clear that if users simply can’t do something they need to do, then the system isn’t usable.

As such, much of the work done in user studies during user needs analysis is focused on uncovering the capabilities and functionality that the users will need.

A traditional requirements document in software engineering focuses on functional specifications, or specs. These list each subsystem of the software and all functional requirements within each subsystem.

This document is revised throughout the requirements analysis phase, and additional functional requirements may be added during development as the functionality is understood more intimately or as usability studies reveal that a feature needs to be added or removed.

Later changes are reviewed carefully to understand then impact on schedule and budget. Functional requirements are explicitly prioritized and desired features are scheduled for later releases of the web site.

The functional specs are referenced throughout design and production of the site to verify that the system being produced corresponds to the necessary functionality. In addition, the quality assurance team uses the functional specs as the basis for the majority of its testing.

A large site will have hundreds, thousands, or even more functional requirements specified. Some example functional requirements for the site visitor include the following:

• Site contains a help system that can be brought up from any screen.
• Site contains links to contact information on every screen.
• Error pages include a customer service phone number.
• Searches that return zero matches include suggested products to view.
• Product listings include product name, description, size, and weight.
• Site sends email to buyers when orders are back-ordered, and when back-ordered products are received.
• Site emails a welcome message to users when they register.

Many sites need an administrative interface for those who must update the site content or process orders. Don’t forget to plan the features for these users also. Some example functional requirements for the administrative (or backend) portion of the web site include the following:

• Ability to add, modify, and delete product listings on the site.
• Ability to add, modify, or delete banner ads posted throughout the site.
• Notification system that emails copies of all orders to the shipping department and to the site administrator.
• Nightly transaction reports listing all orders through the site.
• Reports upon request for
• Money made per period – by ads and by order
• User demographics by product category
• Products sold by user category
• Banner ad hit counts by company purchasing banner ads
• Ability to tell f the system is down and send an alert to the system administrator and to the manager responsible for the site.

Report This Post

Why are you creating a web site? Who is it for and what do they need to do on the site?
A form like Form 3-2 can be used to help you clarify the stakeholders, business goals, user goals, and usability objectives for the site. (Download from http://www.mkp.com/uew/.) Feel free to expand on it if it isn’t quite the right list for your site.

The Stakeholders
Who will be affected by the existence of your web site, and why do they care? Your clients. Your design team.

The end users. For an e-commerce site, the stakeholders include the vendors, the distributors, the shipping company, business partners, advertisers, investors, all departments within the e-commerce company (marketing, purchasing, billing, shipping, customer support), the customers, the person they’re buying for, the customers’ spouses who get ignored while the customers are using the computer, and their friends who are trying to call while they’re monopolizing the phone line.

You’ve got to factor in the concerns of all these people in a complex set of design tradeoffs. If you ignore some stakeholders, someday they’re going to walk in and play their trump card, and an otherwise careful design will be shot full of holes.

If you’ve never bothered to consider what information the shipping company wants, and you don’t have what they want, then you may find yourself with hundreds of orders (or worse yet, millions) with no way to fulfill them.

For instance, you may assumed a flat shipping rate or a rate scaled to the purchase quantity, but your shipping department may surprise you with extra charges for fragile items, hazardous chemicals, or biological waste.

Stakeholders who are affected by your site design but don’t actually use it themselves are sometimes called indirect users. Excellent usability means working for the indirect users as well as the direct users.

Business Goals
What are the business reasons for this web site? What’s the value proposition? How is the business going to determine whether the site was a success? For some sites, the evaluation is simply, “How much money did we make from customers of the web site?” In the large number of marketing web sites, the value is assessed based on indirect effects on purchasing, lead generation, and company reputation and valuation.

For many first-time sites, the criterion for success is that the business gains a better understanding of the role the Internet can play in its business.

In redesigning or expanding an existing web site (or developing a large initial web site), a cost justification is in order, without which the site is destined for failure.

Business goals have to be factored into consideration with user goals. For example, if usability goals aren’t tempered by business goals, the most usable e-commerce site is one where users get everything for free (it’s not only cheaper, it’s also a lot simpler)!

User Goals
Why will users come to your site? To be entertained or to get work done? To learn something or to create something?

To interact with other people or to avoid having to talk to one of your salespeople? Set up your initial expectations and refine them as you learn more about the users.

If you can’t think of a reason users would come, then they probably won’t. Some web sites try to lure users by providing portals or news, but if you can’t think of a reasons users would prefer your portal or news service over another source, then they probably still won’t come.

So consider how your service can be more useful – for example, greater relevance (e.g. local news), more up-to-date information, or easier use. Try adding value to your core services rather than throwing in unrelated extras.

Report This Post

Determine how well the site needs to work for users. Consider how often they’re likely to come to your site and how much time they can spend there.

Based on that, how much time can they afford to spend learning how to use your system? How many times can they afford to make mistakes?

If they get confused, will they simply leave your site and never return? How impressed do the users need to be? What activities do they need to perform? How often do they need to come back? These questions will be elaborated as you learn more about your users. Below are some common types of usability objectives that may apply to your site:

Category   
Learning time/task time  

Examples of Specific Objectives
Users will be able to use this site the first time without any training. First-time users will be able to find their topic of interest within two minutes of visiting the site; expert users (5 or more visits) will be able to find a topic within 30 seconds.

Category
Number of errors 

Examples of Specific Objectives
Users will not visit more than three incorrect pages (on average) in completing a task.
Users will make no fatal errors at least 99 percent of the time (such as entering an incorrect credit card or shipping address).

Category
Subjective impressions 

Examples of Specific Objectives
On a scale of 1 (really appealing) to 7 (really unappealing), users will rate the site at least a 2.5.

Category
Accomplished tasks 

Examples of Specific Objectives
At least 75 percent of users who add an item to a shopping cart will complete a purchase.
At least 95 percent of users who complete their credit card information will complete a purchase.

Category
Revisits 

Examples of Specific Objectives
At least 50 percent of registered users will return to the site at least once per month.

Don’t be overly simplistic or unrealistic in setting these objectives. A three-click rule is a popular target (the user should be able to get to any page within three clicks), but it’s not a realistic objective for large sites.

It’s good to minimize the number of clicks users have to make to get something done, but it’s more important to consider how long it takes them and how many mistakes they may make than to worry about the specific number of clicks. Similarly, it’s good at aim for fast downloading of pages, but you should be realistic about how fast they can possibly be.

Report This Post

To develop a user profile, you need to find statistics on what your users are like and how they vary. A survey is particularly effective at developing this kind of demographic information. Some of the common ways people vary include.

Market segment: Age, gender, education, occupation, hobby, or income
Disabilities: Visual, hearing, movement, or cognitive impairments
Experience level: Computing, intent culture, subject domain

These different types of audiences will influence the selection of content and functionality for your site, the way text is worded, the appearance of your site, and the level of simplicity of your design.

These choices will be based both on the preferences and interests of your target audience and their needs and abilities.

A straightforward example is designing for children: a heavier emphasis is needed for imagery over words, simplified language is needed, the complexity of the screen layout should be reduced (with a realization that an unbalanced display may easily pull a child’s attention in one direction or another), and the topics must address issues interesting to kids (who really don’t want to hear about retirement planning).

Disabilities
Around 22 percent of the U.S. population has some kind of disability Addressing the accessibility of your site potentially expands your audience significantly, increases user satisfaction, helps to comply with legal regulations regarding accessibility, and avoids unnecessary discrimination.

The dominant standards for accessibility in web design are currently established by the W3C (www.w3.org/WAI).

Several tools are available for evaluating your web site in terms of access for users with disabilities.

For example, Bobby is a web tool that provides detailed suggestions for improving your site (www.cast.org/bobby), and RetroAccess is a commercial product that identifies accessibility problems and helps guide you through their repair (www.retroaccess.com).

Some Typical Guidelines
Most current accessibility guidelines are focused on the contents of people with visual impairments and those with motor difficulties that affect their ability to type or position a mouse pointer precisely. Among the guidelines are the following:

• Avoid using color to make meaningful distinctions between items because of the prevalence of color blindness, especially red-green color blindness (8% of men and 0.5% of women in Europe and North America are color-blind).

• Use high contrast and highly legible fonts to help those with even minor visual impairments. Allow the user to control fonts and font sizes for optimal reading.

• Make sure all graphics and other multimedia elements have text equivalents so that people who are blind can hear descriptions of them with a screen reader.

• Don’t rely on spatial relationships to make the text sensible. For example, don’t refer to “the column to the right” or “the button below.”

• Avoid uses of DHTML or Java, such as rollovers and nonstandard pop-up menus, that make it difficult for screen readers to interpret where the buttons are or what text is displayed.

• Avoid using small graphics as buttons and make sure small buttons are spaced well. Young children and people with arthritis will often have difficulty targeting small regions and may hit the wrong button if buttons are too close together.

• Avoid requiring typing when selecting a button or link will do. Avoid requiring the user to switch frequently between clicking and typing.

• When you are using audio or video, provide closed captions or other text equivalents of the audio for the hearing impaired.

• For the cognitively impaired, minimize the need to remember items between screens. Use simple, direct, concrete language. Expose the document structure as much as possible.

Accessibility Helps Everyone
Some types of disabilities are so extraordinarily common that most people do not classify them as such, despite the fact that they have an enormous impact on design.

While relatively few people are blind, an enormous number of people have imperfect eyesight and benefit from larger graphics and higher contrast.

A report from the U.S. Census tabulates the distribution of disabilities among, people 16 years and order. Notice that nearly 22 percent of all people report some type of disability.

And while relatively few people have severe motor impairments, clicking small buttons and navigating multilevel menus can be difficult for small children and for those with arthritis.

Many people also suffer occasional temporary disability (a broken wrist, a swollen eye) during which accessibility is much appreciated. Similarly, users may encounter situational disabilities in their everyday experience.

Situational disabilities are those challenges caused by imperfect situations factors, such as having to reach around a desk awkwardly to control the mouse when standing up, giving a presentation in an unfamiliar room, or being in too much of a hurry or having other problems on your mind that make it difficult to concentrate.

In each of these cases, people appreciate the fact that fonts can be made large, buttons are large enough to press easily and difficult to press by mistake, pages load fast, and the interface doesn’t require a lot of mental overhead. In addition, noises in the workplace or silence in the workplace (such as a library) may mean that people can’t use any audio, and alternatives to audio are helpful.

Accessibility Standards Are Only a Starting Point
Many typical guidelines for accessibility stress the use of standard technologies or recommend providing standardized fallbacks when using nonstandard technologies. In particular, most advise following HTML standards strictly.

Unfortunately, the real world is rather messy, and most web browsers do not follow HTML standards exactly, making strict adherence to the standards sometimes less accessible in practice.

The only certain way to ensure accessibility is to follow the recommendation as well as possible and then test the site with users with disabilities.

Report This Post

Users’ hardware and software configurations vary widely. Despite noble attempts at making web technologies transparently cross-platform, platform differences still play a significant role.

Hardware and software configurations need to be carefully sampled and tested. Hardware may be one of the easiest things to control for when designing intranet applications, but even the, be sure to verify your assumptions by visiting actual users sites to see if they have the hardware and software settings you expect.

Identify all platforms you need to work well on, and test them thoroughly. Consider even relatively small populations, and make sure your site works adequately, if not elegantly, on less pervasive platforms.

A common surprise is with screen resolution. While many users own machines that are capable of higher-resolution display, they often leave their computer configured at a lower resolution because either they don’t know how to change it or they actually prefer the larger, easier-to-read fonts.

Why Don’t They Upgrade?
From a developer’s point of view, an ideal situation would be one where every user has the same hardware and software and the most advanced possible versions. This reduces testing and enables the developer to rely on the latest technological capabilities. However, that simply isn’t realistic.

The Problem: Users Actually Are Using Systems and Settings That the Designer Consider Non-Optimal

We often get asked: Do any users actually have 640 x 480 monitors? Do they still turn images off? Is it realistic to think that users turn off cookies (after all, if they did, they wouldn’t be able to use many sites on the web)?

The answer is yes, yes, yes. Are such people just extreme examples? No. They’re everyday normal people who have valid reasons for their situations. Hasn’t everyone loaded all the plug ins? No lots of people haven’t.

The Solution: You Can’t Change the Users, so Understand Them and Design for Them
Don’t rely on your intuition for information about users’ platforms.

Find the current data. If only 40 percent of potential users have the plug-in you need, then they probably don’t want to use up their hard disk space or destabilize their computer system, or maybe they just aren’t interested.

Are they wrong or just stupid? Probably not, but even if they’ve made the wrong choice, are you going to start a lonely crusade to upgrade all the hardware and software used throughout the world? Hopefully not.

Watch the trends, and design for the level of adoption you expect to be valid when your web site is launched.

You’ve Learned Everything, but Newbies Abound
We get asked: Isn’t such-and-such technique a web convention? Isn’t everyone familiar with these yet? Actually, something may be a convention, but at best that might mean that 5 or 10 percent of web sites are applying the convention.

Besides, most people online are relative novices. Why? Exponential growth – the number of people online is still growing at an exponential rate, and as long as that remains true, many new people who don’t know how the Web works will continue to come online.

Low-End Use Is Counterintuitive To High-End Users
For those of us who have been online for what seems like our whole lives and who buy all the latest hardware and software, the practices of low-end users can sometimes be hard to believe.

Designers and developers need user studies precisely because they’re too expert to form reasonable assumptions of what the users are like.

Hardware and Operating Systems
While the Windows PC is the most common platform, consider which other platforms play a significant role in your target population.

While certain industries may have very little Mac usage, Macs have a higher market share than average among home users, and in markets such as education, graphic design, and video.

Unix and Linux users are relatively uncommon, but they should be considered when targeting technical audiences, such as IT workers and web developers.

As you’re testing these platforms, be sure to consider earlier versions of the operating systems, as a large fraction of users will not have upgraded to the latest version.

For example, when testing for Windows, you should test Windows 95, 98, NT, ME, and 2000. Unfortunately, the same browser often works differently on each platform, so every combination needs to be tested.

Common differences between PCs, Macs, and Linux/Unix include default font size differences (and differing interpretations of font specs), color calibration, level of support for plug ins, minor variations in browser implementations, and differences in how form elements and other widgets work (e.g., if you spawn a new window, make sure all the window controls, such as a close box, work as expected on all platforms). For an example of how a single site can differ on different platforms.

Other platforms to pay attention to include Palm OS, WebTV, and mobile phones. Most of these individually represent a very small target population, but internet appliances and mobile devices are becoming increasingly popular, and for some domains may represent a highly desirable target audience.

In most circumstances, no single-platform among these can justify the cost of a custom site design, nor are they sufficiently standardized to give detailed design suggestions that will work for all of them.

Generally, to work well across a broad set of devices, you should design according to well-established standards, avoid novel technologies, depend primarily on text, keep the content as concise as possible, and avoid altering defaults such as fonts and background colors (or use style sheets to do so, but realize that many users won’t know how to override a style sheet they don’t like).

Where you intend to target a specific platform, such as WebTV, specific design standards are sometimes available from the manufacturer (e.g. see WebTV guidelines at developer.webtv.net/design/).

Monitors
Monitor sizes vary dramatically and can create significant design difficulties. Monitors vary in resolution (common standards are 640 x 480,000 x 600, and 1024 x 768, but the resolutions are setting much higher) and in color depth (from black and white to grayscale, and from 8-bit to 32-bit color). Don’t rely on users having the latest high-solution system.

At the same time, it’s nice to give users with a high-resolution seen the ability to take full advantage of their systems.

We’d hope that users with two-page displays would use the extra space for a second browser winner or another application, but users quite often maximize their windows and grow frustrated if the design, created for a smaller screen, fills up only a function of their screen.

Users with 8-bit color monitors will get a different set of 256 colors depending on their platform.

Therefore, pages can be designed using only the colors in the web-safe color palette, a subset of 216 colors that displays fairly reliably on all 8-bit platforms, without dithering the colors or mapping them to unexpected colors.

Web-safe colors were previously a critical design criterion for web designers but are becoming relatively unimportant as the number of users with 8-bit color is dwindling, and because using non-web-safe colors compromises visual quality but rarely interferes with usability (except when legibility of text is compromised because of dithering).

Browser Differences
Browser variation is extraordinarily hard to keep up with. While the vast majority of the browser market is held by Internet Explorer and Netscape Navigator, the variations among versions of these browsers demand lengthy testing.

When writing HTML, you need to consider backward compatibility with older versions of HTML, but you also need to consider how HTML standards are likely to evolve in order to avoid writing code that won’t work in future browser releases.

In addition, while you can write to fit the formal specifications of these browsers, you also need to work around lesser-known browser bugs.

Testing is essential or you’re likely to build a site that fails in unexpected ways. When testing your code in different browsers, write down the name of the browser, the operating system, and the browser version, as well as any nonstandard user settings.

This way, when a problem comes up later, you can check whether it should have been spotted in the version you tested, or whether you should have been testing a configuration you weren’t. For instance, during testing, write down the browser tested in a quick shorthand like

NT: E4.0, E5.0, N4.1, Opera3.0
Mac: N4.7, E5.0, iCab(beta)

Browsers often vary in how they handle aspects such as proprietary tags, horizontal rules, margins, link colors, and table formatting. And while conventions exist for how tags such as <blockquote> or <strong> are implemented, individual browsers may display them in a unique way of allow users to set their own format. So, although <blockquote> is normally used to indent a paragraph, an old version of Explorer displayed block quotes in italics.

The only way to rely on how the tags in the way expected is to conform to the standards specifications as closely as possible. Don’t depend on any display characteristics that aren’t spelled out in the standards.

Even so, the standards may not be implemented correctly, and testing remains the only way to verify compatibility.

Network Differences
Slow download time is one of the most frequent usability complaints. Slow pages will drive users away. Users may have 288.8 – 56K modems, ISDN. DSL, cable modems. T1 lines, or other broadband services.

Low-bandwidth modems are still common, in homes and in small businesses, so optimize your site for slower modems, and test from home rather than in a high-bandwidth development environment to get a feel for the user experience.

Report This Post

While users from the United States represent a large proportion of users on the Internet, this is changing over time, and even from the beginning, the Web has been international.

Sites that do not even intend to cross national boundaries will find by examining their hit logs that they have quite a few international users.

Different countries and cultures use different languages, different units, different symbols, different currency, and different conventions for all sorts of things. Even countries that share a common language can have differences in dialects and differences in standard practices that can cause confusion.

What Country Is This?
Since users may be coming from absolutely anywhere, be clear when you are targeting a specific local market.

If you have no interest in users outside your geographical region, or if you know you aren’t interested in a certain audience, you need to indicate to such users that this site is not for them.

This is usually as simple as making your location or target market highly visible at the top of each page.

Include the country in your address, and include international codes in the phone number. For example, a U.S. phone number should include a + 1 as the country code, as in +1 (734) 665 – 9307.

An exception to this rule is U.S. 800 numbers, which are not available internationally, so should not include the country code. If you are expecting many international visitors, be sure to comment that the 800 number is “(U.S. only).”

Language
You may choose to write only in your native language, provide access to multiple-language translations of your site, or provide your site in a common international language, such as English or Spanish. Writing direct and simple text, without too much idiom, slang, or metaphor, will help nonnative speakers read your text.

When offering multiple languages, avoid using national flags to identify each language. Some languages are spoken in a variety of countries, and many countries have several different languages.

Thus, flags can be ambiguous about which language they represent. Also, when a language is spoken in multiple countries, you face the daunting challenge of deciding which country’s flag is the most appropriate to represent that language without making other countries feel excluded.

In general, rather than using flags (as the Disneyland site in does), you’re much safer to simply state the name of each language in its native tongue “English Frangals Espanol Nihongo.”

Units
Use metric units when it makes sense, but for many common uses, especially when targeting the U.S., a local unit needs to be used, as in. Provide metric equivalents when you can, but if your primary target audience uses local units, at least provide a link to a table of conversions.

When the unit is ambiguous, be sure to specify the relevant measuring system – certain units, such as a pint, can represent different amounts in different measuring systems.

Currencies
Be sure to include currency units on prices. The same currency symbol, such as the dollar sign ($), may be used in multiple countries, so it’s a good idea to provide a country indicator to clarify which currency you’re intending (e.g., “US$”).

Remember that exchange rates change quickly, so you’re best off leaving conversions to the user rather than computing them on your site (unless you have live access to the latest rates in your back-end system). Give the user a link to a current rate chart if you expect it to be needed as in.

Symbols
Use religious and political symbols only after very careful research into their appropriate usage. Symbols of any kind are culture specific. Even color represents different meanings in different meanings in different cultures.

For instance, white is a color or weddings in some cultures and for funerals in others. Red is a color of celebration in some cultures and violence in others.

So avoid using color as a symbol, and avoid using color a specific differentiator of categories. Also avoid using human facial expressions or hand signs as icons. Hand signs, in particular, have many different interpretations throughout the world.

Date and Time
Date formats vary throughout the world. For instance, September 11, 2001, may be written as “11 September 2001,” “9/11/01,” “11/9/01,” or “01/09/11,” among other variations, and that’s considering only the variations of order, lot of punctuation. To clarify dates, a good approach is to spell out the month and use a four-digit year, as in “11 September 2001.”

It is extremely problematic to specify a particular time to people in multiple time zones. If you must do so, be sure to include the time zone, although many people will not recognize time zones (and giving the offset from GMT is a lot of work to decipher even for those people who understand it). Include an “a.m.” or “p.m.” if the hour is 12 or less, realizing that 24 hour time will confuse many U.S. readers, and 12 hour time will confuse many people who expect 24 hour time.

Times are best avoided entirely, but can be unavoidable when scheduling some events. When possible, a reasonable solution is to dynamically provide the time in terms of an offset from the current time, as in “The live broadcast will begin in 3 hours and 45 minutes.”

Report This Post

Users may set their browser preferences to all sorts of odd settings, which can baffle the designer. Fortunately, most users never change their preferences at all, so it’s fairly safe to do the majority of your testing with the default browser settings.

Nevertheless, a few settings are changed quite often. Some of these settings may be dictated by corporate requirements for convenient system administration or security standards, so users may not be able to change them to your preferred settings even if they want to. Preferences that can be changed by users include the following.

While the typeface itself isn’t changed often, the font size varies widely among users and platforms. Available typefaces will depend on platform and which typefaces users have installed.

Link colors: Fortunately it doesn’t happen often, but users can change the default colors of links and can turn off the underlining of links.

Image-loading: Users with slow connection speeds will often avoid loading images.

Plug-in: While the percentage of users with standard plug-ins like Flash, Acrobat Reader (for PDF files). RealAudio, and Quicktime is increasing, many still don’t download them in order to avoid lengthy download times or bloating them systems.

Enabled features: Users may turn off Java, JavaScript, cookies, and other features for security, speed, or personal preference.

Web sites that require users to have specific plug-ins can create a system administration burden for them, since they must monitor plug-in versions and maintain and replace them as they upgrade their system or move from one system to another.

Try to minimize reliance on plug-ins; when you do use them, strive for compatibility with multiple versions, to minimize the burden on your users.

Similarly, it makes little sense to tell users to change their browser settings to conform to your site. This places the burden of ease of use on the user, which is hardly user friendly.

Report This Post

One of the biggest challenges in web design is developing for the wide diversity of users, user preferences settings, hardware and software platforms, browsers, and network speeds.

While it’s impossible to create an optimal design for everyone, you’ll need to decide how well you want your site to work for each segment of the target population.

When designing for diversity, several options are available that make tradeoffs between cost and the quality of the design for various user segment.

Our compatibility philosophy is that we want our designs to work great for most people and effectively, if not ideally, for most of the remaining people.

We recognize that some small segment of the target population is bound to have a less than-satisfactory experience, but we want to keep that to as small a percentage as possible.

Perhaps less than 2 percent is a realistic goal, but this cutoff will depend on the scope of your project and budget and the impact of tailing to serve a given target population.

When you’ve decided who you’re not going to please, that needs to be part of the documentation of your target audience. Choose this group carefully: for what group of users is it okay for them to say, “Your site jut doesn’t work for me”?

For some markets, you may have a sufficiently well-defined and homogeneous target population that you don’t need to worry about significant variation.

For example, when developing intranet applications, you not only know exactly who your target users are, but you may be able to require that they use a certain platform, enabling you to rely on a wide range of assumptions that considerably simplify design.

In considering each type of variability – computer users, hardware and software platforms, browsers, and network speeds – it’s a good idea to keep track of the latest available statistics.

Unfortunately, no single source of statistics produces good data on all these factors, so you’ll need to seek out multiple sources.

Up through 1998, one of the best online surveys was the GVU survey (GVU 1998), which has unfortunately been discontinued. You can also track some types of stats, such as browser types and operating systems, using your own server logs.

2 + 2 Is More Than 2
Suppose you decide that your site doesn’t need to work browsers having 2 percent market share or less.

That doesn’t mean that your site will work for 98 percent of browsers. Rather, it perhaps means your site will work for fewer than 95 percent of browsers, because several different browsers have less than 2 percent market share.

Then perhaps you decide it doesn’t need to work for visually impaired users (3.5%) or for non-English speakers (say, another 5%) or for people with small screens (640 x 480 or les, which is, say, another 10%).

In each case, it seems that very few users are being excluded, but when you add them all together, you’ll soon find that your site doesn’t work for 15 percent of your potential customers.

Excluding so many people from your web site is as arbitrary as excluding people from your brick-and-mortar store because they aren’t driving expensive cars. (“Dear customer, If your car is more than three years old, please upgrade it at your local auto dealer and come back when you’re done.”) It makes for fewer sales and bad customer service.

Report This Post