That said it was nice to see them all compared to each other in a clear and concise manner. It’s a little analysis I never bothered to do, and will probably be useful down the road.

Do you have any recommendations or comments on designing for dynamic wizards (where number of steps in the wizard is determined by the user)?

The problems that I ran into with designing dynamic wizards are:
can’t tell the user how many steps it would take to finish the wizard, and displaying correct status indicator.

Let’s face it though, much of the boxes and arrows conent is NOT ground breaking. Many of the topics have been covered 5, 10, 15, & more years ago. Look at design history, early HCI literature, work in data visualization, Dreyfuss’s book on Designing for People, etc, etc…

Good article I thought. Well written & thought out.

On a more abstract note, there’s something interesting going on in Ben and Liam’s comments. My goal with these articles is not so much to break new ground but rather to describe the workings of proven interaction design mechanisms so that less experienced designers can make more appropriate use of them. To my eye there is no shortage of poor design that could easily be fixed by a better understanding of these basics pattern.

This approach stems from my philosophical position that design in general, and certainly interaction design in particular, is fundamentally a craft — a craft that is both easy to learn and difficult to perfect. The implicit disappointment in Ben’s comment however points to a different, competing philosophy, a philosophy that sees interface design as a type of science that is constantly evolving new knowledge and new techniques.

I suspect the truth is somewhere in between those two positions but would be interested in hearing what others think.

I do have a few nits to pick, however…

1) Terminology: yes, the term “Wizard” sounds like techno-obscurantism. However, many users coming from a mainstream GUI background (i.e., Windows) tend, in my experience, to already be familiar with both the term and (roughly) the concept. So using it lessens the learning curve and the need for having to explain the flow of that (wizard) UI. This is a win, though not necessarily a big one.

2) Both the diagram and the example screenshot of a Wizard show a ‘Start Again’ navigation path. While I think that is a defensible addition the normal navigation paths in a wizard, it *is* a quite unusual one! So, I would change the diagram so that there were just left/right arrows between adjacent bubbles on the diagram–that would much more closely correspond to a ‘traditional’ wizard.

3) Finally, it is not clear to me that the distinction between a ‘wizard’ UI and a ‘guide’ UI is a useful one. They _both_ look like wizard UIs to me, except that the latter one has some (what I call) non-linear navigation paths added.
Furthermore, if you think about it, the BA.COM screenshot example (and the wizard diagram) could be considered as using a ‘guide’ UI design, albeit a degenerate one where the only non-linear path support is the ‘back to start’ one.
So I would refer to the two UI designs as: a ‘traditional’ wizard vs. a wizard with non-linear navigation added.
I’ve seen implementations of the latter in both GUI (Windows) applications and in Weblications. For an example of the latter, go to: http://www.sonexis.com and then click on the button entitled (“See the Power of the Sonexis Conferenceing Solution”), in the middle of the home page. When you see the UI entitled “Schedule Conference For Later”, notice the captions over in the left ‘sign post’ area–these are actually hyperlinks and, thereby, support non-linear navigation of the wizard.

In terms of your final point, I agree that the distinction between wizards and guides is a subtle one. However, I chose to differentiate the two because I wanted to enforce the point that the strict, linear wizards are too often used in situations where they are not required. My hope was that by referring to guides as a separate type of workflow it would inspire readers to seek out solutions that supported the additional navigational flexibility characteristic of guides.

Thanks again for your comments and I’ll try to make sure that it’s not quite another full year before my next article. 8^)

In this case, a Wizard serves an important function: hiding complexity that is not required for all users. In this sense, a wizard is much more than a single form broken up into tranches… And a guide would not enhance the experience, unless the “hub”-style map changes its shape based on user selections.

Thanks for pointing out the omission and apologies for my near-total brain cramp 8^)