Let users help you fix that dreaded screen.
Call it the screen from hell. Your users do. They dread that screen. But they can’t avoid it – it’s in an application they use every day, or even all day long. Maybe they have to copy information off the screen with pen and paper, then type it in again. Maybe they have to back up two screens if they mistype anything. Maybe if they accidentally tab past a field, they have to start all over again. What’s certain is that it’s the kludgiest, most user-hostile screen they deal with, and it’s been on their fix-this request list to IT for years.
But it doesn’t get fixed, because the screen from hell is just as ugly, kludgy and dread-inducing to programmers as it is to users.
Your developers can’t just patch it up – that’s how screens from hell come to be, from an endless series of hacks and quick fixes that result in an awful, unmaintainable mess.
No, they’d have to replace it, unscrambling and recreating all the complex, jerry-built business logic that has evolved through all those years, matching the function of all the weird kludges and patches that someone once needed to get all the right data from all the right sources onto that hellish screen.
And that will be painful, expensive – and risky. Maybe it can’t be done. If you fail or get it wrong, users will blame IT. And all this is for one lousy screen, so it will never look like it’s worth the trouble, misery and risk.
No wonder you’ve dodged it all these years. And no wonder users hate you for it. Can you ever get rid of the screen from hell? Maybe, if you’re willing to put those long-suffering users at the centre of the effort to fix it. Doing that could dramatically improve the chance the project will succeed – and cover your IT shop’s backside in case it doesn’t.
Start by getting the users to cost-justify the fix. If this really is a screen from hell, it’s costing users in time, effort and work quality. Get them to estimate that cost – it’s your payback from this project. (If higher-ups refuse to OK the project because the payback isn’t good enough, you’re off the hook – the bosses simply aren’t letting you solve the problem.)
Once the project gets a green light, get the users to pick a pilot group. That group’s first job: deciding on the absolute minimum functionality they can live with in the first version. Promise you’ll squeeze in everything in the end. But for now, you need a first step. Make them define it.
Then make them define the rest of the project’s road map, one new feature at a time. They know which capabilities they need early and what they can live without. (And if they leave out something crucial or waste time on nonessentials, you’re off the hook – they screwed up, not you. See a pattern here?)
Now your developers can go to work. Building the simplified first-pass screen will be a lot easier than trying to reinvent that whole hellish wheel. As soon as the pilot users approve it, you can add the next feature on the road map. And the next.
Each new feature means a new point release. Each point release must be production quality – and get the users’ OK before you go on. That way if someone pulls the project’s plug, at least users will get something out of it. (And if it’s buggy – hey, they OK’d it, right?)
If developers design it right, stick to the road map and get feedback continuously, the new less-than-hellish screen just might work. If it doesn’t work, well, you’re still better off than before. Users will understand why they’re stuck with that screen from hell. And you may discover that working with those users is just a little less hellish next time around.
Hayes, staff columnist with Computerworld (U.S.) in Framingham, Mass., has covered IT for more than 20 years. He is at [email protected].
