I was leading a requirements meeting for a self service application recently when I heard the words that all experienced VUI designers have heard at some point in their careers: "This application is on our web site. Just look at that and use that for your design." I nodded, took a breath, tried not to digress too far into an explanation of how web design and VUI design differ, and agreed to look at the web application.
Trying to understand requirements from visual web designs is something I call design archeology. Any software interface is a collection of design decisions constrained by business requirements, user requirements, technical limitations, prior practice, existing standards, and often just the arbitrary personal preference of the designer. One field on a web page follows another because there's a business or technical reason, and sometimes there's no reason at all. Working backwards from design to requirements is a little like a physical archeologist trying to learn something about the way a culture functioned by excavating the site of an ancient city. The archeologist, digging through the dirt, makes inferences about artefacts based on the depth to which they are buried, the condition they are in, their location within a room, their proximity to one another, and so on. It's guesswork a lot of the time.
So it is with design archeology. I have the advantage over my counterparts because I can ask my clients questions about my hypotheses. Often, though, the creators of the web application have moved on and the answer is, "It's done that way because that's the way it was when I arrived." Often the original business rules were never captured anywhere but in the design itself.
Of course, it's important to parse out the requirements from the arbitrary aspects of the design because you need to know what you can safely change and what you need to preserve in your own design. And so it goes: dig dig dig, find, form hypothesis, check with client, dig some more. All in pursuit of a usable VUI design that will serve callers' needs.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment