Interaction design

All about web user experience and good design practice

Scrolling shopping baskets

Posted by Danni on December 7, 2009

Some quick thoughts..Scrolling SB has comes with risks. If the shopping basket is too long, the totals and ‘checkout’ call-to-action button could appear below the fold. This is especially the case if many products have been added and at lower resolutions or non-maximized screens. Users would have to scroll to the bottom of the page to get the ‘checkout’ button in view.

I recommend:
- non-scrolling SB.
- if it must scroll, then make sure it anchors to the bottom of the page, so the checkout button is always in view (the top the basket then won’t be though..)
- make it scroll along slowly 
- either keep the product descriptions short (or empty) or consider removing the totals. test the worst-case scenario if it is a likely one.

Anybody seen any examples?

Posted in E-commerce, Interaction Design, patterns | Leave a Comment »

Improving electronic forms

Posted by Danni on December 6, 2009

Online and web forms

For e-commerce businesses it may be cheaper to make some easy fixes to your form than to implement for inline validation. Quick wins, like the ones listed below, may be cheaper to implement and have more effect on conversion than inline validation.

Always consider making these form improvements first:
- Remove optional fields. Let users fill that out via their profile after registering.
- Make input formats forgiving and if possible auto-correct user’s data for them without surprising the user negatively (don’t show them the corrections you made).
- Clean forms and make them easy and fast to scan by eye.
- Improve the emotional experience. Make the form page pleasant (e.g. Vimeo.com) and filling in the form fun (e.g. Flickr) or calm.
- Improve error copy and make messages clear, errors fast to detect and easy to correct. For example make use of red highlights and scroll to the error when user clicks Submit button.
- Pre-fill fields with gray examples or give a short static explanation just near the field (below or to the right of the field).
- Use inline hints to guide the user when clicking on a field.

Posted in Uncategorized | Leave a Comment »

When to use inline validation

Posted by Danni on December 6, 2009

Still uncertain whether inline validation is worth it for you? Can inline validation make your businesses happy? How useful it is to you and your customers depends mainly on your form content.  It may be distracting if overused or misused. Expect that you need to spend some time redesigning your form and copy to accomodate for inline validation. Else you may introduce new usability issues. Not to forget the development costs and testing the implementation which is vital for rich interactions as these.

When is inline validation useful

- Registration forms, where comparing user input to server data may prove useful to find out if a new domain name is available or password is secure enough.
- Unique fields such as usernames.
- Exceptionally long forms or forms with many fields, where filling in or returning (pogosticking) back to the page is experienced as very painstaking at the point that it risks several users bailing out of the process.
 For longer forms it is better because it prevents the user from being overwhelmed if there are a lot of issues.
- Time-critical situations, where a user focus is dedicated entirely to a field and real-time feedback is essential and expected. Also if the user wants immediate assurance that data is valid or how to correct it as soon as possible.
- Data-critical situations. If a user needs immediate assurance that submitting is not is risky or input data cannot be undone. He might want to know the consequences of his input or selection before submitting the data. Can he still correct wrong data? Make it clear that undo is available or returning back to the form will be possible, for example by using progress indicators to show the user the form filling is a multi-step process with a confirmation step before final submitting. Or (like Amazon) writing under the submit button a text: “You will have the chance to review your order before it is finalized”.
- Forms with complex data and strict formatting. If users might doubt during or right after filling in a field, inline validation might be just what is needed to give that instant confidence boost and motivate the user he’s on the right track.

When is inline validation less useful

- Order forms. Typical order forms ask a user for contact and payment details, which is pretty standard stuff to the user. I don’t expect it to improve form completion time much, if at all.
- Tricky copy. With Inline validation error messages appear suddenly which is why they are usually placed next to fields rather instead of in between them. Some designs are limited in space hortizontally, so error messages need to remain short. Shortening error messages may potentially make them less clear and less usable. After all, error messages should not only say that something is wrong, but may also need to say what is wrong and how to correct it (sometimes with examples or formatting suggestions).
- Tricky audience. Websites with relatively many users with different browsers or with Javascript disabled. Inline validation can come as a penalty to non-broadband users with slow connections. Slow PC’s may also be affected depending on what technology you use for implementation.

Consider your users and your form

Ask yourself the following:
- What information do I ask from the user in my form?
- Which fields might the user have trouble filling in?
- If you’re desperate for quick results, have you considered first making other general form improvements?
- Will the time/resources invested in inline validation outweigh the increase in conversion?
- Is there a risk it will decrease it? By definition for any design: less is more, meaning don’t clutter your design with elements which don’t add value.

Measuring the impact of inline validation

If you can implement inline validation, test it on a small audience and revert back to your old design easily, go right ahead. When you want to measure if it makes a quantitive difference (conversion rates) then A/B split testing will give you the answers you’re looking for. But remember to measure other KPI’s, especially if you expect no or not much effect on conversion.

Conversion is critical to businesses, and customer satisfaction often comes secondary. I predict it won’t make a difference to conversion rates of most order forms, but can benefit in other situations where inline validation is useful (e.g. sign-up forms where usernames are scarce or where there is a strict password policy or other complex fields) – discussed earlier in this article.

Consider the effect on other KPI’s like customer satisfaction and lead generation. User experience may improve or suffer. SEO, performance, compatibility may suffer and these play an equally important role in conversion. In some instances lead capturing may be incomplete and lead generation may decrease. Plan the A/B testing well.

In the case conversion/lead generation impact is insignificant, I highly recommend that you also measure the impact on customer satisfaction. This could be measured via a usability test, but preferably via a web questionnaire.  

It could A/B test to measure differences in KPI’s such as:

o        form or order completion satisfaction rating

o        form completion difficulty

o        company friendliness/helpfullness rating

o        form completion time (subjective)

Posted in Uncategorized | Leave a Comment »

Inline validation design and implementation

Posted by Danni on December 6, 2009

This post is a continuation of the article about Research into inline validation.

When (re)designing a form for inline validation you might come across some challenges. This article discusses some issues and considers some suggestions on how to solve them.

Design challenges

With inline validation forms become very dynamic. Because inline validation occurs while the user fills in a form, there needs to be adequate room for helpful error messages. The form probably needs to be redesigned to make room for these messages. This may have some negative consequences. Error messages being inserted and removed between fields may confuse and annoy users due to fields constantly moving from their original position.

This could be solved by:
   - Compacting forms (horizontally). Its nice to place error messages right next to the field they are refering to. The form may need redesigning (decreasing widths of input fields) for these error messages. This may create new usability issues or new design challenges. 
  - Increasing vertical whitespace between the fields. Increasing forms vertically has many downsides. A longer page might convert less well and makes labels less scannable. It may put off users from filling in the form in at all.
   -  Shortening error messages texts, with the risk of making them potentially less clear and less helpful.
   – Call-out error balloons may overlap other elements, or even obscure other error balloons.

But during design also remember to:
- Prevent error messages from appearing above or below the fold and out of sight.
- Don’t make an error message a Javascript dialog.
- Showing each error message near the field itself instead of (only) at the top of the page is better usability. Of course this is essential in inline validation.

Checkmarks: in or out?

In inline validation a correct field could be marked by a tick or (green) checkmarks. The purpose of this is to reassure the user that what was typed in that field is correct. The business value is that it can help motivate users by giving them the confidence that there is no error so they can continue.

If you use inline validation, you shoud stive for consistency. Just like error field might need an error icon, so should every valid field probably also needs a checkmark. Leaving the checkmark out may make users uncertain about the fields that do not contain an error symbol: are these fields correct, or is the system still checking them? This is especially an issue if you plan to use inline validation only on certain fields.

On the other hand, consistency can be a bad thing. Watch out for the christmas tree effect: it could leave you with many green (valid) and red (error) colours blotted over your form. Ensure your form remains clean and aesthetic. Checkmarks that fade out are easily missed by some users.

The tick or checkmark is the most common symbol to indicate that a filled in field is valid. Consider the effect of leaving them out; they might not be needed at all. Can you afford to go for inline validation for only a few fields, or will it make people think and doubt?

The checkmark as a confirmation of acceptance or pass may not be universally understood by all cultures. Some plausible variants of checkmark:
- OK text (preferably in green)
- smiley
- thumbs up
- VALID text (best for accessibility is an icon that includes the word “valid” or an even more specific messages such as “valid email address”)

Animating checkmarks
To avoid the christmas tree effect, you might want to make disappear or fade out after a few seconds. [2]: “Yahoo provides instant feedback each time users fill in a field by showing a tick at the end of the field. Each tick disappears after a few seconds. The majority of the participants commented they did pay attention to them. However there were mixed opinions from the participants on the animated ticks. Some of them gave positive comments, whilst others thought they were distracting.”

Implementation challenges

Inline validation comes at a cost. Is there hope? Possible work-arounds for the cons

- Leads: Capture e-mail address and contact details first. Ensure you capture data while a form is filled in, and not only upon clicking submit button. This requires an AJAX like server communication, with more costs…
- Smart format recognition: Ensure forgiving input (make the system smart in recognising errors and correcting them itself).
- Requires Javascript. Use a lightweight Javascript. Around 2% of users have Javascript disabled (on purpose). If you want to support users without Javascript, you might want to use inline validation with normal validation as a back-up. Alternative technologies are Flex/Flash, Java and AJAX, although Javascript is your best bet due to its ubiquity.

Remember:
- Scroll to the first error onSubmit, as even for large resolutions the error might still be out of sight (outside the fold).
- All client side validation (onBlur) must be enforced with server side validation (onSubmit)

For a comparison of server-side and client-side validation (ideally you should have both in case one fails), see this article. 

Developer toolkits

http://jquery.bassistance.de/validate/demo/milk/
http://livevalidation.com/examples
http://www.adobe.com/devnet/flex/quickstart/validating_data/

Posted in Uncategorized | 1 Comment »

Inline validation: pros and cons

Posted by Danni on December 6, 2009

Inline validation: benefits (advantages) and costs (disadvantages)

If you’ve read our article about research into inline validation you have found that ….

There are some. A comparison.

Pro’s:

- Helps with tricky fields. Appreciated by users for fields which they want to provide extra thought and care (username, password) or are tricky to fill in (bank account and credit card numbers) or are typically written in various forms.
- Immediate help. Appreciated by users because form completion time can be shortened due to immediate feedback. Users remembered what they just typed, so they are in the flow of providing that data and are also more capable of correcting it.
- Motivation. Encourages the user by affirming that everything is correct and that he will not remain in the same page but arrive at the next page after clicking the submit button.
Shorter forms. With inline validation error messages will usually appear next to rather than under fields, depending on where error messages appear. On the other hand, if there are 2 fields placed next to eachother and they are both wrong, how and where will system communicate this?

Cons:

- Cost. Can be expensive to implement (server-side).
- System performance. Inline validation may lead to larger scripts, server slow-downs (if error rate is high) 
SEO. More Javascript may mean heavier, more complex pages. Google might rate your form page lower.
Expertise. If not designed properly can harm usability and conversion. Also testing intensive.
- Leads. May harm lead capturing and lead conversion (especially if user encounters an error, is discouraged to continue filling in the form)
- Surprise and distractions. Users don’t know that their form is being validated until they notice a checkmark or error message. Badly designed checkmarks are interpreted with confusion, so it needs to be clear what they represent to be understood. Clicking Submit must scroll the browser window to show where the first error is.
- Disrupting. Completion mode versus revision mode theories tell us that interupting a user interupts his mental flow (especially for those users who hardly look up to the screen from their keyboard). Does this lead to increased form completion time? 
- Conversion benefit unknown. Requires A/B split testing to determine if it really makes a difference on conversion without doing too much harm to gaining leads.

Posted in Uncategorized | 1 Comment »

Asterisks or optional fields

Posted by Danni on December 5, 2009

Posted in Uncategorized | Leave a Comment »

Research into Inline validation

Posted by Danni on December 4, 2009

Inline validation may seem useful at first insight, but should be implemented carefully and only if appropriate. If you’re still sceptical about its costs and benefits are, read on.

In this first article of the series … In this article I help you outweigh the pro’s and cons and provide existing researches and a checklist. You can also read about the design and implementation challenges you might cross.

Inline validation is generally useful where users would expect it, like when filling in a username to see if it still available or a typing a new password to check if it is long and secure enough. If the system is not forgiving and is strict about format types, the user might start to wonder. Also, most users want to complete the form as fast but accurate as possible. If they click Submit and go to the next step, they might be less pleased to see the same form again (with errors communicated) and make the effort of correcting any errors (and waiting for the next step again).

What is inline validation?

Inline, real-time, or instant validation is a error communication strategy in electronic form design. A system responds immediately to an error, constantly validation user input and providing immediate feedback about input errors during filling out a form.

Two variants of inline validation exist:
a) On-the-fly: any error is communicated in real-time or instant, meaning as soon as the user has typed an invalid character in a textfield.
b) OnBlur:  any error is communicated only after a user leaves a field by clicking outside it or clicking another field.

The opposite of inline validation is afterwards validation or on-submit (onSubmit) validation. That means that errors are communicated only after the user has clicked the submit button.

Just show me the numbers (or research)

Does inline validation increase conversion? When using inline validation on sign-up and ordering forms, do we really win more confidence from the users or only disturb them in their mental flow while filling the form? Research about inline validation and its advantages for conversion is scarce and contradicting. There are no hard sales figures or proof of increased conversion, because research about inline validation is not conclusive about the link yet between different form types (sign-up form, order form or other) and design (content, error behaviour) in relation with its added value on different types of forms.

Research case A: inline validation didn’t help

One research paper covers ‘usable error messages on the web’ [1] (not confirmed) that afterwards validation is more ‘effective’ than inline validation. I’m not sure what they mean by ‘effective’, but I deduct from the table of contents of the article that they define ‘effective’ by:

  • lower error rates.
  • lower time to complete.
  • higher subjective ratings.  

Summarizing their findings:

 When users are completing online forms present the errors after the user has completed the form.
-          When completing an online form users have two flows or modes: Completion Mode and Revision Mode.
-          Users tend to ignore immediate error messages when they are in Completion Mode.Of the six possible ways to present error messages, thee proved to be more effective (?) than the others:
o        Present the errors afterward, embedded in the form, all at once.
o        Present the errors afterwards, embedded in the form, one by one.
o        Present the errors afterwards, in dialogues, one by one.Where presented with inline validation, users often simply ignored the messages on the screen and continued completing the form as if nothing happened. These results lead to the postulation of the “Modal Theory of Form Completion“: Users are in either “Completion“ or “Revision Mode“ when filling out online forms. These modes affect the users way of interaction with the system: during Completion Mode the users disposition to correct mistakes is reduced, therefore error messages are often ignored.

Interestingly most users don’t actually look at the inline validation unless they are worried their answers might be wrong. As soon as the user hesitates they look at the form and can see straight away whether their answer is right or not.

Research case B: inline validation helps

On the other hand, an article by Luke L in the aListApart.com article has opposite and positive findings on inline validation:

  The inline validation version had:

  • a 22% increase in success rates,
  • a 22% decrease in errors made,
  • a 31% increase in satisfaction rating,
  • a 42% decrease in completion times, and
  • a 47% decrease in the number of eye fixations.

A discussion on ixda.org summarises:

“His research suggested that:

  • validating data that shouldn’t be validated (e.g. first name, last name) was regarded as weird and confused users.
  • speedy, immediate checking of data that should be validated (e.g. is my choice of username available?) is welcomed by users and helpful
  • attempting to validate data before the user has finished typing is intrusive and disliked by users (a point we explore further in our book: it’s all about interrupting the user’s turn in the conversation). “
  • Research conclusions

    Inline validation can either harm or benefit your customer satisfaction and conversion. Every forms differs in content and design, so each research will differ in their findings. Not all design research is universally applicable; we should learn from the context rather than to generalise conclusions.

    What’s next?

    Read related articles on inline validation:
    Pros and cons of inline validation
    Design and implementation challenges

    When to use inline validation
    Preparing for inline validation

    References

    [1] Usable error message presentation in the World Wide Web: Do not show errors right away
    by Javier A. Bargas-Avilaa, Glenn Oberholzerb, Peter Schmutza, Marco de Vitoa and Klaus Opwisa

    Examples

    Sign-up form examples:
    Yahoo! mail sign-up page
    Mint.com sign-up form
    TypePad sign-up form
    Audible.com sign-up   (username onBlur, others onSubmit)

    Order form examples:

    Posted in Interaction Design | Leave a Comment »

    Conversion tips

    Posted by Danni on October 21, 2009

    Keywords: increasing conversion improvement optimization

    - SEO
       - unique content
       – TITLE tag
       – fast-loading (light) pages
       - H1, H2, etc
    - Call-to-action buttons above the fold

    Need quick conversion tips?
    Check these articles:
    Ton Wessling @ http://www.searchcowboys.com/events/522

    Check these sites:

    Posted in Uncategorized | Leave a Comment »

    Protected: Password post test

    Posted by Danni on October 9, 2009

    This post is password protected. To view it please enter your password below:


    Posted in Uncategorized | Enter your password to view comments

    Constructive criticising design and usability feedback

    Posted by Danni on August 18, 2009

    There are times when you have to tell a website owner or another designer what’s bad about their design or site. In face-to-face discussions the way you communicate for optimal effect is crucial.

    How to give critique

    • Just ask yourself these questions during your critique: What did I enjoy about this design and why? What concerns me about this design and why? What does this design remind me of and why?
    • Talk about the bigger picture/rationale. Instead of saying, “While I think those flyout menus are slick, I recommend you nuke them and put the links in the center of the page,” the critic might ask, “What alternatives did you consider for the flyout menus?”. While, in any project, practical constraints often win out, discussing the higher level concepts help the design owner (and other team members) make better decisions going forward.
    • Respect the design owner. Start with some positive feedback.
    • “Have you considered…” is a great way to start an important criticism, since it gives the design owner a chance to say, “I did, but I chose this direction because…” Now, the team can talk about the bigger issues behind the rationale instead of nit-picking the design details.

    Other possible topics for this post: how to gather and structure critique.

    Inspirational sources:

    http://webdesign.about.com/od/authoring/a/aa100699.htm

    http://10steps.sg/articles/ways-to-handle-design-criticism/    (Dealing with criticism)

    http://www.smileycat.com/miaow/archives/000990.php

    http://www.intute.ac.uk/cgi-bin/browse.pl?id=artifact772

    http://eprints.qut.edu.au/1830/1/Teaching_Indust_design_Criticism_Seongnam.pdf

    Posted in Uncategorized | Tagged: , , , , | Leave a Comment »