Quando lavoriamo su sistemi consolidati, ho spesso trovato il modo di migliorare un'interfaccia utente per massimizzare l'efficienza dell'utente (ad esempio: la schermata di manutenzione delle app legacy non consente operazioni su più righe, in cui fare ciò potrebbe far risparmiare ore utente a settimana il metodo esistente "modifica una riga alla volta").
La sfida che incontro è che un miglioramento della GUI è qualcosa che non posso applicare universalmente a un sistema senza uno sforzo di programmazione più consistente (uno sforzo che è improbabile che la gestione approvi).
Quindi ho difficoltà con la decisione di provare ad aggiungere il miglioramento in una schermata o di rinunciarci finché il progetto mitico non sarà approvato un giorno.
Non farlo significa che il sistema non consente agli utenti di essere più efficienti, e questo mi infastidisce, come se io avessi volutamente permesso un acceleratore su di loro che non meritavano.
Ma farlo significa che ora c'è qualche incoerenza nella GUI del sistema. Non tutti gli schermi funzioneranno allo stesso modo, il che può creare una potenziale confusione.
Considerate le vostre conoscenze ed esperienze, qual è la migliore pratica qui? Consistenza o efficienza?
Aggiorna
Grazie a tutti per le vostre risposte. Ho svalutato tutte le tue risposte riflessive. Ho familiarità con l'articolo di Spolsky con i collegamenti di Robert Harvey. Il cambiamento a cui mi riferisco è meno rischioso di tutta la riscrittura dell'esempio di Netscape a cui si riferisce, ma l'articolo è pertinente e sempre una buona lettura.
Questa domanda è stata stimolata da un momento in cui ho trovato un modo per consentire agli utenti di elaborare gli articoli per la fatturazione più rapidamente, quindi si potrebbe sostenere che ha migliorato l'efficienza delle entrate, tuttavia, come molti di voi hanno accertato, non è stato critica. Le parti interessate hanno ceduto al divario tra le decisioni e le conseguenze e, dato che non erano quelle che dovevano fare il data entry, erano più che felici di lasciare che gli utenti languissero con l'inefficiente interfaccia grafica. Tuttavia, l'artigiano che è in me vuole un miglioramento continuo e, come dice Justin Cave, se non fai niente, il tuo sistema non si sta evolvendo, è stagnante.
In alcuni altri casi ho fatto ciò che è suggerito nelle risposte e ho tentato un approccio di base, facendo sì che gli utenti spingessero per il cambiamento attraverso i loro rappresentanti delle parti interessate. Ho trovato che l'approvazione per i cambiamenti incrementali che hanno rotto la coerenza dipendono dall'accessibilità agli utenti finali, una parte interessata nelle riunioni di richieste di modifica e, stranamente, dai leader IT a cui è interessata o non interessa affatto l'applicazione in questione. Quelli che si prendevano cura dell'empatia con il dolore dell'utente finale e quelli che non erano a proprio agio lasciavano la decisione ai subordinati che lo facevano. I moderatamente preoccupati si gloriano sul principio di coerenza che è discutibilmente lodevole ma a cui la rigida adesione senza un piano di cambiamento significa ristagno.