When working on established systems, I’ve often found ways to improve a user interface to maximize user efficiency (example: legacy app maintenance screen doesn’t allow multi-line operations where doing so could save the user hours per week over the “edit one line at a time” existing method).
The challenge I encounter is that a GUI improvement is something that I can’t apply universally to a system without a more sizable programming effort (an effort that management is unlikely to approve).
I then struggle with the decision to either try and add the improvement in one screen, or give up on it until the mythical project is someday approved.
Not doing it means the system is not enabling users to be most efficient, and this bothers me, as if I have purposely allowed a speed throttle on them that they don’t deserve.
But doing it means that now there is some inconsistency in the system GUI. Not all the screens will work the same way, which can create potential confusion.
Given your knowledge and experience, what is the best practice here? Consistency or efficiency?
Update
Thank you everyone for your answers. I have upvoted all your thoughtful responses. I am familiar with the Spolsky article Robert Harvey links to. The change I refer to is less risky than the whole rewrite of the Netscape example it refers to, but the article is pertinent and always a good read.
This question was spurred by a time when I found a way to make it possible for users to process items for invoicing faster, so it could be argued that it improved revenue efficiency, however, as many of you ascertained, it was not critical. The stakeholders succumbed to the decision-consequence gap, and as they were not the ones having to do the data entry were more than happy to let the users languish with the inefficient GUI. However, the craftsman in me wants continuous improvement, and as Justin Cave says, if you do nothing, your system is not evolving, it is stagnating.
In some other cases I’ve done what is suggested in the responses and tried a grassroots approach, having users push for change through their stakeholder representatives. I found that approval for incremental changes that broke consistency have depended on accessibility to end-users, a willing stakeholder in the change request meetings and strangely enough, IT leaders that either cared very much or not at all about the application in question. Those that cared empathized with the end-user’s pain and those that didn’t were comfortable leaving the decision to subordinates that did. The moderately concerned would glom onto the consistency principle which is arguably laudable but to which rigid adherence without a plan for change means stagnation.
Your goals may differ from those of the stakeholders.
-
The stakeholders may already be familiar with the interface and its quirks. Changing it, no matter the improvement, will initially add friction, and require a training effort.
-
The software is already making money for the organization. Any change to the software eventually needs to translate to potential improvements in future revenue.
Most system evolution is gradual. For a cautionary tale about cataclysmic change, see here:
http://www.joelonsoftware.com/articles/fog0000000069.html
Ask the application owners.
More than likely, if you can save each user multiple hours every week and the trade-off is that they need to train the users to understand that different screens work slightly differently, they’ll jump all over the request. At a cost of, say, half an hour of training per user, they’d gain many times that investment in productivity in the first week. That’s a pretty easy decision for management to make. Most likely, they’ll then push to make the same change on a number of other screens. Perhaps they’ll want to make the change to half a dozen screens before rolling the change and the training out to the users.
In the vast majority of established applications, you’ll see traces of different approaches to development and to designing the user interface. It makes little sense to remain consistent with the first screen that was built when new techniques, new architectures, and new information about how the users actually interact with the system have given you better ways of building things. On the other hand, it often makes little sense to invest the time to rewrite years of work just because you’ve found an incrementally better approach. Waiting for the “big bang” project that will likely never come means, in practice, that nothing ever gets better.
In my (limited) experience, if you have to apply a cataclysmic change, you’re dealing with a design oversight of some kind, which makes it more dangerous than most people would already portray it as. I am reading your case as a ‘would be nice’ feature, instead of a ‘must have immediately!’ feature, so lucky you, this one shouldn’t be too painful…of course, your manager might not agree, because of that.
Because of this, I would go with the gradual approach. Try making the GUI control a multiline, but before you commit, get some stockholder input, and see if they want this everywhere, and an unofficial estimate of just how much time they expect to save with a multiline control, or if it even will save them any time. If they like it, they’ll probably out-and-out tell you a few more places that this would save them effort instead of just ‘everywhere’ (though, they could say that too.) Either way, you’re going to be expending effort to make this happen, and a prototypical upgrade will save you the trouble of figuring out the gotchas of making this GUI change.