CHI-WEB Archives

ACM SIGCHI WWW Human Factors (Open Discussion)


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
"ACM SIGCHI WWW Human Factors (Open Discussion)" <[log in to unmask]>
Thu, 12 Mar 2009 17:46:43 -0400
David Reid <[log in to unmask]>
text/plain; charset=US-ASCII; format=flowed; delsp=yes
David Reid <[log in to unmask]>
Hilary Bienstock <[log in to unmask]>
text/plain (143 lines)
Yes, we have used a bar to communicate status. More specifically,  
we've often defined the bar's multiple steps as "phases" rather than a  
sequence of pages. At times, the steps align with the pages, but more  
often a series of tasks exists in one step/phase and maintaining  
context and orientation is the priority.

We've used this for insurance enrollment and financial applications  
for new account creation and have seen positive results. Through  
iterative testing we learned the distance from current state to end  
state is typically what the user is expecting to see - e.g., how much  
do I need to do?

We also learned the required time is difficult to estimate as it  
depends on the individual's personality (ex., is s/he prepared to  
answer a particular question, technically proficient, impatient,  
etc.). The progress bar is very effective and highly recommended for  
more than 2 phases to sequence of required tasks.

David Reid
Managing Partner

radiant UX
527 Bangs Ave., Suite 12
Asbury Park, NJ 07712

(732) 807-3377
(732) 676-7609 fax
[log in to unmask]

A Human-Focused Strategy & Design Group

On Mar 12, 2009, at 3:58 PM, 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
> [log in to unmask]  :: 310.883.5818  ::  fax 310.829.2839
> ________________________________
> From: claire rowland <[log in to unmask]>
> To: [log in to unmask]
> 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 <[log in to unmask]> 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

    Tip of the Day: Quote only what you need from earlier postings
     CHI-WEB: POSTINGS: mailto:[log in to unmask]
              MODERATORS: mailto:[log in to unmask]