That didnt make it any clearer. The only reason why change in banking would be more expensive than other areas would be because of the strict security issues. I.e. you would develop something that would have to change the security system and the reprogram the same security system.
But if that is the case, then you will most likely have to adhere to those restrictions anyway given that those systems are pretty limited in what they allow you to do so you cant really screw around with that part. Obviously if the bank anyway gives you the freedom to propose something that affects security issues you should thread carefully but I find that an unlikely scenario and I find it even more unlikely that you would catch it in a usability test. Now if you are lucky you work with a banking system that has more freedom once a secure connection is being established your design patterns would not be any different than what you would normally use and you would anyway operate within some sort of "sandbox" before you submit your data back to the core database. I am currently working on a self-service channel for a bank and frankly have yet to see what you could propose (unless as said above program and reprogram security) that would make it substantially expensive to change any more than any other area. But thats of course just my experience, I am still interested in understanding exactly what part it is you think make it more expensive. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Posted from the new ixda.org http://www.ixda.org/discuss?post=46278 ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [email protected] Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
