Showing posts with label introduction. Show all posts
Showing posts with label introduction. Show all posts

Sunday, September 23, 2012

Wisdom of the crowds

Group of people and a bowl of jellybeans.

How many jellybeans are in the bowl?

Individually people do not get so good answers. Add all those answers and get a mathematical average and you´ll get really good answer.

This to work:

  • individual answers
  • people should guess well not socially appropriate way

Designing Software for Collaboration

Collaboration: Same time / same place

  • Face to face interaction
  • Roomware
  • Shared tables, wall displays
  • Group Decision Support Systems (GDSS)
  • Single display groupware
Collaboration: Different time / same place
  • Message Boards
  • Dedicated Team rooms
  • Large displays

Collaboration: Same time / different place: 
  • Remote interaction
  • Video-Conferencing, 
  • Real-time groupware 
  • Messaging (Instant messaging, Email) 
  • Virtual worlds 
  • Multi-User editors 
  • Shared Screen (vnc)
Collaboration: Different time / different place:
  • E-mail
  • Wiki
  • Blogs
  • Workflow
  • Version control
It is hard to synchronize things, much more easier asynchronous. 

Introducing Controlled Web Experiments

User tests online not in lab.

Two column layout can be better then one.


Ways design makes a difference

  • The position and color of the primary call to action
  • Position on the page of testimonials, if used
  • Whether linked elements are in text or as images
  • The amount of “white space” on a page, giving the content space to “breathe”
  • The position and prominence of the main heading
  • The number of columns used on the page
  • The number of visual elements competing for attention
  • The age, sex and appearance of someone in a photo

Setting Up, Debriefing, and Summarizing Results

Greeting participants
Explain the task
Warm up tasks
Give the questions
Sign the release form.
Ask if they have any questions.
Don´t give away what you want to measure or them to learn.

Instructions to Participants
We test UI not you!
They can quit at any time
Explain that you are not providing any help to them

Collecting data
What they did and think.
How many errors and where.
etc.

Debriefing
Show the critical incidences and what they think you could do better there.
Ask about design alternatives!

Summarize the results
Things that actually matter. Your brain is going to forget all the details and summarizes can be really valuable. Even just one sentence.

Prioritize the different results - then you know what you have to do next.

Capturing Results and Recruiting

Video recording - its god to narrow it down to 20 sec snippets where you presents successes and problems of your design.

Screen recording is also an options.

Note down all the critical mistakes. Use these to get feedback again from the user when he ends the user test. Also you use them to help you to improve your design.

The "Thinking aloud" method:

Need to know what users are thinking, not just what they are doing.
Ask users to talk while performing tasks

  • tell us what they are thinking
  • tell us what they are trying to do
  • tell us questions  that arise as they work
  • tell us things they read
Thinking out aloud can change things also their actions can be different compared to silent task performing.

Another good practice is to let users perform the test individually and afterwards pair them up and show them videos about their critical problems while they tried to use the UI. They can then discuss the problems and maybe give you even more valuable information.

Setting up the test session: You can already prepare notes for noting. For example you already know what kinds of areas are interesting for you or just fill in some blanks etc. It can be better than just blank notebook.




Saturday, September 22, 2012

Goals, Tasks, and Details

How to lower down the stress on people who are measured?

You are testing the site not the user! Communicate to the user that he is a partner for you who helps you to find errors and bugs in your system.

Articulate the Goals of your study. Write down the parts of your system you think you could improve and where you need feedback.

Think about when and where this test is going to take place.

Create concrete tasks - written down on a paper on computer - then you can be sure that you are consistent during many study sessions with different users.

Plan out the steps  - what are you going to ask, that you plan time for introduction and also feedback.

You can have a built in timer in you app / webpage that collects data about the time user is on one page.

Roles in a team of three: a facilitator (all the interaction with the user), note taker, video maker/ photographer.

Experimental details - do you want that users have some kind of training or preparation for the test.

Before you bring any real users into lab make shore you have had a "pilot"- he is purely there for debugging your user test process.

Participants and tasks

Choosing participants

Persuade participants if needed. For example if you are building an interface for teachers and they don´t want to participate then you can say that in the end when your product goes to production then they can use it in their work and make their life easier.

Selecting tasks

Real tasks that people would perform while using your interface in everyday life.
Don´t bend the tasks in a way that your preferred design would stand out. That´s cheating!


Designing user studies

Between subjects design - one group uses only one interface. - use it if you want to avoid ordering effect.

  • Half of the users try out one interface.
  • The other half tries out the other  interface .
Within subjects design - both groups use both  interfaces - this one avoids all the individual differences problem

Users already know a bit more about interfaces by the time they start using the second interface. To get more objective results in the end, both groups should start with different interfaces.


Evaluation Strategies

How can we measure success? How do we know?
Why evaluate design by people?

Taxonomy of methods - different methods achieve different goals
the scientific process of classifying things (= arranging them into groups)


Field strategies


  • Field Study - You give your thing out there  and users use it over a longer period of time.
  • Field Experiment -Like clinical drug trial.Half the people get one, the other half gets the other one. Users use it over a longer period of time.


Experimental strategies


  • Experimental simulation - 
  • Laboratory Experiment - You bring people into the lab and they try out one or two different interfaces.


Respondent strategies


  • Judgement Study - how much do you like X or Y
  • Sample Survey - different polls, you can do them before or after the user has used the interface.
    • Surveys - you are not getting behavioral feedback but more like self reports. People may not be telling the truth what actually happened.


Theoretical strategies


  • Formal Theory - 
  • Computer Simulation - computer simulates what a user could do - this kind of method is not really widely used


Measure - dependent variables
task completion time
accuracy 
recall
emotional responses

Manipulations - independent variables
You are always manipulating some aspect of the user interface. Should we use a graph for representing info or textual. Should we put a navigation bar on the top or to the right of the page. These kinds of manipulations we see all the time in the field of HCI.

Precision - Internal validity
If we would run the tests again would we get the same results? Weather the results are useful etc.

Generalizability- External validity
If the results generalize to real world situation we ale going to say that UI has high external validity.

Friday, September 21, 2012

Rating Scales and Graphs

Use scales that people can relate to.

This image of scale values can be really hard to understand. For example you see a post where you notice a random rating used. At first you have no clue does it represent good or bad value ..

Color

How to get color right?

  • Design in grayscale first (black and white).
  • Keep luminance (heledus, erksus) values from grayscale when moving to color. 

Design for Glanceability

glance - to look quickly at something/somebody; to read something quickly and not thoroughly


It is much easier to read the top half of the letters than the bottom half.

68 %of the time  the eye is in motion when reading, 32% of the time the eye is fixated on one spot. When the eye is in motion it cant actually see anything. It can only read when it is down on the fixations.

With an "heat tracker" you can see how much time is spent on different parts of a webpage. 

Things that are top left are likely seen at first. Less important you can drift out.



Interlaced browsing and navigation

interlaced - põimitud.

A lot of different tabs opened in browser. Reading a lot of stuff at the same time.
On a mobile you don't have maybe seven different sites open but your attention is disturbed by other people.
Users attention is scattered and we as designers have to deal with that.

Menu labels that don´t say you anything -> Transactions - what the hell is that?
Users start to "try" different things and going back and forth to find the action they are looking for.

If icons are not supporting the text, come up with better icons !

If you are looking for one perfect word that would be a heading for  bunch of different stuff, then you should understand - there isn´t one perfect word!

Speaking block navigation - describes if you would click there what will you get to.

http://www.smashingmagazine.com/2008/02/26/navigation-menus-trends-and-examples/






Matching semantics & visual layout

Some starting points:
  • Gather materials you find successful 
    • Could be from very different domain
    • Good artists borrow, great artists steal - Picasso
  • Include visual design professionals in the iterative design cycle
Icon design: Differences that make a difference. Contrast like black vs white. Green is GO and red is STOP.

The example with the pill bottles - they are full of information but if you have 4 different bottles you cannot differentiate  them only by looking. 


Thursday, September 20, 2012

Type matters


Typeface: Gill Sans (sans-serif typeface designed by Eric Gill.)

Dynamism through asymmetric layout in a text. Do not center stuff!

Sans serif is for short texts or headings. Where serif is for more longer texts.

Use real quotation marks - easier to understand where a quote starts and ends.

Also numbers have upper case and low case. Low case numbers bled in to text more easily.

Books that are cheap don´t but so much white space around text. But with white space it is easier for the eye to read.






Representational shifts

Instead of remembering what have you copied on a clipboard, the thing you did cut or copy could be circled in the same document.

As a designer your task should be:design in a way that there would be no chance for an user to make an error. "Your text is outside of the printable area, would you like to proceed?" - Don´t ask me but show me where it is and show it already by doing not afterwards.


Good Representation

Representation: kujutis

Problem solving as Representation
"Solving a problem simply means representing it so as to make the solution transparent" - Herbert Simon

Design by 0 working memory - meaning that don´t make a user to memorize stuff.

A good representation shows all the relevant information, and nothing else. Should enable: comparison, exploration, problem solving.

If designing a system to replace a manual work, pay attention not only at the process itself but also the objects used. for example by doctor your record tells more then only information written to it. If it is really "used" then you know a lot of action has been going on. If your record is still on doctors table then you were recently there etc.

Command line vs GUI

GUI

  • self disclosing (ise nn avalduvad)
  • you know what you can do all options are on the screen
  • you know what you did, feedback


Command line

  • Perform abstract actions
  • Move many things at once


Buttons often have to abstract names and users actually don´t know what they are doing or what does it mean. For example 'Save'. where or what do I save etc.

Map Interface controls

Controls should mirror real world.

Direct manipulation provides

  • Good idea of how each object works and how to control it
  • Interface itself discloses how it is used
  • The art in design is ti translate users cognitive capabilities and existing mental models into interfaces that work.
  Computers bring flexibility and if we concentrate only on making interfaces more like real world then we cant have that kind of flexibility  .

"If technology is to provide an advantage, the correspondence to the real world must break down at some point."- Jonathan Crudin


Wednesday, September 19, 2012

The Gulf of Execution and The Gulf of Evaluation

The Gulf of Execution
Primary question of users when meeting UI-s:  How do I do what I want to do ?

The Gulf of Evaluation 
Second question: What happened.


Can the user do what they would like to?
What representations are used for communication?

Solution what many UIs come across : Direct manipulation user interfaces


  • Immediate feedback on actions
  • Continuous representation of objects
  • Leverage metaphor  - we are more and more familiar with digital environment and we don´t need so many real world metaphors to understand an user interface. 



Good design reduces gulfs.

How easily can we:

  • Determine a function of the device?
  • Tell what actions are possible
  • Determine mapping from intention to physical movement
  • Perform an action?
  • Tell if system is in desired state?
  • Determine mapping from system state to interpretation?
  • Tell what state the system is in?

One strategy is really effective - Mental models.

Mental model in users head does not do what real life is really like.

There are many kinds of mental models:

  • My own behavior
  • Someone else´s behavior
  • A software application
  • .. or any information process that´s mediated


Metaphores: Learning Mental Models
"A text processor is a typewriter"
Mental models are inconsistent in time

Users and designers communicate through their mental model

Designer´s model = mental / conceptual model of the system.
User´s model = mental model developed through interaction with the system
Designer expects user´s model to be the same as the designer´s model. But often it isn´t!

Conceptual Model Mismatch
Mismatch between designer´s and user´s conceptual models lead to: slow performance, errors, frustration. You see this by walking around and noticing notes on devices etc where people write what to do or how to do smth.