It's All About People: Write Software for Real People, not a Market
|
DarkWyrm's Haiku Site It's All About People: Write Software for Real People, not a Market |
|
It seems that often times, the vast majority of computer users are referred to with contempt or disdain by those possessing a "superior" amount of computer literacy. I've often compared computer techs to automotive techs. Both have specialized knowledge which surpasses a large number of the general populace. Both devices being fixed seem mysterious to those not in the know. Somehow, though, along the way we seem to forget that car owners are not necessarily expected to have much knowledge about their vehicles, unlike computer users. Car owners are greeted with a 'Check Engine' indicator and users are expected to understand what exceptions, general protection faults, or segment violations are. Developers understand these, but the average user does not. In my last article, we looked at a way to design applications geared toward the type of user that they were intended. We shall now see who these applications are for.
By not leaving the application's design simply up to the programmer's concept of the application is crucial to designing a good interface because one could say that developers are a breed unto themselves. Developers as a group utilize a vast body of knowledge that they understand or have the capacity to learn quickly. They speak a lingo of their own, as well. Simply by education are they automatically set apart from the majority of the user community as "experts," whether or not this is true for each individual developer. Understanding the terminology in an application is rarely a problem for a programmer nor is learning seemingly arbitrary actions to perform a task - learning an API or a command-line interface such as UNIX. However, most people have difficulty with these very same things and are more concerned with thoughts like "The big guy wants that projected sales report on his desk in the morning" as opposed to "Now what was that switch that piped cvs checkouts to stdout? Hmmm.... where's that man page?" Programmers have a distinct tendency to design applications which other programmers - but not necessarily others - use well. In some cases, the only person who can easily use such an application is the person who wrote it.
The lifestyle of a developer often dictates that he spend copious amounts of time talking to other developers and wondering why management just doesn't understand. Management exists to ensure that whatever products and/or services provided by the company will make the most money possible. Developers exist to create those products and services. Results are important, not the implementation. Which word processor a status report is written with Productive, Word, or OpenOffice's Writer makes little, if any, difference as long as it is written. From the manager's perspective, accounting for the probable case is more important than every possible case. Most developers are the exact opposite. Conflict often exists because each group tends to understand its own and not attempt to understand the other.
Although it might seem somewhat strange to think of it in this manner, the computer industry is really a service industry. The products and services are bought by and ultimately for people. It is, thus, necessary to remain focused on who an application is meant for, such as developers, web page authors, graphic designers, etc. By recognizing and anticipating a person's strengths and weaknesses, it is possible to compensate for his weaknesses and make his strengths even stronger. In designing for only one or two people, the application is designed for a large number of users just like them. People is people.
When a company makes these decisions, it writes a couple fictional biographical profiles, often called 'personas.' These personas guide design to include the necessary functionality and display it in the proper way. The level of detail in each persona varies on the project and the design team. Often times a persona will include a name, age, personal interests, job title, relative level of computer literacy, and needs.
While the tendency of developers to write for developers is not a Bad Thing (TM), most often, we are targeting someone on the level of Joe User or Joe's Grandma. Joe User (sometimes condescendingly referred to as Joe Loser), is a stereotype for end-users which are not technically-oriented.
Since we're talking about Joe User, let's talk about him in a little more detail. Joe User works in a white-collar job and is not very technical. He probably is a teacher, parent, or a small business owner. Make no mistake, Joe is not a beginner, but he is no expert, either. He knows where the power button is, and knows that there is no 'Any' key. Normally, he can find the files he has created, but occasionally loses them in the file hierarchy and needs to ask one of his coworkers to help him find it. There are a lot of things about computers he just doesn't know much about, so he wants it to just work and let him get his work done and go home without unpaid overtime.
The above example is a rather general description of someone. While it could very well be used to guide design, it can only do so much because it is for a general context - no specific application. However, if we are to get some help from creating a persona, we need an application to which it is associated.
Let us start with a fictional documentation system for Haiku called Dox. Its goal is to provide the user with a powerful, yet relatively simple means to find content in text files of various sorts. One of its users is named Aaron. Aaron is a 43-year-old janitor who hasn't previously shown much interest in computers, but has had his curiosity piqued after his son gave him one of his older machines. The computer is a bit old, so it had BeOS installed on it to make best use of the hardware. Anyway, he finds it difficult to learn anything about it because he can't find any books on BeOS and doesn't really know where to start. His son told him that there are text files on the computer to help him, but Aaron can't find them himself. Most of the time, his son just makes a few icons on the desktop for him to click on for the programs he uses most.
Unfortunately, we can't let ourselves forget Dirk, a senior Business major in college. Dirk loves computers and uses them to organize his life. He dreams of opening a PC support business when he has the sufficient startup funds. Currently, he uses his computer mostly for term papers and such, playing around with something he downloaded recently called BeOS Max Edition. Because he has Internet access via the college's LAN, he downloads applications left and right. The only problem is that he is tired of having to remember where he put apps to look up help files and is intrigued by the Terminal application and how to use it. He finds it frustrating having to navigate through BeOS' HTML files in order to look up switches for grep, tar, and bzip.
The company wants to market Dox to people like Aaron and Dirk. By knowing who the application is for, it is clearer what will be needed for each gentleman in order to work than if someone said "Dox needs to be easy for the newbie and powerful for the power user." For those of us who code by themselves on a project, a little work like this may not seem very useful or interesting, but our projects are better for it nonetheless. It doesn't take much time, though. In fact, it took the author more time to type the two above personas than it did to brainstorm the details. Sometimes what is thought of as the Fast Way is not necessarily the Right Way - in this case, the right way is about remembering that programming is really all about the people the software serves.
_
_
|
What are You Looking At? |
_ |
_ |