Meet the user

Yesterday I had the opportunity to sit down with one of the users of an application I helped build last year. The project was in many ways painful to me and rewarding.
(Warning! Long story ahead! To get back to the user skip down to the bolded word monkeyshines below)
The project was painful because the charter of the project was to replace an application that the users did not like with an application that was to be as close to functionally and visually identical from the application that was to be replaced.
That's like going through an unhappy marriage, getting a painful divorce, then marrying her younger sister. It's worse than that, it's seeing all the mistakes that were made on a previous attempt, knowing they are there, and then doing it all over again. Let's start with how this happened.
Well, the goals of the project were defined by people who didn't have any stake in using it. The director who made all the decisions used the application as a reporting tool and not as a tool to update records. Her use case was to look things up and see as much information about those things at once as possible. In fact, she demanded that 26 columns of data be displayed on a page and that paging not occur. The number of rows that could appear could reasonably reach around 5000 rows. That's 130,000 data points.
These requirements were set the last time the team created the tool. These requirements had been set 5 years prior to the project I was in. The UI was created by a bunch of C programmers and mainframe programmers who were making their first attempt at creating a Java web application.
The developers violated a few tenets of my base level rules for web applications: they were opening JDBC connections within scriptlets, they overloaded buttons to add unintuitive functionality, instead of improving query performance they came up with the worst Ajaxian hack I've ever seen.
The hack was to handle when JSP pages would timeout in a browser before the response was returned from the server. It happens from time to time, especially in synchronous web applications.
The hack worked like this. The request was sent to the server. The server spun off threads to perform queries against the database. When the threads were finished they set a static variable on the thread class--safe I know.
The JSP would follow the following logic. It would load the page that rendered the results of the query. It would then check the static variables on the threads to see if the information is ready. If it was ready, the information was rendered on the page. If it wasn't, and it usually took over 5 minutes to be ready, the page would immediately reload.
The resulting UI experience was for the page to flash like crazy and the clicking sound you get in Internet Explorer when you reload a page. Fortunately for the people whose job it was to perform this application's business function, there was a pretty well made application that did the same thing that was made with them in mind. They griped that the new tool was not fast enough. They probably should have also complained that the UI design of the tool was horrible. The users just continued to use the old tool and refused to let it be retired.
The new tool that I worked on was to replace both the old tool and the old new tool. The director who funded the project left no room for training and very little for business requirements. The requirements were simple, make a new tool that works exactly like the new old tool, not the old old tool, and make it faster. Any usability improvements and you'd need to get a variance from the director.
I should mention that this director is one of the most unpleasant people I've ever worked with. At least that is the reputation that preceded her. She was by no means dumb, she held a doctorate in one of the most demanding fields--more difficult than an MD. She was known for shouting at people in meetings and trying to intimidate them. If she didn't get her way or you weren't moving fast enough for her she'd go right over your head.
I experienced a little bit of this when she found a bug while our project manager was on her honeymoon. It would have taken many of us out of our comfort zone to get a change into production with the PM gone. I tried to suggest a workaround that I thought was pretty reasonable, it required an extra step, but nothing too onerous. I sent the step by step instructions and an explanation that putting a fix to production was risky at that time and difficult. I heard nothing back for a day. The next thing I knew we had an emergency ticket demanding that the fix be put in immediately. No reply to me, just a demand straight up my chain of command.
That was her being nice. Weekly meetings before I joined the team, when the team consisted of people who were involved with that early attempt at a web app, were the stuff of legend. One contractor on the team and she would get into shouting matches each week. It could have been a cultural thing, these were both Indian women, but they really knew how to dig into each other. I never personally witnessed any of the things that people talk about in happy hours.
I think it's clear to state that the flow of usability enhancements were tempered more to a drip. Suggestions that would improve performance were even carefully crafted because she may go ballistic.
With that in mind, we went forward designing a back end that worked in a way that was as clean and sound as we could make it. We took all of the functional business logic out of the UI and put them in a respective server side service or model class. We made a very sound application on the back end. Something that I am very proud of. Considering the requirements and the bar that was set by the old new tool I thought we made a huge step forward.
It wasn't as fast as something that would could have created with collaboration from the users, but it was pretty good. Instead of 5 minutes and a clicking sound, we'd see a range of between 1 and 45 seconds depending on the parameters with no clicking. 45 seconds to pull a couple thousand rows, that's not too bad considering our constraints. The performance was deemed acceptable by the director.
The old new tool was decommissioned as well as the old old tool. Now users could only use the tool I worked on.
(Monkeyshines)
Which brings me to yesterday. Yesterday I got to sit down with one of the most frequent users. It pains me to meet with her because I can see the results of the compromises that were made because the funding party had no interest in the users. It pains me because we did not meet with the users while we were developing this application. We funded a year of work for a team of five developers, two testers and a project manager, but we couldn't bother to meet with the people who were actually going to use the product. What a waste.
It wasn't all pain though. I was able to learn more about how she uses the application and get a list of her biggest complaints. I'm going to try and funnel those into our summer internship program. I think making small enhancements will be a great opportunity for our interns. The user also learned a lot from the experience, I was able to share a few shortcuts with her, ctrl + f for find, ctrl + z for undo, ctrl + a for select all. I was also able to explain why it take a month for anything to get fixed--thank you Sarbanes and/or Oxley--or the people who interpreted that legislation as it pertains to business software development. I told her how to submit enhancement requests and that I'd do my best to get interns to help out. I also explained the constraints that we had to deal with in providing the tool. I think for her, she saw that the people who made the application that she was frustrated by actually want to provide something that isn't painful for her to use. That we want to give her something that is better. I gave her a sense of empowerment by telling her about my intern plan. For me, well, I feel better about the improvements I make. I know there are results for my work. Although my company tends to silo the people who make the software from the people who use it, we all benefited from the experience. By meeting my 'customer' I now have an emotional attachment to my work. I know that there are effects to my actions and that what I do is important to somebody. I recommend that if you have the opportunity to meet whoever it is who uses the products of what you do, be it a coworker, a customer, or whomever that you take it.