Friday, May 22, 2009
The user is always right?
Most of the forums and lists, both agile- and traditional-development related, have resident experts and contributors who have years of experience in their chosen area of software engineering. Questions are asked relative to a problem someone is having either technically or with a process. At some point in most discussions someone providing answers asks some variation of “what do the users want?” This is a reliable fall-back to any software development issue based on requirements. Ultimately, we are producing a solution to a business problem voiced by those users.
It got me to thinking about whether the user has or should have such absolute power over what we create and deploy.
Forty years ago there was no input from the users except to identify what they wanted on reports. Formatting was up to us as programmers, and input definitions (on punch cards) was also up to us. Users certainly didn’t specify how they’d like their punch cards to look.
When the users were introduced to monitors, they still didn’t have much to say about the appearance. It was green-gray scroll mode only. Ask a question, input an answer.
From the mid-70s on, or about the time we started doing prototyping on minicomputers and the like, the users held sway. Even though the interface didn’t appear logical to us, when the users said they wanted it a certain way, they got it. Of course, we didn’t have much in the way of user interface to play with: fixed input or display screens of black and white separated by menus. However, the final and ultimate word was always that of the user who would be staring at that screen day in and day out.
Nowadays, of course, it’s all different. The user, however, still appears to control the interface. This leads me to wonder whether the user experience analysts and experts, the information architects and the human factors analysts should control the interface instead.
Is there a line between a user’s power to dictate his/her own interface and the knowledge and skill that a specialist has to make the interface more efficient and the users of that interface more productive? Where is that line drawn?
Who draws the line when two (or more) users agitate for different interfaces to perform the same activity? It could be a simple color difference or a different way of viewing the flow of entry. Certainly code could be written to accommodate all users’ peccadilloes. Where then is the line between the extra code written and subsequent cost of maintenance to accommodate all the users? Does one user get preference over others? Majority wins? All users are created equal, just some users are more equal?
Finally, and it’s a shame to bring this up but that is the reality of business today, there is the misalignment of process and product. A user, in this case perhaps one with authority, specifies changes or a new feature that might benefit him or her personally, or perhaps his or her department, and it isn’t within the overall corporate strategy. Since upper level management does not always have checks and balances in place to coordinate tactical projects and strategic initiatives, who draws the line when the user’s request isn’t in line with corporate strategy or mission? I developed a slick system for a Vice President that did everything he wanted and more, and was delivered on time and under budget. Before we could even commence the celebratory party the VP was sacked and the system shelved because it didn’t fit in with the corporate strategy. We also built a neat system for a telecom company hitting all the early release dates and preparing for another five releases to improve the system based on user feedback, only to have the company sell off the entire system and division to another company, something that was in the works from before we started. We were then told the system wasn’t right because the purchaser didn’t like it.
So where is the line between finding out what the user wants and delivering something that may be better than what the user requested, and aligned with the corporate strategy? ¶ 6:53 AM
It got me to thinking about whether the user has or should have such absolute power over what we create and deploy.
Forty years ago there was no input from the users except to identify what they wanted on reports. Formatting was up to us as programmers, and input definitions (on punch cards) was also up to us. Users certainly didn’t specify how they’d like their punch cards to look.
When the users were introduced to monitors, they still didn’t have much to say about the appearance. It was green-gray scroll mode only. Ask a question, input an answer.
From the mid-70s on, or about the time we started doing prototyping on minicomputers and the like, the users held sway. Even though the interface didn’t appear logical to us, when the users said they wanted it a certain way, they got it. Of course, we didn’t have much in the way of user interface to play with: fixed input or display screens of black and white separated by menus. However, the final and ultimate word was always that of the user who would be staring at that screen day in and day out.
Nowadays, of course, it’s all different. The user, however, still appears to control the interface. This leads me to wonder whether the user experience analysts and experts, the information architects and the human factors analysts should control the interface instead.
Is there a line between a user’s power to dictate his/her own interface and the knowledge and skill that a specialist has to make the interface more efficient and the users of that interface more productive? Where is that line drawn?
Who draws the line when two (or more) users agitate for different interfaces to perform the same activity? It could be a simple color difference or a different way of viewing the flow of entry. Certainly code could be written to accommodate all users’ peccadilloes. Where then is the line between the extra code written and subsequent cost of maintenance to accommodate all the users? Does one user get preference over others? Majority wins? All users are created equal, just some users are more equal?
Finally, and it’s a shame to bring this up but that is the reality of business today, there is the misalignment of process and product. A user, in this case perhaps one with authority, specifies changes or a new feature that might benefit him or her personally, or perhaps his or her department, and it isn’t within the overall corporate strategy. Since upper level management does not always have checks and balances in place to coordinate tactical projects and strategic initiatives, who draws the line when the user’s request isn’t in line with corporate strategy or mission? I developed a slick system for a Vice President that did everything he wanted and more, and was delivered on time and under budget. Before we could even commence the celebratory party the VP was sacked and the system shelved because it didn’t fit in with the corporate strategy. We also built a neat system for a telecom company hitting all the early release dates and preparing for another five releases to improve the system based on user feedback, only to have the company sell off the entire system and division to another company, something that was in the works from before we started. We were then told the system wasn’t right because the purchaser didn’t like it.
So where is the line between finding out what the user wants and delivering something that may be better than what the user requested, and aligned with the corporate strategy? ¶ 6:53 AM
