I think I know the answer to this but I want to present the case study for general input. Maybe someone has some brilliant idea I haven't thought of.
Situation: I'm building a large new application for helpdesk/customer support/operations people. The major use cases for this product are input of new information such as when a new customer starts up with us or a new person joins an existing customer (about 30% of the time). This also includes use cases for when an existing record is to be edited. The 70% use cases revolve around search and look-up of information, including by people who aren't authorized to edit things anyway or who just need to find a piece of information. In response to an early set of mock-ups that focused on the inputs, the users asked for there to be view-only screens. They are concerned about inadvertent or unauthorized data change. So this Monday I presented a new set of mock-ups including both edit and view "modes". The design calls for them to be very different, with the view screens optimized for quick scanning. Due to the complexity of the underlying data, the input screens have dozens of extra options that might be selected. End set-up. The presentation included developers and the dev manager. During the presentation, the developer said that he had been planning to make the "view" screens be the same as the edit screens but with all the input controls turned off / made inactive. The manager, with one eye clearly on the delivery schedule, leaped on this suggestion as a way to speed up his project. I tried to point out how ugly and clumsy that would make the screens and the user representative more or less saw my point and agreed. I pointed out that it would tak e the users longer to get everything done with screens full of inoperable controls. But I don't think Development is going to budge. The trouble here is that the user is going to suffer a death by a thousand cuts. No use cases are going to be blocked by this decision; it just means that every single action the users want to take will be more awkward and take longer. (How much longer is difficult to quantify just from the paper prototypes, but my guess is that it's a few seconds more on each operation.) We're a high-service operation, so the people using this app aren't going to be measured by the minute like a call center. So the question is whether I want to try to fight for the extra development time to implement proper viewing/scanning-oriented screens or just throw in the towel and let the users suffer. I can't marshal data to back up my professional intuition (not least because the project is already late and taking the time to gather the data to prove my point would put us even farther behind) but I'd bet a mighty fine dinner that doing things the programmer's way is going to cause pain and suffering. Sigh. --Alan ________________________________________________________________ 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
