Technology x User Experience
Posted by Silvia | Filed under Usability, User Experience
By Silvia Reitsma
My mother never liked that much to read manuals or to learn to operate electronic equipments. I thought it was really great she got to use a cell phone and I was even more surprised when I asked the phone number of my aunt and she said: “Wait, I will check my cell phone.”
I thought she had learnt with someone how to save the numbers in the phone’s memory, but she just came back with her phone completely covered with post-it notes with her most dialled numbers.
Usability Testing
Posted by Silvia | Filed under Usability
By Elizabeth McLachlan and Leanne Waldal - View Article
Usability testing, like any component of development, involves a certain amount of planning, thought, process development and execution. Encouraging and delivering a well-delivered process and execution for usability testing can help bring usable products to intended consumers.
Whether your organization conducts its own usability research or an outside agency handles it, each key person should be concerned with the process of conducting usability research.
Although we cannot exhaust the subject of usability research or testing here, this article offers up some topics of consideration and steps to follow when conducting usability research. You can make the following assumptions when reading this article:
- The particular focus of usability is on that of the user interface or design of a web site or software application.
- Our style of usability testing is qualitative in nature, gathering data from actual users though successive, in-person, one-on-one interviews.
Part I: Planning your usability test Step 1. Start thinking about usability testing.
Usability testing should be a part of product development. Adding usability testing to the development process at the beginning of development will aid in the execution of usability testing. Devote ample time to determining a product’s usability before you release it to the world. The expectations of usability testing should be determined in the process plan. Set the expectations of the product’s usability ahead of time, involve key players and bring in the decision makers. Finally, set a schedule for each step in each iteration of user testing (see a sample schedule of one iteration).
Step 2. Define the audience and the goals of usability testing.
Once the usability testing phase of product development begins, you’ll need to define or redefine the audience demographics. Determine who will use your product, what their specific demographic characteristics are and how best to approach the testable individuals. Ideally, every product has a viable and definable target audience (why wouldn’t it?), so that product should be made usable for the intended audience. The goals of usability testing should therefore be focused on determining whether this interface is usable and whether the intended audience, and anyone else who might come in contact with it, can use it. The needs and desires of the intended audience often drive the goals of usability research.Defining the goals of usability testing isn’t always as simple as addressing the most obvious things, such as “can they use it?” or “do they like the colors?” Other goals often address perceived usability problems for existing products, such as installation instructions, site drop-offs or customer complaints. For online stores, most existing site stakeholders are concerned with users dropping off at certain points in the shopping or checkout process.
Develop your goals for the usability testing project by asking these questions:
- What should the intended audience be able to get out of the product?
- What do you want to know about your product?
- What do you already know about the usability of your product?
- Where are the known problems, issues and bugs? In particular, are there any issues that won’t be resolved before you launch?
(A more extensive list of questions appears here.)
Perhaps this is the first question you should ask:
After you determine the goals of your usability test, turn them into a test script—the guide to be used by the moderator when interviewing potential or existing users. The test script is a critical step for getting good data. It should be written as though it will be read aloud to the testing participants. When writing the test script, you should include not only all the questions about the product’s usability, but also any statements, phrases or verbiage that will actually help the person being interviewed.The participant needs to be the focus of the test script. The questions asked, tasks presented and opinions sought should be written and spoken in a way that allows the participant to feel as though they are contributing to the project, rather than being tested by the moderator. When asking a participant how they would add something to their online shopping cart, check out and complete the order process, the task should not be a test of the participant’s ability to use the computer to check out, it should be a test of the checkout process itself.Before asking questions regarding the product, your test script should start with information to help participants understand what it’s all about:
- Explain why the participant is there.
- Recap what the non-disclosure agreement means.
The script should ask participants questions about themselves to make them feel comfortable and help set the tone for the interview. Using questions where the answers are already known—such as “How long have you been using the Internet?” or “What kind of computer do you have?”—will help users through the remainder of the session. Questions about the product’s usability should not be a series of yes/no questions, nor should they be interrogative in nature. If they are, you won’t get any good data because users will feel uncomfortable.
The format of the test script should include qualitative questions and directed tasks regarding the product. Give users tasks to complete and ask them questions about what they’re seeing. Here are some examples:
- Do you like the colors?
- Can you read the text?
- Where would you click to get information on the company?
- You’re being shown a list of steps to complete the installation of the product. Could you read that list and tell me if the instructions are clear? Do they make sense? Do you know what you’re supposed to do next?
- Why are you being asked to register?
- Could you please show me how you would buy [name of product]?
- How did you feel about that order process? Was it easy? Hard? Did it take too long?
The final step in the test script development should include a test drive that’s conducted with the most key player in the organization concerned with the product’s usability. This could be the information architect, designer, developer or marketing manager. The test drive helps determine the organization of the test script, length of the test, flow of the questions and scope of the usability research.
In addition to writing a test script that works well for the participant, please keep in mind that participating in a usability test can be a nerve-wracking experience. Participants arrive at a place they’ve probably never been to, they’re asked to sign non-disclosure agreements, they’re brought into a somewhat sterile environment and then they’re sat down with a camera pointed at them. They usually figure out they’re being watched, too.
Step 4. Recruit your users.
This phase of usability testing can be conducted in conjunction with your script development. Look at your intended audience and fine-tune it based on the logistics and practicality of the usability testing. For example, if user testing takes place in San Francisco, you’ll probably only want to recruit participants in the San Francisco Bay Area.Figure out also how many participants to interview. Although this topic is often debated in usability circles, we recommend no fewer than eight for any usability testing project. Five users help develop trends in a product’s general usability as reported by the participants, and three more help qualify those findings. So eight is the bare minimum.
Develop a screener that helps you find the participants you want. If you make it broad or too vague, you’ll end up spending more time weeding out inappropriate respondents. Use the screener as an e-mail message or phone script. Examples of screener information/questions include the following:
- Name
- Phone number
- E-mail address
- Age (or age range)
- Income level (or range)
- Do you use a PC or a Macintosh?
- What is your connection speed?
- Job title or occupation
- Do you use [name of product] for your job?
- How long have you been using [name of product]?
- Have you used other similar products? If so, which ones?
Recruit users far enough ahead of time to allow for cancellations, schedule reorganizations and for any focus changes. Allow enough time to get at least three times the number required for your usability testing project. By doing so, you’ll weed out many respondents. Receiving a good number of responses gives you the luxury of picking and choosing appropriate participants for your study.
Part II: Conducting your interviewsNow that you’ve finished your goals, test script, test drive and recruiting, it’s time to test. The moderator should be comfortable, healthy, focused and mentally ready for a day or two of usability testing sessions. Things to keep in mind when moderating and gathering data include the following:
- Set up and conduct interviews in a comfortable space. Make sure the room is quiet and private. Provide snacks and beverages. You may want to use contextual spaces such as an office environment.
- Set up the video equipment correctly. The user should not be staring down the camera’s lens. The video camera should not be pointed at the screen, either. Use an angle that incorporates the screen and some part of the user. You may wish to consider picture-in-picture videotaping.
- Be aware of the time. Interviews should last their intended time and not much longer. If the session lasts too long, the user will be become agitated or bored.
- Stay flexible. Don’t go into “clinician” mode. Users are unique and the moderator should do his or her best to be comfortable so that the comfort level and ease are conveyed to the participant.
- Don’t place any importance on one user. One participant may present the most compelling data about your product. However, one user’s comments will not solve a product’s usability. As exciting as the user’s comments may be, stay focused on each user’s comments.
- Be opportunistic. If a participant says something interesting or compelling, ask them to clarify it. For example, if a participant says “I didn’t see that. Why is it over there?” when probing the interface, ask where they think it should be. Seek help from their expectations of the interface. Similarly, if a user hesitates it often means that something is confusing or unclear (unless they’re reading!). Follow up on these hesitations by asking if the information makes sense or if they know what they’re supposed to do next.
- Take notes. For many user testing projects, employ a separate note taker to observe the user testing sessions. We recommend that the moderator be the primary note taker. The moderator is the person who interacts directly with users. The data that the moderator gathers is possibly more valuable than other data (such as a note taker one step removed from the interview or the videotape itself).
- Be attuned to observation bias. Users are being tested and want to give the “right answer.” Let users structure tasks whenever possible. Encourage participants to talk freely.
- Respect participants. Be patient and considerate. Keep in mind their confidentiality as well as the product’s. Makes sure users know that the information they provide is confidential. Make sure they know that their information will not be provided for any further purpose beyond the session. Remember to thank them for their participation.
Between sessions, take time to think about the data that the user provided. Organize your observations toward an analysis of the results. Remember to get all the data from the participants before making any final determinations.
Part III: Organizing data, analyzing data and presenting your findingsAfter completing the sessions, review the data and make a list of the top issues you discovered. From there, start flushing out the usability concerns and the recommendations for improvement.When analyzing your results, keep the users’ comments at the front of the analysis. It’s too easy to incorporate your own biases and expectations here. Try not to do so. Marry the users’ comments with the analysis. To illustrate:
- Observation: Five users tell you that the search box is in the wrong place on the page because they don’t see it. Two of them say the colors are too similar to the rest of the page; two of them don’t see it because it’s in the lower-right corner of the page.
- Correct analysis: Because the users report that they cannot see the search box, it should be moved to a place on the page where they can see it. The designer may want to rethink the colors used in that area as well.
- Incorrect analysis: The users are simply not accustomed to the placement of the search box, but after using the site for a certain amount of time they should become comfortable with it.
Pay attention to patterns. After a few interviews, you may receive very similar information regarding the product. It’s important to notice these patterns, along with any deviations from them. If four of eight participants believe the text in the content area is easy to read, but the other four complain that they cannot read it, you should investigate further and analyze what specifically they could not read and why. Was the font size too small? Did those four complain about other text on the page? Were those four trying to get through the task (too) quickly?
Keep a perspective. Remember that even if the data gathered consists mostly of complaints about the interface or design, those complaints can help. Don’t take it personally and don’t negate the comments. The users, no matter how cynical or whiny, provide the most useful information for the product’s usability.
Present the results to the key members of the product’s development and ownership teams. Keep in mind the audience for this presentation. Remember their goals as well as the product’s, along with the original goals of the usability project. Make recommendations based on the findings and help provide positive information wherever possible.
As you’ve probably figured out by now, conducting usability tests takes time. Executing a well conceived and well though-out project will help you get great data and hopefully improve the product’s usability. Careful considerations towards a product’s goals and the intended audience(s) need to be made before designing and planning usability testing. Comments and feedback provided by user testing participants can really make the difference in a product’s usability. There really is no substitute for direct user feedback.
Design starts with Proposition (ergo Usability)
Posted by Silvia | Filed under Usability, User-centered Design
by Leisa Reichelt - View Article
Here’s a typical story.
A project is in its final phases when it gets to the part of the Gant chart that says ‘usability testing’, and so they do.
People come in and are asked to perform tasks, and so they do, with greater or lesser degrees of difficulty. And yet, something else is wrong.
It’s not so much that they *can’t* use your website, it’s just that they don’t want to.
People ask me all kinds of questions about usability. What are the most common usability problems? What’s the best way to make sure our site/application/system is usable? That kind of thing.
It’s pretty clear when they ask these questions that they’re thinking on the presentation layer. Is that button in the right place? Is it big enough? Has it got the right label?
Now, don’t get me wrong, the presentation layer is important, but it’s not the biggest usability problem I see in my work. The biggest problem is that you’re designing something that people don’t care about. You’ve got your proposition wrong.
What’s your proposition? Well, basically it’s the value you’re offering to your customer. Are you offering something they want? Are you solving *real* problems for them? You’d be amazed how often this is not the case, and how often people don’t know about this until they’re about to launch their product or, worse still, once it has launched and is failing.
The diagram above is one that I pull out fairly often these days (it’s another one I’ve borrowed from Flow). It talks about how you need to design from the proposition down. You need to get the value offering right, then look at the model for delivering that value to clients at a conceptual level, then start looking more at what elements go on a page, what functionality is included, how it is structured and ordered. Unless you have all of these in order, it doesn’t really matter where your buttons go or what they’re labeled. Appearance level usability is the most superficial, easily remedied and perhaps even least important of all of the levels of design.
If you’ve got a flaw in your thinking at the top of the chain, then no amount of surface usability is going to save your product.
So, how do you approach this kind of Proposition design and usability? It’s pretty simple really, you test your proposition. This kind of testing (or really, research) is more about talking than tasks, and it’s about understanding your customers better and checking whether you are conceptually on the same page as they are.
I’ve been involved in several projects just in the past twelve months where doing this kind of research has saved companies tens of thousands of pounds (double that if you’re talking dollars) in *not* designing and developing functionality that either was unwanted by their customers or was designed to solve the wrong problems.
Working this out when you have a few pencil sketches or a couple of visio wireframes with a few days invested is an awful lot better than working it out when you get to the ‘usability testing’ line in your Gant chart.
So, if you really want my advice about usability, it’s that it starts right at the very beginning. Before a line (or a box) has been drawn. If you’re not designing the *right thing* then no amount of design expertise is going to get you a really usable product.
Talk to the people you’re designing for.
You’ll save lots of time and money and look really smart.
Amen.
Paper prototype
Posted by Silvia | Filed under Interaction Design, Usability
By Silvia Reitsma
Even the smartest people make faults. This is particularly true for project teams. As a project advances, assumptions and well-meant but poor decisions build up, turning hours of effort into a poor user experience. Intelligent teams reduce their faults by means of a procedure called UI prototyping. Combined with usability tests, prototypes help teams to keep on the right track.
There are quite a few expertises and tools which can be used for creating prototypes. Think on the kind of design you’re wanting to make a prototype of and the objectives of your prototyping work as you choose what for expertise or tool is good for you considering their advantages and disadvantages.
Paper is often used in rapid assessments and the quickest way to prototype a design proposal. Using a drawing tablet, Photoshop or any tool you are comfortable with, produce screens that express the design, and print them out on paper. You can simulated walkthroughs If you make enough screens, verifying if users make the right decisions concerning the navigation flow and experience the design. Though, for prototypes of reasonable intricacy, producing paper prototypes can be awkward. Projects which involves a high level of interactivity as chat rooms or games are not suitable to be reproduced on paper.
Paper prototyping is the perfect method for recognize common complex problems that can ruin websites. It takes only 5-8 possible users to identify mistakes and prevent more than 80% of them to happen:
Layout
Hand-drawn prototypes let users give a broad range of responses. They can help you conclude if pages have too little or too much content, and if the common layout of the page is efficient.
Navigation flow
It is a good way for testing a website’s navigation flow. Users can help you decide whether the website’s structure is intuitive and whether the terms used in the navigation is logic.
Interactivity
By offering users mock-ups of your website’s interactivity, you can see if the planned functionality will be exploited and appreciated by users.
For example, it can assist in verifying if a determined tool will be used successfully by users.
Content
Paper prototypes are an ideal technique to check the efficiency of your website’s content. You can discover if the content and writing style is suitable for the intended users. Users normaly help finding out if there is content missing, imprecise, or pointless.
When to prototype?
Depending on the range of the prototype and the level of necessary details, prototypes can be made at any time throughout the project. Normaly prototypes are developed in the beginning of the project, in the specification phase, before developers produce any code. That is the phase when investigation is necessary and when the time investiment is still plausible.
Who framed the web: Frames and usability
Posted by Silvia | Filed under Usability, Web technologies
By Roger Johansson - See Article
Back in the nineties, using frames to split a browser window into several independent parts was very popular. Much due to the increased awareness of usability and accessibility over the last few years, frames usage is not quite as widespread as it used to be. However, frames can still be found on many sites, especially those that haven’t had a major overhaul in a while.
If you spend most of your online time reading blogs, you hardly ever come across any sites that use frames. That’s good, considering that blogs are typically very rich on information. I don’t miss frames at all, and it’s been years since I last used frames myself, but recently I asked myself what the problems with frames are, and if there are occasions where the pros of frames outweigh the cons.
The problems with frames
The drawbacks are obvious to some, while others think frames have some things going for them. The problems I see with frames are mostly related to usability and accessibility. You may have heard of the problems before, but let me reiterate:
Frames break the unified model of the web. One of the basic principles of the web is that every page is represented by a unique URL – the page is the atomic unit of information. Frames break this fundamental principle.
Frames cause problems for search engine robots. While it is possible to provide workarounds that allow search engine robots to crawl a frame based website, those workarounds are still workarounds. There will also be problems for visitors that come to a framed site from a search engine. Those visitors are likely to land on documents that are incomplete when viewed outside of the context of the frameset they belong to. Crucial elements like navigational links may be missing, for example.
Some frame-dependant websites try to get around these problems by using the file robots.txt to tell search engines not to index sub pages. On other sites, JavaScript is used to prevent visitors from viewing any document outside of its parent frameset. Both of these methods – preventing deep-linking and disallowing search engines from indexing a site – may work, if the goal is to get fewer visitors.
Frames make URLs stop working. If a visitor wants to send someone the URL of a document within a frame based site, they can’t just copy the address from the browser’s navigation or location field. That’s the frameset’s URL, not that of the current document. It’s possible to extract the URL to a document within a frameset, but many people don’t know how to do that. Even if you do manage to find the document’s URL, it leads to an incomplete page, creating the same problem as when a search engine indexes a frame based site.
Frames break bookmarking. Most web browsers can’t bookmark a page inside a frame based website. When you open the bookmark, you will go to the default state of the frameset, which is usually the website’s homepage, and most probably not the page you intended to bookmark.
Frames make printing more difficult. Many visitors will have problems when trying to print documents. It’s common for browsers to require that you activate a frame by clicking in it (or tabbing to it) before you can print it.
Frames hurt accessibility. While the leading screen readers can handle frames, a frame based site is more complex, and thus more difficult to navigate in a non-graphical browser. For this reason, accessibility guidelines advise against using frames.
Frames increase technical complexity. Besides causing trouble for the site’s visitors, developers using frames make things harder on themselves. A frame based website is technically more complex, and more time consuming to develop and maintain than a site that doesn’t use frames. For example, something as simple as keeping the navigation system in sync with what’s being displayed in the main content area can get really complicated.
Frames
What about iframes (inline frames) then? Well, usability-wise they really aren’t all that different from normal frames. They suffer from most of the problems mentioned for normal frames. Iframes are probably slightly less complex to maintain than normal frames since they don’t need special frameset files.
There are also reports of potential accessibility problems with iframes, where under some circumstances an iframe grabs focus when its content has finished loading. This can be very confusing for someone using a screen reader, and can cause unexpected results when printing. I haven’t seen this occur in my (limited) testing, but it’s something to keep an eye on.
CSS based frame imitations
CSS can be used to imitate the look of frames. This will avoid most of the problems with real frames. However, it can also cause usability problems that are different from those caused by frames.
One CSS technique used for this displays a header and a footer in fixed positions, letting the whole browser window scroll when necessary. The main content area will then slide behind the header and footer. I’m not aware of this technique causing any serious problems.
However, when an inline frame is imitated by using the CSS declaration overflow: auto, printing the full contents of the “frame” becomes impossible in the browsers I have tested – only the visible part is printed. This can be circumvented by providing a print style sheet, but it’s something that you should be aware of.
Another problem with the overflow: auto technique is that in many browsers, scroll-wheel mice cannot be used to scroll the contents of a “CSS frame”. While this is not a huge problem for most, and probably something that should be fixed by browser vendors (Apple and the Mozilla Foundation come to mind), it is very annoying.
Frame imitations cause fewer problems than real frames, but you should be aware that there are issues. Those issues can be avoided by providing alternative style sheets, both for viewing and printing.
Frames and frame imitations aren’t always bad
You can probably tell by now that I am no fan of frames, iframes, or frame imitations. They do have their uses though. Frames can be useful for intranets as well as for applications like web based e-mail and content management systems, where most of the problems noted here are of little or no concern. On a public website, however, they cause too many problems and should be avoided.
Visual arguments for using frames
But if frames are so bad, why do they even exist? Well, because they were invented back in the nineties, when every new browser feature had to be used just because it was possible. The question should probably be “Why does anyone use frames on public, information based websites?”
In my experience, most of the web professionals that like to use frames are more visual design oriented than structure oriented. I don’t know if that assumption is true, or if it’s just coincidence. What I do know is that I’ve had plenty of clashes over frames with visually oriented designers wanting to confine a site’s content to a tiny scrollable area. Their reason for wanting to do this is usually a desire to keep the site’s navigation and/or “branding” always visible. Usability, accessibility, and search engine visibility are not on their radar.
I don’t mean that as a knock against all visual designers – I’m just bringing it up as an example of the attitude I’ve run into over and over, especially when working with designers coming from a print background.
Conclusions
To me there is no doubt that frames should be avoided for public websites. They just cause too many problems. For web based applications and intranets however, many of the problems mentioned are of less concern, so there are cases where frames can be useful. Think carefully before using frames though – ask yourself whether you really need them or if there is a better solution available.
As for CSS based frame imitations, my feeling is that those techniques can be useful, but should be used with care. Be aware of the printing problems they can cause, and don’t squeeze your content into a tiny, scrollable area just because you can. Remember that for most sites, people don’t visit just to admire the pretty design – they come looking for content.
The difference between Usability and User Experience
Posted by Silvia | Filed under Usability
by Jared Spool - See Article
© Copyright 2007 by UIE Brain Sparks
…
The customer, looking for a new digital camera, goes to the large electronic retailer’s website. She quickly finds the camera she wants, puts it in the cart, and without incident, pays for it using the option to pick it up at the store that same day. Quick, easy — she is pleased and excited to receive her camera.
When she arrives at the store, she initially doesn’t know where to go, as no visual clues present themselves. After a ten-minute wait at the customer service desk, she’s told she’s in the wrong place and needs to find another desk, this one labeled “Online Receiving”. Once she finds that desk, the clerk, who obviously can’t wait for his shift to end, sighs and says the camera she’s purchased is out of stock. She can buy a different camera at this point, but to receive a credit for her original online purchase, she needs to call an 800 number. She ends up leaving the store without a camera and a charge on her credit card she needs to resolve.
This scenario highlights the difference between usability and user experience — a question I get quite frequently these days.
Usability answers the question, “Can the user accomplish their goal?” In the case of our camera shopper, from the perspective of the site’s design, she did accomplish the goal, being very satisfied with the result.
User experience answers the question, “Did the user have as delightful an experience as possible?” The store portion of the experience canceled out the online portion.
If the online portion was the only thing involved, our customer would’ve been delighted with the results and likely shopped again. Because of the total user experience, she’ll likely resist shopping with the brand again.
In this organization’s case, the usability of the site involves only those people who directly influence the design of the site. However, to create a pleasurable user experience, we now have to involve people from all over the organization, including those people dictating how the store operations are designed and implemented.
User experience takes far more effort to do well, but the results have far better impact.
Simplicity
Posted by Silvia | Filed under Usability
by Oliver Reichenstein
Simple websites are easy to use, easy to understand, nice to look at. In practice, websites are either unusable or ugly and in general filled with too many complicated words. Why do designers have such a hard time to keep it simple?
Graphic design and usability, marketing language and user expectation are in constant struggle with each-other. Simplicity as a result of a creative process is “the ultimate sophistication”, as Leonardo da Vinci (1452–1519) said. Achieving simplicity is a difficult task not only in web-design but in every discipline (art, business, sports, science…), yet simplicity for websites is a particular challenge as paper derived graphic design and usability on one side, marketing language and user expectations on the other side are in constant struggle with each-other.
Graphic Design vs Usability
HTML and it’s table structure was not made to display graphics. First of all, HTML and it’s table structure was not made to display graphics. It was made for text only. So by it’s technological nature the Internet was against designers.
There is an unarticulated war currently raging among those who make web sites. This war is between usability experts and graphic designers.
Flash doesn’t solve this problem, it creates new problems. Flash is an alternative technology that is hard to use, hard to optimise for search engines, hard to administrate and even harder to combine with current components. Designers like flash, users don’t. However, no technology is bad as such. Of course, Flash can be very useful if used intelligently.
Things got better since table-less CSS. Things got better since websites are made in table-less CSS though, as CSS is made for and by friends of typography and graphic design. The conflict design and usability is not just a technical one.
Web-designers are confronted with a set of rules that websites have to follow in order to work, such as: - Links have to be recognizable either through being underlined or blue or super obvious - Logos should be placed in the upper left corner - Fonts should be big and scalable - Few pictures is better than many pictures - Few fragmented text works better than text-blocks - No columns for text, as websites scroll
Branding vs. Usability
The usability rules above lead to design rules that are different and in many ways stricter than the rules with paper based design. And, in many of those ways corporate design manuals clashed with these rules. Corporate identity was and often is still made by senior (old) designers that are not familiar with design on the web. Thus an important part of a corporate design is often missing and then poorly adapted from paper based design guidelines.
Branding vs. Usability = Identity vs. Conformity
The conflict between branding and usability is also a conflict between identity and conformity. Strong identities are first of all: different, recognizable, bold, successful websites tend to uniformity. Successful websites however manage to create identity through their interface.
Simplicity as unity of conflicting parameters
To create a unity between those principles is a particularly difficult task. On the other hand, brand experience online is essentially defined by the ease of use. If using a website is without problems, the user has a good brand experience. If on top the website is consistent with corporate design, you are right there. So basically,if web identity is part of the core identity development, there should be no conflict between branding and usability. Of course, whoever develops the on- and offline identity has to be aware of the characteristics of interactive media. In one word: Online identity is not a question of how big a logo is or where it is placed (this is almost a given), it is more a question of who you are and what you say, it is more a question of what words, what pictures do you use, than where you place them. And quite honestly, this is a measure stone for any corporate identity - on as well as offline.
New design rules
Creative people don’t like to be censored, yet few regulations incite more creativity than censorship. Since 1994, and more-so since we can use table-less CSS, web-design has developed significantly. It is currently establishing its own set of graphic rules, and insights such as:
Talk talk vs. clarity
Websites should be made as simple as possible, but not any simpler, in order to achieve maximum effect with minimum means. The copy writer has to be able to write whatever the marketing department tells him to write in clear simple words. The practice of simplicity is his daily bread. This clashes with the all too often empty overly wordy corporate blabla, but here again, websites are a healthy remedy of old practices. Successful websites are funny. And the reason is:
Humor is the strongest weapon of communication. With customers getting smarter and smarter (also through the Internet), and time getting more and more sparse due to the tremendous acceleration of things - you absolutely need the strongest communication to make yourself heard. The strongest communication is earnest, straightforward and humorous.
Paper likes grey noise, the screen doesn’t
Paper brochures are expected to be filled with text, so copywriters write and write more or less blind text. As a result, nobody reads them. And not just brochures, fashion magazines, newspapers are full with blind text; TVs implode with their preposterous nonsense. They do not care for the attention of the consumer; all they seem to care is to fill the world with deadly grey noise.
Struggle for every word
Websites basically have to struggle for every word, as with ever word that you write too much, you might loose your reader. Yet if you stay simple without oversimplifying or being sensational (works only for the dumb audience), your chances to keep the reader are considerably high.
Simplicity is not a given
Of course, simplicity is not a given, it is the fruit of continuous, concentrated, diligent work. Only who knows what he is doing is able to do it simply. There is no recipe or anything such as an ideal website. But if you know what you are doing as a designer, copywriter, business strategist, you are mainly dong one thing: You are reducing things to their essence. Designers have a hard time to keep it simple, because simplicity is not something that is there from the beginning, it has to be elaborated.
First Rule of Usability? Don’t Listen to Users
Posted by Silvia | Filed under Usability
By Jakob Nielsen
To design an easy-to-use interface, pay attention to what users do, not what they say. Self-reported claims are unreliable, as are user speculations about future behavior. In past years, the greatest usability barrier was the preponderance of cool design. Most projects were ruled by usability opponents who preferred complexity over simplicity. As a result, billions of dollars were wasted on flashy designs that were difficult to use. One of the main advantages of the “dot-bomb” downturn is that cool design has suffered a severe set back. Companies are now focused on the bottom line:
- Public websites, which formerly focused on building awareness, now aim at making it easy for customers to do business.
- Intranets are similarly refocused on improving employee productivity. Many companies are attempting to create order, impose design standards, and enhance navigation on previously chaotic intranets.
Happily, glamour-based design has lost and usability advocates have won the first and hardest victory: Companies are now paying attention to usability needs. Unfortunately, winning a battle with usability opponents doesn’t win the war with complexity. It simply moves us to a new front line: The battle is now to get companies to do usability right.
Watch Users Work
Too frequently, I hear about companies basing their designs on user input obtained through misguided methods. A typical example? Create a few alternative designs, show them to a group of users, and ask which one they prefer. Wrong. If the users have not actually tried to use the designs, they’ll base their comments on surface features. Such input often contrasts strongly with feedback based on real use. For example: A spinning logo might look pretty cool if you don’t need to accomplish anything on the page. Another example is the drop-down menu. Users always love the idea: finally a standard user interface widget that they understand and that stays the same on every page. However, while they offer users a sense of power over the design, drop-down menus often have low usability and either confuse users or lead them to unintended parts of the site. To discover which designs work best, watch users as they attempt to perform tasks with the user interface. This method is so simple that many people overlook it, assuming that there must be something more to usability testing. Of course, there are many ways to watch and many tricks to running an optimal user test or field study. But ultimately, the way to get user data boils down to the basic rules of usability:
- Watch what people actually do.
- Do not believe what people say they do.
- Definitely don’t believe what people predict they may do in the future.
Say, for example, that 50% of survey respondents claim they would buy more from e-commerce sites that offer 3D product views. Does this mean you should rush to implement 3D on your site? No. It means that 3D sounds cool. The world is littered with failed businesses that banked on people’s attitude toward hypothetical products and services. In speculative surveys, people are simply guessing how they might act or which features they’ll like; it doesn’t meant they’ll actually use or like them in real life.
When and How to Listen
When should you collect preference data from users? Only after they have used a design and have a real feeling for how well it supports them. Jonathan Levy and I analyzed data from 113 pairwise comparisons of user interfaces designed to support the same task and found a 0.44 correlation between users’ measured performance and their stated preference. The more a design supports users in easily and efficiently doing what they want to do, the more they like the design. Very understandable. However, when collecting preference data, you must take human nature into account. When talking about past behavior, users self-reported data is typically three steps removed from the truth:
- In answering questions (particularly in a focus group), people bend the truth to be closer to what they think you want to hear or what’s socially acceptable.
- In telling you what they do, people are really telling you what they remember doing. Human memory is very fallible, especially regarding the small details that are crucial for interface design. Users cannot remember some details at all, such as interface elements that they didn’t see.
- In reporting what they do remember, people rationalize their behavior. Countless times I have heard statements like “I would have seen the button if it had been bigger.” Maybe. All we know is that the user didn’t see the button.
Finally, you must consider how and when to solicit feedback. Although it might be tempting to simply post a survey online, you’re unlikely to get reliable input (if you get any at all). Users who see the survey and fill it out before they’ve used the site will offer irrelevant answers. Users who see the survey after they’ve used the site will most likely leave without answering the questions. One question that does work well in a website survey is “Why are you visiting our site today?” This question goes to users’ motivation and they can answer it as soon as they arrive. Your best bet in soliciting reliable feedback is to have a captive audience: Conduct formal testing and ask users to fill out a survey at the end. With techniques like paper prototyping, you can test designs and question users without implementing a thing. Following these basic usability rules and methods will help you ensure that your design is truly as cool as it looks.
Usability Definitions
Posted by Silvia | Filed under Usability
Here goes some definitions of Usability:
- How easy something is to use.
- The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.
- Usability is the measure of a product’s potential to accomplish the goals of the user.
- Usability is an approach to product development that incorporates direct user feedback throughout the development cycle in order to reduce costs and create products and tools that meet user needs.
- Usability is the measure of the ease with which particular people can employ a particular tool or other human-made object in order to achieve a particular goal. Usability can also refer to the methods of measuring usability and the study of the principles that may predict whether an object is found usable in practice. Usability usually refers to the elegance and clarity with which the interaction with a computer program or a web siteis designed.
- Usability is the effectiveness and efficiency with which users can achieve tasks in a particular environment.