I once worked on a system that fulfilled the primary objective of the business and technically let the users get the job done; but to use it, you had to have a fair degree of knowledge and skills and remember how to fill in all the boxes and which boxes were meant for each operation. Although I supported it, I always had to ask the expert user how to do various things in order to test fixes, it just wasn’t intuitive. New features had been created by just creating new fields, or new tables and letting the user fill in data. Just big shoeboxes you could put things in, really.
I’ve just read http://www.baobabhealth.org/2008/02/09/text-editors-and-electric-kettles/ and would describe this application as somewhere in between the text editor and the kettle, but combining the worst features of both. The system had a very strict idea about what should be allowed, clearly assembled from years of incoming instructions, but because it made no use of functions to manage the mountain of code, the same basic instruction could be implemented in lots of places, in lots of ways.
But the users were more or less used to the quirks: they knew that when they had a scenario that didn’t fit the hard-coding, that they could falsify data or choose incorrect choices deliberately to force difference behaviour. They made their own text editor.
I’m embroiled in a project to write an operations system for a company who need infinite flexibility in the day to day nitty gritty, but overall patterns in the broad-brush approach to service delivery. I aim to provide a templating system that is adjustable at multiple levels, and give a task-based approach to the whole thing. As a user, you will be given the list of things that absolutely must be done to perform a service, and the manager can provide simple guidance that will appear onscreen when requested, as to how a task should be done.
I’ve created a monster – it’s flexible in that you can generate workflow for anything you like, but minimises training as end users will just indicate what they have been asked to provide, and it will tell them what they need to do. But from a developer’s perspective, it’s a monster. Just creating multiple levels of templating system for workflows has been interesting. I’m now working on what happens when a user completes a task, calculating the next path and generating instructions for them to follow.
One thing I’ve learned is that when you have a complex problem, the complexity can’t really go away. If the developer doesn’t want to deal with it, they have to delegate it to the end user. If the developer is foolhardy/brave enough to want to deal with it, it’s a lot of hard work.
I always develop things from the point of view of me being the end user of it. I have limited patience and am hopeless as remembering to do things unless I have a list I can check off (thanks Things.app!) and so things that would annoy me are smoothed over, and things that would be useful to me, go in. A selfish way of designing, yes, but I think I have quite good empathy and I make the effort to try and understand all the problems from all angles before I start designing.
I think you have to be fundamentally honest, as a developer, to produce something that will actually help. If you can see something is not quite going to work, you can plaster over it quite easily; or if you can’t be bothered dealing with the complexity, you can provide a simplified solution and just hope that the users can mentally fill in the complexity for you. But if you genuinely want to help the user, and make their job easier and not just different, you have to be honest and deal with all the problems you can see. I have seen too many times where ‘simplification’ of the system has lead to horrible text editor creation, where the users have to invent their own solutions to the problems that have been ‘simplified’ away. Usually this involves spreadsheets. Ugh.
No related posts.
Related posts brought to you by Yet Another Related Posts Plugin.