Sketching User Experiences: Getting the Design Right and the Right Design (Interactive Technologies) by Bill Buxton

Sketching User Experiences: Getting the Design Right and the Right Design (Interactive Technologies) by Bill Buxton

Author:Bill Buxton [Buxton, Bill]
Language: eng
Format: mobi, pdf
ISBN: 9780080552903
Publisher: Elsevier Science
Published: 2010-07-27T14:00:00+00:00


I’m not sure who first used the term “Wizard of Oz” in the context of interaction design. I first heard it from one of my early influences, John Gould, of IBM. But regardless of who coined the term, the meaning is pretty well understood internationally (unlike the story): the Wizard of Oz Technique involves making a working system, where the person using it is unaware that some or all of the system’s functions are actually being performed by a human operator, hidden somewhere “behind the screen.”

The objective is not to make the actual system, but to mock up something that users can actually experience, thereby enabling us to explore design concepts in action and as experienced far earlier in the process than would otherwise be possible. Such a system should be cheap, quick to realize, disposable, not the real thing, and only have sufficient fidelity to serve its intended purpose. That is, it should have all the attributes that characterize a sketch.

Inherent in all this is the following rule:

Generally the last thing that you should do when beginning to design an interactive system is write code.

Now I know that a very large proportion of interactive products are software driven, and that the status quo is that software engineers play the primary role in their development. Having gone through this myself, I also know the amount of time and effort that these same software engineers have expended in acquiring their skills. I even know that they or their parents probably spent a fortune paying for that education. But I also know the following rule:

If the only tool you have is a hammer, you tend to see every problem as a nail. (Abraham Maslow)

Having gone through all the effort and expense to develop these skills, the natural inclination is to damn well use them. And the better you are at it, the more likely it is that this will be the case. After all, that excellence probably came at the expense of not developing other skills (since there are only so many hours in the day and nothing comes for nothing). So the point here is that all the biases in the status quo stack up against the Wizard, and in favour of programming and engineering. Not just from the individual perspective, but also from that of management, who have made a huge investment in the best programming talent available. (“What? I hire all these great computer scientists and engineers and now you are telling me not to use them?”)

It is precisely because of the magnitude of this investment that we must make a conscious effort to manage things along a different path. These resources are too expensive to squander on a product that is almost certain to fail—and fail it will most likely do, if one leaps into engineering prematurely.

I hope that it is clear that I am not trying to downplay the importance of programming and engineering skills I am simply saying that the front-end of the interactive design process is generally not the appropriate place to apply them.



Download



Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.