Habe hier ein schön illustriertes Poster gefunden, das erklärt worum es beim UCD geht und wie es überhaupt funktioniert. Verschönert bestimmt das ein oder andere Büro.
User-centered Design Poster
Zur Seite des Künstlers geht es hier:
http://www.paznow.com/ucd/
Das Poster zum Download und zum selbst ausdrucken gibt es hier:
http://paznow.s3.amazonaws.com/User-Centred-Design.pdf
- Women have surpassed men as online buyers and they spend more and their influencing is growing rapidly, in addition to the use of group buying or ‘flash sale’ sites eg. Groupon.com LivingSocial.com. Social retail is an emerging area for women, due to their tendency to share and discuss with other others.
- Women spend more time online 8% globally than men and 30% more time on social networking sites than men.
- Women are motivated differently in their use of social networking sites like Twitter. Twitter adoption is equal or higher than men. Twitter is used by women more for conversation, to follow celebrities or to find deals and promotions. Men are more likely to post their own tweets.
- Social networking is emerging as a driver for women in the mobile sphere.
- Women are using online entertainment e.g. puzzle, board and card games and functional sites money management as much as men change in past behavior where health, apparel, baby goods.
- Cultural differences in emerging markets Asia, Latin America will always influence online behavior by gender- an important localization issue.
- Older women moreover men, are rapidly adopting social networking sites– and at the same intensity of younger women.
- Women are still attracted to health content, community and lifestyle sites. However women are outpacing men in some areas of finance and are actively engaging in male-dominated areas: adult content and gambling.
- Compared to men, women Bing users spend more time on Bing for search, than Google- and YouTube for video. Facebook, while visited more than men is unable to compete with regional social networking sites such as CyWorld in South Korea, Vkontakte.ru in Russia, Mixi.jp in Japan or StudiVZ in Germany, especially among older women.
- Women spend more time on Social Networking, Instant Messaging IM and Email than men globally.
- The embrace of social networking and its importance to women has significant implications for content and user experience.
- Women spend more time on photo sites and adopt photo sharing faster. Email usage is higher in the 45+ age group. Latin American women do more IM’ing than other women globally, with their use of email topping North American females.
viaDemystifying Usability : New Study- Gender differences in Web Usability.
Nach Pidoco ein weiterer interessanter Webservice, der es ermöglicht online Prototypen zu entwickeln und diese auch dem Kunden zur Besprechung zur Verfügung zu stellen.
Damit die erstellten Lösungen nicht einfach nur simple, statische Wireframes sind, hat sich der Hersteller einer neuen Sprache für Nicht-Programmierer einfallen lassen “Flow”.
Ein weiterer positiver Ansatz ist die Wiederverwendung von validem HTML und CSS Code.
Der Prototyp kann direkt in ein entsprechendes Grundgerüst überführt werden. Dies ist bei anderen Lösungen eher bedingt oder garnicht der Fall.
Quplo in der Beta-Version findet man hier:
Web-based prototyping software for interaction designers: quplo.
Wenn eine klassische hierarchische Ordnung von Inhalten sehr schwer wird und man unterschiedliche Einstiegsmöglichkeiten dem Anwender anbieten möchte, eignet sich hier eine Facetten-Navigation.
Diese zeichnet sich dadurch aus, dass man nicht einen linearen Weg beschreitet, sondern explorativ sich durch das bestehende Angebot z.B. mit Filter hindurchnavigiert.
Hier einige Beispiele von Projekten, die mit Hilfe eines Frameworks beeindruckende Lösungen erstellt haben.
Großer Vorteil dieses Frameworks ist das vermeiden einer leeren Menge: Man startet mit dem gesamten Angebot und schränkt dann nach und nach die Menge ein.
Facetten-Navigation
Usability test tasks are the beating heart of a usability test. These tasks determine the parts of a system that test participants will see and interact with. Usability test tasks are so critical that some people argue they are even more important than the number of participants you use: it seems that how many tasks participants try, not the number of test participants, is the critical factor for finding problems in a usability test.
But for test tasks to uncover usability problems, usability test participants need to be motivated: they need to believe that the tasks are realistic and they must want to carry them out. So how do we create test tasks that go beyond the mundane and engage participants?
To help our discussion, I’m going to classify usability test tasks into 6 different categories. You don’t need to create tasks in each of these categories — you simply need to review the categories and decide which kind of task will best motivate your participants.
The 6 categories are:
- Scavenger hunt.
- The Reverse Scavenger hunt.
- Self-generated tasks.
- Part self-generated.
- ‘Skin in the game’ tasks.
- Troubleshooting tasks.
Let’s look at each of these in a bit more depth.
Scavenger hunt
This type of task is a great way for you to find out if users can complete tasks with your system. With a scavenger hunt task, you ask users to do something that has one clear, ideal answer: an example of this kind of task (for a web site that sells luggage) might be: “You’re travelling abroad next month and you’re looking for a good-sized bag that you can take on as hand luggage. You want the bag to be as big as possible while still meeting the airline’s maximum luggage dimensions (56cm x 45cm x 25cm). You have a budget of £120. What’s the most suitable bag you can get?” With a good scavenger hunt task there will be one perfect answer, so quiz the design team to find out the best solution to this task and then see if participants can find it.
The Reverse Scavenger hunt
With this type of task, you show people the answer — for example a picture of what they need to look for — and then ask them to go about finding or purchasing it. For example, if you’re testing out a stock photography application, you could show people an image that you want them to locate and then ask them to find it by creating their own keywords. This kind of task works well if you think that a textual description of the task might give away too many clues.
Self-generated tasks
Scavenger hunt and reverse scavenger hunt tasks work well when you know what people want to do with your web site. But what if you’re less sure? In these situations, try a self-generated task instead. With this type of task, you ask participants what they expect to do with the site (before you show it to them), and then you test out that scenario. For example, you might be evaluating a theatre-ticketing kiosk with regular theatre-goers. You begin the session by interviewing participants and asking what they expect to be able to do with the kiosk. For example, you might hear, ‘book tickets for a show’, ‘find out what’s on’ and ‘find out where to park’.
You then take each of the tasks in turn, and ask the participant to be more specific. For example, for the task, ‘book tickets for a show’, you’ll want to find out what kind of shows they prefer, such as a play, a musical or a stand-up routine. How many tickets would they want to book? On what day? For an evening or a matinee performance?
Your job is to help participants really think through their requirements before letting them loose with the system, to make sure that the task is realistic.
Part self-generated
These tasks work well when you have a good idea of the main things people want to do with the site, but you’re less sure of the detail. With a part self-generated task, you define an overall goal (for example, ‘analyse your electricity usage’) and then ask the participant to fill in the gaps. For example, you can do this by asking participants to bring data with them to the session (such as electronic versions of past electricity bills) and allowing them to query their own data in ways that are of interest (for example, ‘what are my hours of peak usage?’)
‘Skin in the game’ tasks
A problem with usability test tasks is that you want participants to carry out the tasks as realistically as possible. But there’s a big difference between pretending to buy a holiday in Spain and really buying a holiday in Spain. No matter how well intentioned they are, participants know that, if they get it wrong, there are no consequences. You can mitigate this risk by giving participants real money to spend on the task.
The easiest way to do this with an e-commerce web site is simply to give participants a redeemable voucher to spend during the test, or reimburse their credit card after they have made a purchase.
A related approach for other systems is to incentivise the participant with the product itself. For example, if you’re testing a large format printer that creates photographic posters, you could ask people to bring in their digital photographs and then get them to use the printer to create the poster they want. The poster itself then becomes the participant’s incentive for taking part.
As well as getting as close as possible to realistic behaviour (mild concerns become pressing issues), this approach also gives you the confidence that your participants are the right demographic, since their incentive is based on the very product you’re testing.
Troubleshooting tasks
Troubleshooting tasks are a special category of test task because people may not be able to articulate their task in a meaningful way. It would be misleading to give a participant a written task that you’ve prepared earlier since by its very nature this will describe the problem that needs to be solved. For example, a mobile phone may display an arcane error message if the SIM card is improperly inserted or a satnav system may fail to turn on. As far as the user is concerned, the product is simply not working and they don’t know why.
For these situations, it makes sense to try to recreate the issue with the product and then ask the user to solve it — either by starting the participant at Google or at your company’s knowlegebase articles. You’ll then get great insights into the terminology that people use to describe the specific issue, as well as seeing how well your documentation stands up to real-world use.
Gefunden auf: http://www.userfocus.co.uk/articles/testtasks.html
Ein interessanter Artikel im Smashing Magazine, welcher die Disziplin “Innenarchitektur” mit “Webdesign” vergleicht und erstaunliche Parallelen offenlegt.
Kein Wunder, dass man Konzeptarbeit auch als “Informationsarchitektur” betiteln kann.
Den Artikel findet man hier:
Applying Interior Design Principles To The Web – Smashing Magazine.
Sehr interessanter Artikel bzw. Best-Practice Studie über Formular Design und Validierung.
Für jeden Konzepter ein MUST-KNOW!
Web Form Validation: Best Practices and Tutorials – Smashing Magazine.
Ein neues interessantes Tool, mit dem es möglich ist die Navigation einer Seite zu überprüfen – und das auch noch kostenlos.
Sicherlich einen Blick wert!
Naview – Create easier navigations through prototyping and testing.
Designing effective web surveys is really about following a process with 6 steps:
- Formulate your research question.
- Identify your population and sample.
- Design the questionniare.
- Pilot test the questionniare.
- Collect the data.
- Analyse the data.
Problems occur with surveys when people skip one of these steps.
Formulate your research question
Surveys provide information to solve problems. So before you begin your survey you need to be able to confidently articulate the specific problem that you’re trying to solve.
A typical problem I’ll hear from people is, “I want to know what people think about our new product.” Although laudable, this is too vague a problem to design a survey around. What specific problem are you trying to solve and what new information do you need to solve it?
Further questioning might reveal that the product is suffering from an unduly high rate of returns. So the problem might be better articulated as, “Why do people return our product shortly after buying it?” This helps us realise that we need to create questions that identify people’s initial expectations about the product and how the product falls short of these expectations — questions we might have missed if we had stayed with the vaguely articulated problem.
A clearly stated problem statement also helps us distinguish between information we must gather and information that is ‘nice to have’ — which means we can also use it to keep our survey short.
Identify your population and sample
All surveys are susceptible to error. Most people are aware of ‘sampling error’, the ‘plus or minus’ figure quoted with opinion polls. When we take a sample, we use a selection of people and hope that their views are representative of the whole population that we are interested in. We can use statistics to quantify the amount of sampling error in a survey but these statistics are valid only if the sample you have taken is truly random.
This is rarely the case, for two reasons. First, the research method you have chosen may exclude certain people (so-called instrument error). For example, using a web survey will exclude people who don’t have access to the web.
The second reason is that non-respondents are often different from respondents in a way that matters to the outcome of the study (so called nonresponse error). For example, imagine we devised a survey to measure people’s experience with the Internet. Imagine further that we send out the survey invitation by e-mail. It might be the case that novice users of the Internet are much more reluctant to click on a link in an e-mail message, thinking that messages with links are fraudulent.
Non-response error is a serious source of error with web surveys. This is because researchers tend to send their survey to everyone as it’s easy to do so.
For example, you may send the survey to 10,000 people on your mailing list and find that 1,000 respond. Although the sampling error will be small, the large non-response error is a serious source of bias. This is because those people who responded may not be representative of the total population — they may like your company more and so be more disposed to take the survey. In this example, the survey respondents are different from nonrespondents in a way that will affect the survey results.
In this example, it would be better to randomly sample 500 people from the 10,000 and aim for a 75% response rate (375). This is because a 75% response rate from a randomly selected sample is better than a 10% response rate from everyone. Remember that the key is to select from your population randomly. Whenever your response rate is less than 60%, you should be on the look out for non-response error.
Design the questionnaire
The survey itself may also be a source of bias. For more on crafting good survey questions, try 20 tips for writing web surveys.
Here are some common errors I’ve seen in survey questions:
- Using unbalanced response scales.
- Using response categories that overlap.
- Asking vague questions.
- Asking leading questions.
- Asking nosy questions.
- Using jargon or abbreviations.
- Assuming people know enough to answer.
- Asking people questions that require too much thought.
- Asking double-barrelled questions.
Pilot test the questionnaire
A pilot test provides a way of finding problems with the survey before you invest in the cost of collecting data. You should never send out a survey without pilot testing it first.
Pilot testing is best done in two phases: in the first phase, you talk with the people who will use the survey results — the stakeholders. Because they have practical knowledge about the kind of data that are being collected, they can spot technical problems that you might miss.
You conduct the second phase of the pilot test with a sample of respondents. It is important to watch people fill out questionnaires in person rather than simply emailing them a link. That way, you can watch for signs that people are puzzled, check their understanding of certain questions, and see if they misinterpret instructions.
Collect the data
Once you’ve got this far in the process, all you should need to do is write an engaging invitation to get people to respond.
Assuming that you send out an email invitation, make sure that you include a relevant subject line and a recognisable email sender name so your invitation doesn’t end up in people’s junk mail folder. You’ll also increase the response rate if you describe the incentive, personalise the invitation and make it urgent (‘survey closes in 7 days’).
Two weeks is long enough to keep most surveys open as evidence shows that over half of survey responses arrive in the first day, with 7 out of 8 responses within the first week
(PDF).
Analyse the data
You’ll use two types of statistics in your analysis:
- Descriptive statistics: Summarises what’s going on in your data
- Inferential statistics: Helps you make judgements of the probability that an observed difference between groups is a dependable one or one that might have happened by chance.
Most of the online survey tools, like SurveyMonkey, make it straightforward to calculate descriptive statistics for your survey and will even create graphs for you. To carry out inferential statistics, you’ll need to export the raw data and do some number crunching in a program like SPSS.
Von: http://www.userfocus.co.uk/articles/websurveys.html
heise online gilt als das bedeutendste IT-Portal in Deutschland. Eine Analyse mit m-pathy zeigte unter anderem, welche Auswirkungen die Platzierung von Anzeigen auf das Leseverhalten der Nutzer haben kann. Dabei wurde ein bekanntes Phänomen bestätigt: Scrolling wird dann zum Usabilityproblem, wenn ein grafisches Element einer Seite genau mit dem sichtbaren Bildschirmbereich abschließt. Viele Nutzer denken dann irrtümlich, sie haben das Ende der Seite erreicht.
Anzeigen als Aufmerksamkeitsbremser
Anschaulich wird dies bei einem Vergleich von drei unterschiedlich gestalteten Artikeln: Das Bild zeigt die Heatmaps von Mausbewegungen. Der orangefarbene Rahmen markiert den sichtbaren Bildschirmbereich. Die Analyse zeigt für den Artikel in der Mitte, dass die Mehrheit der Nutzer nur den ersten Absatz wahrgenommen hat.
Die Werbeanzeige ist hier so ungünstig platziert, dass sie als Stopper wirkt. Sie liegt genau auf dem Ende des sichtbaren Bildschirmbereichs. Die meisten Besucher dachten vermutlich, dass der Artikel an dieser Stelle zu Ende ist und haben deshalb nicht weiter nach unten gescrollt. Bei dem Artikel links im Bild wird die Anzeige am Ende des Textes eingeblendet. Zwar sind auch bei dieser Variante die meisten Mausspuren im oberen Bereich des Artikels zu sehen. Doch sind sie insgesamt gleichmäßiger verteilt und erstrecken sich über den gesamten Text. Dies zeigt, dass die Nutzer hier bis ans Ende der Seite gescrollt und den Artikel vollständig gelesen haben. Der Artikel rechts zeigt eine weiter oben platzierte Anzeige. Hier ist der Abschnitt oberhalb der Anzeige kürzer. Für den Nutzer ist dadurch ohne zu scrollen auf den ersten Blick sichtbar, dass der Text unterhalb der Grafik weitergeht. Die im Text platzierte Anzeige wirkt deutlich weniger als Hürde. Die Nutzer scrollen bis nach unten und nehmen auch das Ende des Artikels wahr. Das zeigen die Mausspuren über dem letzten Abschnitt.
Fazit: Eine lange Seite, die über mehrere Bildschirmhöhen reicht und vom Nutzer verlangt zu scrollen, besitzt nicht per se eine schlechte Usability. Problematisch wird es aber, wenn grafische Inhaltselemente wie Bilder, Absätze oder Trennlinien genau mit dem Ende des sichtbaren Bildschirmbereichs zusammenfallen. Für viele Nutzer wirkt das so, als ob die Seite an dieser Stelle zu Ende wäre. Sie scrollen deshalb – sicher unbewusst – nicht weiter nach unten, obwohl sie prinzipiell natürlich wissen wie ein Scrollrad funktioniert.
via heise.de: Anzeigen als Aufmerksamkeitsbremser – m-pathy.
