Re: Step n of m

Actually, I have tested using a progress bar vs showing number of 
steps.  The success of the progress bar was a direct function of how 
much the bar appeared to fill in when they arrived at Step 2.  The less 
the progress bar moved, the less "successful" it was, principally 
because of the lack of information.

John Zimmatore
User Experience
Sun Life Financial

Hilary Bienstock wrote:
> Has anyone solved this problem by using a loading bar to visually represent progress, rather than explicitly conveying the number of steps?  That might be a way to treat the problems that Claire mentioned where the number of steps can vary, and could also allow you to get rid of the issue of whether your process is one step per screen or not, since you are not explicitly calling out steps.  Any feedback on that?
>
> Hilary
>
>  
> Hilary User Experience
>                    Hilary Bienstock, Principal
>  
> [email protected]  :: 310.883.5818  ::  fax 310.829.2839
>
>
>
>
> ________________________________
> From: claire rowland <[email protected]>
> To: [email protected]
> Sent: Wednesday, March 11, 2009 10:34:34 AM
> Subject: Re: Step n of m
>
> Hi Hal,
>
> I used to do a lot of testing of online insurance quote forms.  Users
> would get quite annoyed when the numbers of steps on the progress
> indicator were not perceived to be an accurate reflection of actual
> screens, and often thought this was a deliberate and sneaky ploy on
> the part of the insurance company to dupe them into getting a quote by
> pretending the process was quicker than it actually was.
>
> Trying to make the process appear shorter and therefore more appealing
> was counterproductive: if the system had added in 'extra' screens
> once, users felt it might do it again, leading many to fear that the
> process must in fact be prohibitively long and therefore increasing
> the dropout rate.
>
> In this context it was often impossible to predict accurately just how
> many steps a user would have to go through, as some users would have
> to enter more information (and go through more steps) than others,
> depending on certain conditions.  For example, users with endorsements
> on their driving licences would have to provide codes and dates of
> each offence before being given a car insurance quote.
>
> I always recommended being as accurate as possible in matching the
> apparent steps to the actual number of screens, making sure it was
> always clear why all steps were necessary and exactly what was going
> to happen next, and explaining the need for any deviations from the
> 'normal' process which might add in extra screens.
>
> NB: This was a few years ago when adding extra questions always meant
> adding extra screens.  If you're able to use a more interactive (e.g.
> Ajax) interface, you could now dodge the issue by adding extra
> questions inline into the form as and when required.
>
> This was a different context so YMMV (insurance customers can bail out
> and phone, or  get the same product elsewhere).
>
> However, from my experience I would recommend always showing actual
> screens completed/remaining.  If it helps to clarify the process then
> show how these map to logical steps too, but make sure you show what
> this means in number of actual screens.
>
> HTH,
> Claire
>
> On Wed, Mar 11, 2009 at 1:29 PM, Hal Shubin <[email protected]> wrote:
>   
>> You're designing a wizard in a Web app. Choices:
>>
>> 1. Each step is one page and each page is one step. Benefit: Clarity --
>> click NEXT and get to the next step.
>>
>> 2. Make the steps be at a higher level, and each step could be spread out
>> over two pages. For example, the "Setup" step includes logging in to your
>> account, downloading software and installing it -- maybe it's just neater
>> (conceptually and/or visually) to break that up. Benefits: Simpler pages,
>> and it looks like fewer steps when you see "Step n of m".
>>
>> I just ran a study where one person was vocal about wanting one step/one
>> page. I don't think it mattered much to the others. Other observations?
>>
>> thanks                          -- hs
>>
>> . . . . . . . . . . . . . . . . . . . . . .
>> Hal Shubin
>> Interaction Design, Inc.
>> 617 489 6595
>> www.user.com
>>
>>   --------------------------------------------------------------
>>          Tip of the Day: Postings must be in plain text
>>    CHI-WEB: www.sigchi.org/web POSTINGS: mailto:[email protected]
>>             MODERATORS: mailto:[email protected]
>>      SUBSCRIPTION CHANGES & FAQ:  www.sigchi.org/web/faq.html
>>   --------------------------------------------------------------
>>
>>
>>     
>
>     --------------------------------------------------------------
>            Tip of the Day: Postings must be in plain text
>      CHI-WEB: www.sigchi.org/web POSTINGS: mailto:[email protected]
>               MODERATORS: mailto:[email protected]
>        SUBSCRIPTION CHANGES & FAQ:  www.sigchi.org/web/faq.html
>     --------------------------------------------------------------
>
>     --------------------------------------------------------------
>     Tip of the Day: Quote only what you need from earlier postings
>      CHI-WEB: www.sigchi.org/web POSTINGS: mailto:[email protected]
>               MODERATORS: mailto:[email protected]
>        SUBSCRIPTION CHANGES & FAQ:  www.sigchi.org/web/faq.html
>     --------------------------------------------------------------
>
>
>
>
>   

    --------------------------------------------------------------
    Tip of the Day: Quote only what you need from earlier postings
     CHI-WEB: www.sigchi.org/web POSTINGS: mailto:[email protected]
              MODERATORS: mailto:[email protected]
       SUBSCRIPTION CHANGES & FAQ:  www.sigchi.org/web/faq.html
    --------------------------------------------------------------