I think you need to answer the question, "What is the actual cost to the business of slowing down the process of finding data?"
Multiply the additional time it takes to use a view-only interface by the dollar cost per minute to the company of a rep's time, and you'll have a concrete reason to create a more usable interface. Unfortunately, the only way to get a measure of the difference in time needed between the two approaches is to conduct usability tests, which may not be part of the development budget (perhaps?). Hope that helps. -Anne On Wed, Jul 15, 2009 at 3:10 PM, Alan Wexelblat<awexelb...@gmail.com> wrote: > 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 ....... disc...@ixda.org > Unsubscribe ................ http://www.ixda.org/unsubscribe > List Guidelines ............ http://www.ixda.org/guidelines > List Help .................. http://www.ixda.org/help > -- Anne Hjortshoj | anne...@gmail.com | www.annehj.com | Skype: anne-hj ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... disc...@ixda.org Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
