By “user friendly” I generally mean that the system should do what the user expects. It should also have as few steps in the process to get to an end as possible. It should just plain be intuitive.

By “little human intervention”, I mean that if there is a process that can be automated it should. For example, one error I saw on a system said something like please correct date to mm/dd/yyyy format. If I entered the date in mm-dd-yyyy format, it should be able to convert it automatically (although it might tell me that it did correct it if the system is something where I would want to verify changes).

I think the “support nightmare” comment is mostly a problem in my company. A lot of issues have to be resolved by IT because it is not automated or just plain left out of the system.

I like to write my code with a text editor and make my code a lean as possible. Some people still use dial up and even on high speed it is nice to have a very responsive system. So to answer your question, too much for me.

I will definately want to read “The Social Life of Information.”

freak3dot

Freak3dot, your post deeply confuses me. I can’t quite reconcile the notions “user friendly”, “little human intervention”, and “IT has created itself a support nightmare”. And when you say that HTML editors put in “too much unneeded code”, too much for whom? Is this a possible cost of doing things in a user-friendly way? You might like to read “The Social Life of Information” and think about some of the issues raised there.

At least in my corporation, the business wants everything yesterday and doesn’t care how bad it is as long as the happy path works. I can’t stand this mentality. IT has created itself such a support nightmare with this going on for years.

I think what got me started on this path is your blog “You Weren’t Meant to Have a Boss.” This is interesting because it is true that the groups do not communicate cross-department well at all.

Now of course I don’t mean the IT should literally run the business. I just mean that the processes should be as automated and user friendly as possible so that fewer people in the organization puts IT closer to the business.

Empowering the users with tools to create their own software sounds like an exercise in bloatware. Just look at a WSIWYG HTML editor. It puts in way too much unneeded code.

freak3dot

Something I always do to avoid this problem is build the UI right away, even before there are requirements. It’s usually just a hack mock-up, but it shows the user what they will get. We typically start the mock-ups after a one hour interview with the business, then we adjust it every day (with them and some representative users) until it is right. That usually takes a week.

This is a much more productive (and exciting) way to start a project than your typical analysis/requirements baloney. I find it ironic that more IT PM’s don’t use this type of approach, because they are trained so heavily in risk management and this dramatically reduces the overall risk of the project.

However, I think we are getting closer to the point where a lot of projects can avoid these problems by leaving IT out of the process altogether through technical solutions that allow users to create their own systems. We’re not quite there yet, but I can see this approach working well for some types of project.

My last project involved fixing up a power user created SharePoint site. This site contained some of the worst code I have ever seen, but the project went well for both developer and user. Development was a matter of replacing bad code with good code, with no understanding of the business required. With a (partially) working system in place already the users’ expectation of the new system wer far clearer than is possble with documents. And with a platform that supports both ugly hacks and professional development there was no platform change and the users could see the improvements without waiting for the existing functionality to be reproduced.