Saturday, October 18, 2008

Module 2 Blog Post (2)

Once upon a time I was involved in helping our ITS department in setting up a VRU (voice reponse unit). At first I was just supposed to be The Voice. I ended up being much more involved because the poor guys setting up the VRU really had no idea what options should lead to what answers (logically speaking). Helping out with the design cycle from that end really got me excited about studying program and web design.



The HCI Life Cycle includes 8 steps and the first one may be the most difficult for a designer coming in from the outside. Knowing the end-users and their goals without knowing exactly what it is the end users do every day can be tricky. What questions do you ask? You can generally ask the user what they want the system to do but how do you know the detail to which they need the system to do what it does? How can the user describe how the system should work when they've never had a system to do what they need done? How do they know what to ask for when they've never had it in the first place?

I would love a system that lets me do what I do easily but to some extent, if I don't know what the possibilities are, its hard for me to describe what could help. What if there was a system that would interface with our existing system and outside systems to collect all the pertainent data I need, makes a decision based on the data, produces the needed documents, contacts the customer, follows up and files the required claims, while adhering to required timelines? Well first of all, I'd probably be out of a job. But how do I ask for such a thing? I'd have to describe every minute detail of my job and my thought processes based on thousands of pieces of data. Would the designer know what questions to ask me to get all the needed data? I'd hate for them to come back saying, "Why did this happen?" for me to only be able to respond, "Well you didn't ask me that?"

No comments: