I've been blogging a bit lately about poor user interfaces and the developers who create them. Sometimes, the problem with the end result of software is caused by the initial project specifications. Here's are of some of the major pitfalls that can occur in any project.
The initial project specifications are not correct
All too often, the user has an idea of what they want in mind at the beginning of the project, and that vision is completely different from what they want by the end of the project. A project that takes a long time to develop is sure to not be finished before the business rules or needs change. Another problem that I have seen time and time again, is that until the user gets their hands on a working version of the product, they do not get to find out if their initial perceived needs are their actual needs. At the beginning of a project, the user may only want a few options, but once they see the power that the software is giving them, they want a lot more options. Or to go the other way, they ask for a thousand options or ways of doing slightly different taks, but find out that in reality there are only a few features they actually use, and the rest are waste.
I combat this by providing sketches and mock screenshots throughout the development process. I try to involve the user as much as possible, because I have found that it is always better to spend an hour giving them a prototype (even if none of the widgets work) that let's them get an idea of how things will work, than it is to spend weeks or months writing code that they don't want.
Users seem to think that low-output projects are low work
This is one of my favorite user misconceptions. They seem to think that the number of results directly impacts the length and difficulty of the development process. Something happened today that is an excellent example of this. I am currently working on a system that ties maps to the user's sales data and sales representatitve data. One of the people in my company sent me some information to think about using "as a demonstration." He seems to think that it should be easy or trivial for me to create results based on this data, because the data set is significantly smaller than what we normally work with. Wrong! It is no more difficult to program to handle 1 million rows of database data as it is to handle 100 rows of data. It is almost always the number of columns and the complexities of the data transformations that make a project more or less difficult. I frequently have customers ask me to run a report ad hoc that will only generate a few "bottom line" numbers. They think that because they are asking for only one row of data that this is a trivial task. It is just as much work to produce the "bottom row" numbers as a full report, because the full report needs to be made to generate the bottom row of it anyways.
The only way to beat this one is through educating your users. But there is a way to be nice about it, and give them a value add as a bonus. For example, in the bottom line number scenario, I go back to the user and say to them, "listen, to generate those bottom line numbers, I need to do a full report anyways. Would you prefer to get the full report while I am at it? It will take only a little bit longer to be able to provide a full report to you, and then you will be able to have the individual numbers as well." This way I have impressed upon them that while the amount of output they are asking for is low, the amount of work is the same as a high-output request. In addition, I am giving them the option of having information that they might not have asked for because they thought it would be too much additional work to produce. The users are very happy with this approach, and after a certain point they come to you and say "would it be much harder to do XYZ versus ABC?"
The project specifications do not match the users' goals
This one is always a problem, particularly when the people performing the work are separated by one or more degrees from the users. In fact, like a game of "Telephone", the more layers between the developers and the users, the worse the problem gets. For example, I recently had a user who needed to get names and addresses from an Excel spreadsheet, insert the information into some text to generate a form letter, and be able to print those letters at Kinko's. This was their actual goal. My project specifications were "take this Excel spreadsheet, insert these values into the text already entered into these cells, then save the individual sheets to PDF format, and make sure they look good." Between trying to take flowing text in Excel and making it "look good", and producing PDF output, I could tell that someone had given me project specs that were not properly aligned with the user's needs. They had given me project specs that matched what they thought would be the best way of performing the task, not the task that the user actually wanted to be done. I dodged this by asking to know what the user had actually asked for. Once I found that out, the project was much easier - it took a few hours as opposed to a few days.
Whenever you are given project specs, you need to get access to the user. In some companies, you may need to demand it. Many project managers get the attitude that you, the developer, needing to speak to the user reflects poorly on them as a project manager. That may be so, or it may not. But at the end of the day, you are going to be writing the code, not the project manager. It is in everybody's best interest for your project specs to accomplish the user's goals, not to fulfill a PM's vision of how you should accomplish what they perceive the user's goals to be. A PM who refuses to allow users to interact with the developers is a bad PM. Currently, my customers have my direct number. They take their requests directly to me, and they love the "self serve" aspect of it. Does my boss get involved? Sure he does, he needs to make sure that one customer's needs don't interfere with my time on other projects, that they are aware of what is within scope and out of scope of the contract, and so forth. But at the end of the day, the user is getting exactly what they need, they are in control, and they are delighted to spend the money because we are doing for them what their own staff cannot or will not do.
At the end of the day, the smaller the gap between the user and the developer, the better the product will be in terms of meeting the user's needs and expectations. Good communications between the suers and developers, while being sometimes difficult, tend to save significant amounts of time and frustration. It is always better to spend an hour talking to the user, even if they are some empty-head sales manager to get to know their real needs, than it is to spend three months designing and developing a proejct, only for the user to never actually use it, or reject it outright, because it doesn't actually do what they need, even if it does what they asked for,
More to come on this topic over the next few weeks...
Justin James is the Lead Architect for Conigent.