It’s Agile practice to work with users to define an application’s functionality and user interface. But who defines who the user is? All too often, the people who sign off on your software design are not the people who spend all day using the software. That’s just wrong.
Too often, software that is ostensibly designed to serve the user is designed for the wrong user. The people who sign off on your software – the client who pays the bills, or the executive committee that decides what the business needs – may be happy. But the person who spends all day doing data entry or relying on the application’s output curses your name.
The problem is: The user that a developer works with to design the application may not be the person who actually uses the software. You might put your heart and soul into answering the needs of the individual or every person on the committee whom you met with. You may create sturdy software that checks-off every item on that organization’s wish list.
But if that isn’t the person who uses the software, who spends all day with her hands on the keyboard, it’s impossible to create that best of all experiences: software that people love to use.
Worse: You might not be able to solve this problem.
Interviewing the Users… All of Them
Here’s a case in point – an example with which you probably are personally familiar. If you have ever applied for a job at a larger company, the sort that uses a resume-collection service like taleo, I am sure that you too have been frustrated by these applications.
These job application sites will drive you to drink. You need to register just to see a job listing. You have to fill in forms using a structure that bears no resemblance to your resume. You’re required to answer questions that are unanswerable or inappropriate for this stage in the application process (such as requiring a number for “salary expected” so that you cannot write in “negotiable” or “Let’s talk about that after we find out what the job entails, shall we?”). The user interface makes you want to scream. It’s enough to make long-term unemployment seem like a better fate than looking for a job (which is depressing enough).
But it’s easy to understand how such lackluster software came about. The programmers who designed and built those web applications worked with the requirements for only one set of users: the HR professionals who are the “consumers” of the job applications and resumes. As far as I can tell, nobody ever interviewed a job applicant to ask, “What’s the best way we can collect your background, suitability for this position, and other relevant information, to make it easier for you-and-the-company to find a perfect match?”
However, the companies that make these “talent management” applications (and the developers whom they employ) are not motivated to serve the needs of the job applicant. It isn’t the job applicant who pays their bills. It’s the hiring companies and job recruiters (and their HR departments) who decide which recruitment software to use. Their criteria are the ones that matter in the purchase decision. Features and functionality that would give joy to the most common hands-on-the-keyboard user (the hundreds of job applicants applying for a given position) may not even appear on the list of application requirements. Which means they aren’t going to be created, unless a rogue programmer somewhere (who has herself been pissed off by these awful job application tools) sneaks them in.
The best software is designed and built by people who use the application. That is why developer tool quality is usually relatively high (developers “eat their own dog food”). Developers know what matters to other developers and they build the software they personally want to use.
When you aren’t the target user, however, it behooves you to learn enough from the actual users so that you can satisfy their needs. Even if you have to go out of your way to do so.
The Curse of Customization
It’s bad enough to use canned software that is designed for the needs of the buyer rather than for the day-to-day user. But the situation gets even more irksome when a software system is a framework or other tool that’s often customized, such as a customer relationship management system or a content management system.
I found myself engaged in three parallel conversations about the use of content management systems (CMSs) such as Drupal, WordPress, or Plone. Each little grouse-fest had a common theme: CMSs are unsatisfying. Or as one journalist asked, “Anyone here not sullied by contact with what he or she believes is The Worst CMS Ever?” Plenty of my tech journalist friends had their own rant about the anti-favorite, and the discussion inspired one friend to generate a long list of features that any reasonable CMS ought to have (but too few do).
However, one problem with the “worst CMS ever” question is that few CMSs are used out of the box. Most of us who actually manage content use a CMS that was customized at least a little bit, especially if it’s for more than just a personal blog. So what we end up evaluating is not the CMS itself but the customization – and I’ve seen a lot of lousy customizations, especially when the developer was never in touch with the user.
For instance, some years ago I was responsible for a publication’s community site that was built in Drupal. I try not to hold it against Drupal that the blogs were, not to put too fine a point on it, terrible (It put a page break in the middle of a sentence! What were they thinking?!). I am certain that if I had 10 minutes with the person who customized that instance of Drupal, that really stupid “feature” could easily be fixed.
But it’s a workflow issue, too, because – though I was the community manager and its primary user – I was never given the opportunity to talk with a developer. The blogging system was built by a programming-and-design team who met only with my boss and a committee of people who were more concerned about project management and budget compliance than about the admin features (I have to do what to add a new user?!). The blogging system was (virtually) dumped on my desk with a ker-thunk: Here’s your tool. Use it.
In a true Agile process this would not be much of a problem. I’d see the changes in the next iteration a few weeks later. Yet even though I was promised that “We are doing this as an Agile project, so don’t worry about the fact that the blog doesn’t do this on Day One,” the development team was never given a budget to continue past the launch date. It’s among the several sins created in the name of Agile, which James Turner (yes, of SQC’s cartoon team) wrote about in When Agile Projects Go Bad.
The end result, however, is that as an unhappy end-user, I easily could have decided that Drupal sucks, when in actuality my situation was, “The customization done for my instance of Drupal sucked, largely because the programmer never found out what the community manager needed.” I’m geeky enough to know the difference because I’m married to a committer on one open source CMS, but most of my writer friends are not. They concluded that the CMS was at fault. When the failure was in eliciting requirements from the actual users.
Getting the Right People in the Room
This is a sticky problem because it has nothing to do with your skill as a website designer, developer, or tester. You might be very good at asking me (as your user) what I want from the system you’re going to build, and at drawing from me all the details I wanted but “assumed” you already knew. (When done well, as was the case with the developer and designer who helped us build SoftwareQualityConnection.com, the editor shouts with joy.)
However, I’ve known too many developers who interview the wrong people.
If you’re an outside computer consultant or web designer, the problem is exacerbated because the primary “user” whom you need to serve is the one who signs the checks. The boss who hires you may have a very different perspective on how the application ought to work. If you as the developer listen only to the executive’s requirements, you might create software that does what was asked for but not what was needed.
Sometimes this happens because the boss is a bozo, but I think that’s relatively rare. In my experience it’s more likely that everyone in the food chain below that boss summarizes their needs for easy-boss-understanding (or their perception thereof), especially when the boss lacks detailed understanding of the way the user does his job. They lose all the important detail in a corporate game of “telephone.” The result is a watered-down specification that might have very little to do with what the software actually has to do. In the interests of creating a feature list, they make bullet points – when application designers need detail.
In these situations, requirements are over-generalized, so “I need to control the features available to each class of CMS user so that Managers can assign this kind of task to others with equal access rights” becomes “needs user management features.” If the programmer is given the latter requirement, the user might or might not get the control she needs. She’ll blame the programmer (and maybe the CMS), not the design process.
When you are given a programming gig (as an employee or a consultant) you tend to take the client at his word: “We need it to do this.” And you know, full well, that if the client or boss is satisfied it is good for your career, since happy clients pay on time (well, we like to think so) and happy bosses might promote you to team lead.
If all you look at is “What do I need to do to get the client to sign off?” it’s a waste of time to interview the hands-on users who’ll live with the software day-to-day, learning what they need and building the software to make them happy.
But that’s a trap. It’s the short-sighted way to do business. If you make the end users delighted with the software, they will sing its praises to the Powers That Be. The project will go smoother and complete faster since the application will do what’s needed, not just what’s asked-for; you won’t waste time on re-work when the client says, after the fact, that what you delivered wasn’t what they had in mind.
I beg you to adopt a different approach. Instead of just taking the executive team’s list of application requirements, please insist on talking to an end-user (our “person with her hands on the keyboard”).
I leave it to your diplomatic skill to position this Programmer’s Requirement in a way that demonstrates your attention to detail and your insistence on doing things right. Perhaps you can say that it’s part of your normal user testing process. Or you want feedback from the end-user to streamline the user interface. Or – well, I suspect you can leave suggestions in the comments here for the way to convince the people in the executive boardroom to permit you to interview the user. Please help us all out and share how you’ve managed to interview the hands-on-the-keyboard user… or the frustrations you’ve encountered when you failed.