Technically minded people are a funny lot, in the sense that they are usually very intelligent, have an urge to be helpful to others, love to solve problems, and yet with all these qualities they can often quite easily miss a very large part of the point about what it is they are doing. As I write this, it is the Software Developers in particular that I am thinking about.
Software is created to run on a computer, developed using tools that run on a computer, and the software works in a structured manner governed by the rules of the computer and by the other software that it interacts with. When viewed from this perspective it is easy to think that software is ultimately about solving problems with computers, and yet it seems that most often we forget that software has less to do with computers than it has to do with people.
Think about this for a moment. Software is created by people, and is ultimately designed to describe systems that reduce the workload for people by taking the burden of repetitive tasks and difficult calculations away from people. Sure, we are still using computers to run the software, but it is people who ask for the software to run, people who design the software, and people who present the problems that the software is designed to resolve. Viewed from this perspective, it is more reasonable to assume that software is really more about solving problems for people, and therefore less about computers and tools.
Let's expand on this idea further by looking at people's perception of software. Software is considered to be good when it does everything that a user could possibly ask for, and it does these things easily, intuitively, and efficiently... from the user's perspective. The user doesn't know or even care about how the software was developed. They don't care if your code is commented or if it has been well factored. All that the user sees is the interface that is presented, and the experience provided by the interface alone. While the software engineer worries about code-spaghetti and how agile the development process is, the user only cares about whether the software will meet all of the user's needs.
I've worked in many places with many more gifted individuals than I. I'm talking about very clever people who are very good at solving complex problems in code. I've often heard such people talking about user experience and fine tuning the user interfaces. In most cases however, the emphasis hasn't really been on the user as a person with a problem to solve, but more as the user being some diabolical entity with a mysterious ability to break even seemingly unbreakable software. The result is that interfaces are deliberately "dumbed-down" in order to make it harder for the user to do something wrong in the view of the software developer. There is largely an us-vs-them mentality that overshadows everything that we do. Even in the most Agile-minded development environments where you'll hear all about bringing the customer in on the development process, the individual users are treated as an almost afterthought, and then only in terms of simplifying interfaces to the least number of error prone steps. In some cases this can be a good thing, but it comes at the expense of the user's individual experiences with the software that we create.
So the question is, is it such a bad thing, that the user gets a simple no-brainer interface and can do the least harm? Or, should we be trying to build interfaces for the individual users and to give them a little more control over their experiences with our software? More importantly, what is it that makes each individual's experience with a software package enjoyable, and is there a way in which we can quantify the user experience in order to allow us to give each and every user a sense that the software that they are using is not only a pleasure to use, but that it is also the best and only software package that they would want to use to solve their particular problem set
I'll leave you thinking about those questions for a moment and look at the issue from a more familiar perspective, which is as it would be seen through the software engineer's eyes. Forget about all that user related stuff for now, and lets just concentrate on the coder's experience in terms of the creation of a software product. A coder's needs are reasonably simple, in that the coder likes to be challenged, have beautifully factored code, have relatively pain free debugging and maintenance processes, have the opportunity to work on new and exciting projects, and to solve complex problems that actually result in something useful to a large body of users. Give a coder all of this, and he'll be as happy as a pig sitting in 3 feet of warm mud on a hot sunny day. Things that tend to bring out the grumpier side of your average coder are long painful debugging processes, boring repetitive tasks, and APIs with difficult to use interfaces, poorly planned projects, and poorly defined specifications. Basically anything that results in any uncertainty that could lead to a failed project. You only have to look at the plethora of programming tools, languages, and methodologies, to understand just how important it is to your average coder to have an enjoyable experience when developing software for the end user. Interesting isn't it, that although the specific problem issues are different, it seems as if there are many similarities between coders and users in terms of their needs to deal with job-specific problems, avoid repetition, and to have an enjoyable experience in their day to day work. And again, is there a way to quantify the coder's experiences in order to better understand the specifics that lead to an improved and enjoyable overall programming experience?
While I don't have specific answers to any of the questions I have posed in this article, and while nearly everything I have written so far tends to result in yet more questions being raised, I do have a hypothesis that the answer to these questions fundamentally lies in understanding human psychology, and in particular the psychology as relates to individual perceptions of their own experiences when interacting with the software and the processes that each individual might use. In my way of thinking, a large amount of effort is expended in teaching junior programmers the basics of programming, and writing software as a process, but very little effort goes into teaching future software engineers about how people think, and how such knowledge might be employed to create better software.
I'm sure we all have many ideas about what it is that makes a good piece of software, but the reality is that interfaces for both users and coders tend to be the afterthought, and not the focus of everything that we do. It's not nearly enough to say that you've been able to capture all of the information that your users wanted, if you've created a UI minefield for them to wade through in order to get everything done. Even most of the better perceived software products will have something that could be done better from the user's perspective. As a quick and dirty example, look at the Microsoft Office products that had that Paperclip helper popping up automatically. Most people found it cute for 5 minutes, then terribly distracting and annoying for the most part. What about the many ways in which software products have "abused" the use of menus, tool-bars, and tabs over the years? Even more disturbing however, is how people will put up with something that they aren't really happy about, because the alternatives are worse, and then when an improvement comes along, these same people will complain because the interface is suddenly different, and the users can't seem to locate familiar functionality, as if they have become conditioned to software working only in a particular and familiar manner.
I believe that much of this really comes down to managing peoples perceptions, and allowing people time to adjust when change is imminent. Even more importantly perhaps, is not to simply allow a single voice to represent the collective will of your valuable customer base, but instead to allow each voice to be heard individually. Sure, you'll end up getting a lot of crackpot suggestions and needing to wade through some seriously dumb sounding commentary, but you'll also have a chance to learn more about the software that you write from the people in the trenches who are actually using your software to solve real problems, and you'll be able to learn from your mistakes more easily than if you simply had to guess from miserable sales figures why your software is perceived to "bad". Likewise, listening to your developers instead of simply relying on their team leaders and managers will also allow you to learn why your software might potentially be difficult and perhaps costly to change and maintain.
So software is essentially all about people. Building and maintaining relationships with people, understanding what it is that motivates people, and about what it is that gives the perception of what is good and bad about software. It's not about solving the tricky problems in a clever way, but about solving them in a user friendly and maintainable way. It's about improving the experiences of the users and developers alike. Happy developers will have efficient and enjoyable development processes that will be agile and designed to reduce maintenance overheads. Happy customers will have an efficient and enjoyable user experience with your software, and be inclined to freely support and market your product on your behalf, with an expectation for high quality and usability. Thus, changing the mindset so that people become the focus for everything that software is about should result in improved sales prospects and profit margins on the products that your company develops, and ultimately result in a better overall quality of software product being developed.
No comments:
Post a Comment