hmmm..Overcoming fear of moderating UX research sessions
(from Dana Chisnell )
It always happens: Someone asks me about screwing up as an amateur facilitator/moderator for user research and usability testing sessions. This time, I had just given a pep talk to a bunch of user experience professionals about sharing responsibility with the whole team for doing research. “But what if the (amateur) designer does a bad job of moderating the session?”

What not to do
There are numerous ways in which a moderator can foul things up. Here are just a few possibilities that might render the data gathered useless:

  • Leading the participant
  • Interrupting or interviewing in the wrong time
  • Teaching or training rather than observing and listening
  • Not following a script or checklist
  • Arguing with a participant

  • Axure RP

    09Jun10

    Axure LogoAxure RP is the leading tool for rapidly creating wireframes, prototypes and specifications for applications and web sites. Quickly get the benefits of prototyping without a lot of hassle.  

  • Axure RP Environment
  • Create Annotated Wireframes
  • Understanding Interactions
  • Show/Hide Dynamic Panels
  • Make Global Changes with Masters
  • Create Flow Diagrams
  • Generate Interactive Prototypes
  • Generate Functional Specifications
  •   

    Another useful resource when you are just getting started is the Learn by Doing: Quick Start Guide (pdf)


    Blocks and Arrows logo

    There is a nice article at Boxes and Arrows. I would feature some quotations from there:

    1. Annotations.. have a difficult role: to speak for the wireframe’s designer when he isn’t there.
    2. There are typically five audiences for wireframes: clients, developers, visual designers, copywriters, and, most importantly, your future self.
    3. All of these have different needs, and addressing them all in the annotations — especially given the small area that annotations typically inhabit on the wireframe — can be difficult.
    4. Clients will want to see that you’ve incorporated the business goals they provided. Developers want to see what they have to support, and how the site or application works (and doesn’t work: don’t forget to document what happens when an error occurs). Designers want to see what visual elements need to be on the page. Copywriters want to see what they need to write. And you — the future you — need to remember why…
    5. ..separate annotations into two main sections — content and functionality— and display them both for everyone. Developers will mainly look at the functional notes, copywriters the content ones, and everyone else will pick and choose between both..

    Things that should be annotated:

    1. Any items that are conditional — when and how they should be displayed.
    2. Links and buttons — what happens when they are clicked.
    3. Anything that, due to space, could not be shown on a wireframe, e.g., every item on a long drop-down menu.
    4. Anything with a business, logical, or technical constraint — e.g., the longest possible length of a password field.
    5. In short, anything that is not immediately obvious from looking at the wireframe should be documented.

    Site Map

    07Jun10

    A site map (or sitemap) is a list of pages of a web site accessible to crawlers or users. It can be either a document in any form used as a planning tool for web design, or a web page that lists the pages on a web site, typically organized in hierarchical fashion. This helps visitors and search engine bots find pages on the site.

    Sitemap


    Interaction Design (IxDA) defines the structure and behavior of interactive systems. Interaction Designers strive to create meaningful relationships between people and the products and services that they use, from computers to mobile devices to appliances and beyond.


    HTML offers authors several mechanisms for specifying lists of information. All lists must contain one or more list elements.  

    Definition lists, created using the DL, DT and DD elements, generally consist of a series of term/definition pairs (although definition lists may have other applications). Thus, when advertising a product, one might use a definition list:  

    Lower cost

    The new version of this product costs significantly less than the previous one!

    Easier to use

    We’ve changed the product so that it’s much easier to use!

    Safe for kids

    You can leave your kids alone in a room with this product and they won’t get hurt (not a guarantee).

    DL – definition list
    DT – definition term
    DD – definition description

    Lists may also be nested and different list types may be used together, as in the following example, which is a definition list that contains an unordered list (the ingredients) and an ordered list (the procedure): 

    The ingredients:

  • 100 g. flour
  • 10 g. sugar
  • 1 cup water
  • 2 eggs
  • salt, pepper
  • The procedure:

  • Mix dry ingredients thoroughly.
  • Pour in wet ingredients.
  • Mix for 10 minutes.
  • Bake for one hour at 300 degrees.
  • Notes:

    The recipe may be improved by adding raisins.
    The exact presentation of the three list types depends on the user agent. We discourage authors from using lists purely as a means of indenting text. This is a stylistic issue and is properly handled by style sheets.  

    W3C Recommendation


    Head rotation created in FlashFrame-by-frame animation can be difficult when you’re working on one frame at a time with no reference for the previous or next frames. In traditional animation, this problem is solved by the use of light desks or light tables, which let you see through multiple layers of paper as though they were transparencies, with the ink/pencil lines standing out clearly laid atop one another.

    Thankfully, Flash has an equivalent of this effect–known as onion-skinning, an option that you can turn on that shows a range of frames both before and after your current frame, progressively fading them out as if they’re layered on translucent paper on top of each other, or “onion-skinned”.


     logo pensil

    The Pencil Project’s unique mission is to build a free and opensource tool for making diagrams and GUI prototyping that everyone can use. 

    Top features: 

  • Built-in stencils for diagraming and prototyping
  • Multi-page document with background page
  • Inter-page linkings!
  • On-screen text editing with rich-text supports
  • Exporting to HTML, PNG, Openoffice.org document, Word document and PDF.
  • Undo/redo supports
  • Installing user-defined stencils and templates
  • Standard drawing operations: aligning, z-ordering, scaling, rotating…
  • Cross-platforms
  • Adding external objects
  • Personal Collection
  • Clipart Browser
  • And much more…
  • Pencil will always be free as it is released under the GPL version 2 and is available for virtually all platforms that Firefox 3 can run. The first version of Pencil is tested against GNU/Linux 2.6 with GTK+, Windows XP and Windows Vista.


    car showLorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean imperdiet aliquam tristique. Sed non elit eu risus feugiat consectetur. Donec tempor tempus lectus, vitae venenatis velit malesuada nec. Proin vitae tristique libero. Vestibulum vestibulum imperdiet ullamcorper. Phasellus vitae imperdiet elit. Vestibulum sit amet neque velit, quis interdum orci. Suspendisse dapibus pulvinar scelerisque. Morbi euismod placerat porttitor. Donec a augue ac magna sagittis imperdiet nec nec ipsum. Praesent nec ullamcorper massa. Mauris tincidunt justo sit amet purus hendrerit quis laoreet tellus dignissim. Nam erat urna, laoreet et tempus non, congue nec risus. Proin posuere pellentesque imperdiet. Praesent tristique scelerisque ante, ut cursus dolor tempor sed.

    car showMauris orci massa, volutpat nec porttitor a, euismod et nisi. Vestibulum quis lorem quam. Donec lobortis consequat libero, quis aliquam augue pretium sed. Sed sodales placerat lacus. Mauris scelerisque pulvinar mauris vitae lobortis. Nulla dignissim ipsum ullamcorper purus ullamcorper fringilla. Nam felis justo, porta aliquet suscipit sit amet, commodo at mauris. Integer a felis non nisl sollicitudin consectetur non in diam. Curabitur turpis nulla, venenatis suscipit ornare lobortis, vulputate eget dolor. Cras aliquam tempor viverra. Etiam auctor rhoncus elit in cursus. Suspendisse dignissim orci accumsan erat hendrerit eu sollicitudin erat molestie. Nulla ac lacus interdum mauris luctus ultrices. Sed condimentum, felis vel varius vestibulum, metus turpis volutpat odio, eget lacinia risus magna eu dui. Pellentesque fermentum fringilla erat vitae porttitor.

    Sed ac quam sed augue commodo venenatis. Fusce semper elit non erat fringilla pretium. Aenean et hendrerit arcu. Ut posuere mauris eu ante blandit tristique. Ut viverra libero at est tempor sed faucibus felis rutrum. Phasellus iaculis erat eu libero suscipit ut auctor elit lacinia. Morbi ipsum nulla, posuere vel semper quis, fringilla ut augue. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Nunc a vehicula eros. Aenean feugiat commodo libero vitae aliquet. Aenean id dictum eros. Vivamus vel nibh urna. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae;

    Federico Fellini

    Donec odio massa, hendrerit id tempus id, euismod vitae sem. Cras eu arcu in nibh auctor lacinia interdum et risus. Fusce venenatis tincidunt euismod. Sed sagittis vestibulum diam vitae dignissim. Nunc dolor lorem, molestie vitae pharetra tempor, varius sit amet velit. Pellentesque porta risus fermentum mi volutpat sagittis. Donec in turpis lectus, vitae semper lacus. Suspendisse sed dui a eros sodales pulvinar sed vel arcu. Donec eros odio, feugiat non laoreet et, tempus vel erat. Vivamus vehicula turpis nisl, vitae condimentum lectus.

    My cats (pdf), placerat eget mattis id, hendrerit sed augue. Vestibulum sit amet sem eget quam condimentum bibendum non ac quam. Ut odio dui, faucibus ac suscipit vitae, laoreet ac lacus. Mauris in dolor leo. Maecenas vitae nibh et risus placerat feugiat iaculis vitae orci. Etiam scelerisque laoreet eleifend. Proin at quam urna. Fusce purus tortor, commodo quis aliquam vitae, elementum non risus. Donec ultricies venenatis libero et molestie. Donec dictum venenatis rhoncus. Cras a orci nisi. Sed ac libero nec est molestie vestibulum nec sit amet felis. Vestibulum tincidunt, felis nec auctor viverra, purus libero sodales metus, sit amet pharetra purus tortor ac purus. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Nam quis elit libero, quis lacinia metus. Curabitur quis feugiat ipsum. Nam posuere tortor non urna lobortis cursus.


    by Jakob Nielsen

    These are ten general principles for user interface design. They are called “heuristics” because they are more in the nature of rules of thumb than specific usability guidelines.

    Visibility of system status

    The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.

    Match between system and the real world

    The system should speak the users’ language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.

    User control and freedom

    Users often choose system functions by mistake and will need a clearly marked “emergency exit” to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.

    Consistency and standards

    Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.

    Error prevention

    Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.

    Recognition rather than recall

    Minimize the user’s memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.

    Flexibility and efficiency of use

    Accelerators — unseen by the novice user — may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.

    Aesthetic and minimalist design

    Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.

    Help users recognize, diagnose, and recover from errors

    Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.

    Help and documentation

    Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user’s task, list concrete steps to be carried out, and not be too large.