by Igor Ješe, May 2007

http://mockupscreens.com/index.php?page=Secrets_of_Successful_Software_Requirements

Introduction

Although most companies do some form of requirements, there is often a lack of understanding as to exactly why the requirements need to be created and the level of detail that should be included in the requirements.

Software is always created to solve a need for a client. The client may be an internal client, an external client, or even the general public. Detailed requirements are important to ensure that a program correctly and fully addresses client’s needs.

Detailed requirements make initial development easier and faster because the developers know exactly what should be developed and do not need to make their best guess at the functionality to be implemented or delay development by creating requirements during development. Giving the developers accurate requirements will also result in less rework at the end of development because the stakeholder’s requirements will have been implemented correctly initially and will not be arrived at through trial and error.

A project manager can use the detailed requirements to create accurate timelines and give correct estimates to the client. This ensures that stakeholders are completely aware how long development will take so they can adjust the scope of a project or proactively add resources if necessary.

Finally, testers can use the requirements to create test plans while development is ongoing rather than waiting until development is complete. The requirements give them information about what the program will do so there cannot be disputes between developers and testers as to what the program functionality should be. High quality requirements also describe problem paths that may need additional testing.

Even though highly detailed requirements make development easier in future phases, this is not always possible due to time constraints imposed by the client or market conditions. With this in mind, let’s look at some secrets to improve your requirements process even under tight deadlines.

Secret #1 – Include Use Cases

Use cases look at the requirements from the standpoint of an end user working with the program and how the program responds to the user’s inputs. At its simplest level, a use case can be thought of as a play where the end user is one actor and the program is another actor. These two actors then have dialogs which explain the interactions between the actors. More complicated scenarios can have additional actors including other programs, other types of users, and even hardware. Use cases have proven to be very easy to read and understand even for non-technical clients.

Each use case explores what happens when something goes wrong in addition to the “normal” interactions. The exploration of these failure conditions is very important because these cases are the most difficult to code and can cause the most amount of testing. Traditional requirements often ignore these cases. It can be helpful to have developers and testers both think of additional possible failures in a use case so they can be fully documented in the requirements.

Use cases do not provide a complete picture of the system though. A technical specification should also be included in the requirements to detail formulas and routines that take place behind the scenes.

Secret #2 – Prototype Screens with a Design Tool

A user of the program only interacts with a program through the user interface so it makes sense to spend a significant amount of time during requirements to ensure that the user interface makes sense, that all functionality is included, and that the most commonly used functionality is easily accessible. The easiest way of doing this is using a screen prototype.

There are a variety of methods of making screen prototypes which range from simply drawing the interface with a pen and paper to building “working” prototypes in a higher level language like Visual Basic which allows rapid screen design. However, each of these extremes has serious drawbacks. A pen and paper prototype does not allow users to interact with the prototype and it is more difficult to change. A “working” prototype done in a programming language like Visual Basic can lead the client to believe that the program is nearly complete and that development should not take very long or it can lead the client to believe that changes to the prototype will be costly making them reluctant to make necessary suggestions to improve the program.

Between these two extremes lies screen design applications which allow you to draw the screens and model interactions between screens. High quality prototyping tools allow you to enter sample data and allow users to move between screens by pressing buttons so they can easily understand the interface and its functionality. Most prototyping tools produce the final output in an HTML format so they can be easily shared even if a client is not in the same office where requirements are being developed.

When looking for a prototyping tool, make sure to select a tool which is easy enough to use that you can easily prototype screens while your customer is in the room. This will allow you to brainstorm and make changes to the screens without delays. A prototyping tool should already have common controls already defined to maintain design standards and improve the appearance of your screens. Being able to enter sample data in each screen can allow the customer to pinpoint areas that may be incorrect.

Secret #3 – Work Directly with End Users

When designing a new application or making revisions to an existing application, there is no substitute for the direct experience that end users have. An end user can give immediate feedback on your design to point out awkward or incorrect functionality. They also help to ensure that all controls are logically placed for the most efficient use of the system.

Using an interactive prototyping tool allows you to walk a user through the interface or even allow them to work directly with the prototype so they can quickly suggest improvements. As use cases are being developed, it is a good idea to walk users through the use case to ensure that the use case is well thought out and that all functionality is captured both in the use case and the prototype.

Secret #4 – Do Iterative Requirements Development

When you create requirements, it is important to develop the requirements in multiple stages. For example, you may want to do a general layout of the program and create higher level use cases in the first session to get a feel for the overall requirements. In the next session(s), you can focus on each key feature to ensure that the normal paths are all defined in the use cases and further refine the prototypes. In the next session(s), you can attempt to define all of the error conditions which can occur and update the prototypes as necessary. The final sessions should review all work previously done to ensure that all requirements are clear and complete. At each stage, you should not be afraid to revise work done in a previous step because getting the requirements correct will ultimately save time in the more costly development and testing stages.

Secret #5 – Place Requirements Documents under Change Control

With all of the time spent on generating clear requirements, it is very important to make sure that all of the requirements documents are included in your change control system. This includes use cases, screen prototypes, technical specifications, and any other documents used to define the requirements.

Conclusion

In this article, we have explored various secrets to make your requirements process successful and ensure that your clients are satisfied with the resulting program even under tight deadlines. At the start of your next project, make sure you have the proper tools in place for a successful requirements iterations including a prototyping program, a tool to write use cases, and a version control program. These tools do not have to be expensive, and they will help to get your requirements right and schedule under control.

BẢY BƯỚC ĐẾN THÀNH CÔNG

Nhìn nền trời thăm thẳm, lấp lánh sao vàng, người phương Tây tò mò muốn biết trên những vì tinh tú đó có gì và tìm cách chinh phục không trung để đến tận nơi quan sát thế giới huyền bí, xa xăm đó; còn người phương Đông ta chỉ nghĩ tới sự bé nhỏ của thân mình, sự yếu ớt của sức mình và cảnh phù du của đời mình. Họ chinh phục Thiên nhiên thì ta khuất phục Thiên nhiên. Mọi việc từ việc nước, việc nhà, tới việc ăn, việc uống, ta đã đều cho đã có Hoá công sắp đặt trước, gắng sức chẳng những đã vô ích mà còn trái đạo Trời nữa. Họ phấn đấu, tiến thủ, còn ta uỷ mị, an phận.

Nhiều khi chúng ta cũng phải nhận rằng có số phận thật. Có những việc xảy ra trong đời mà ta chưa thể giảng được và cho là tại số. Khoa học sau này có giảng được không, chưa biết. Nhưng ta biết chắc một điều là phần động chúng ta đều không rõ trước được số ta sẽ ra sao hết. Vì chính khoa tướng số cũng nhận rằng Số không phải là cái gì chắc chắn như hai với hai là bốn, rằng Số vẫn có thể dùng sức người mà sửa được. Điều đó, may cho chúng ta vì nếu biết chắc đời ta Trời bắt sao phải chịu vậy thì kiếp trần này còn có chi đáng sống không? Còn việc chi đáng làm không?

Vậy số mạng, cái bí mật của Hoá công chưa hiểu được ấy, cũng chỉ như một luồng nước. Ta không biết chắc nó sẽ qua đông hay qua tây, và nếu muốn, ta vẫn có thể chống với nó. Thế thì thái độ của ta nên ra sao? Nên như cánh bèo chơi vơi trên dòng, mặc cho gió táp sóng dồi, may mà tới được một bến có hoa có lá thì càng hay, chẳng may trôi ra biển cả, chìm xuống vực sâu thì cũng đành ư? Hay như con cá tìm nơi nước trong sóng lặng mà tới, vẫy vùng giữ dòng; nước xuôi thì mau đến mà nước có ngược cũng không bị lôi cuốn vào nơi vô định?

Huống hồ phương Tây có câu: “Bạn hãy tự giúp mình đi rồi Trời sẽ giúp bạn”, mà phương Đông cũng có câu: “Khuynh giả, phúc chi, tài giả, bồi chi”[1]. Ta chẳng thấy những người đang cơn bĩ, một hôm suy nghĩ phấn khởi lên, đầy lòng tự tin rồi như có thần linh mách bảo, có sức vô hình đưa đẩy, tâm hồn thay đổi hẳn, hoá ra quả quyết vui vẻ hoạt bát hơn, được lòng nhiều người hơn, thông minh hơn và đi từ thành công này đến thành công khác đấy ư? Đó chẳng phải tự mình giúp mình rồi Trời giúp ư?

Cũng có khi họ thất bại một vài lần đầu, nhưng nếu họ kiên nhẫn thì trước sau gì họ cũng đạt được mục đích vì vận may không phải chỉ tới một lần trong đời người mà tới nhiều lần. Ta phải dự bị sẵn sàng rồi đợi, đừng để nó gõ cửa ta trong khi ta mê ngủ rồi than rằng nó không tới. Tóm lại, ta phải tự tạo lấy vận may.

Thấy phần đông người mình thiếu tinh thần phấn đấu của phương Tây, sống lây lất, nhắm mắt đưa chân, tới đâu thì tới, cho nên chúng tôi dịch tác phẩm “Give yourself a chance” của Gordon Byron để giới thiệu với các bạn một phương pháp tu thân luyện tính, một phương pháp tổ chức cuộc đời của người Âu[2].

Gordon Byron là một người Anh. Ông đã thành công rực rỡ trong nhiều ngành hoạt động, hồi nhỏ ông đầu quân rồi lên tới chức đại uý trong đội Pháo binh của Anh Hoàng. Sau ông bắt đầu học nghề bán hàng và trở nên một viên chỉ huy trong công ty ông giúp việc. Ông lại làm cho một công ty quảng cáo và lên tới địa vị giám đốc. Ông chưa từng thất bại. Trong công việc trứ tác cũng vậy, ông viết trên 12 cuốn có ích, mà cuốn có danh nhất là cuốn “Give yourself a chance” xuất bản đầu năm 1946.

Đọc cuốn ấy, độc giả sẽ được ông cầm tay dắt lần lần lên bảy bực thang để đến cửa đền của thành công.

Bảy bước đó là:

1. Luyện lòng tin và rèn nghị lực.
2. Luyện nhân cách.
3. Đắc nhân tâm.
4. Luyện tập và giữ gìn thân thể.
5. Khéo léo dùng tiếng mẹ đẻ.
6. Luyện trí.
7. Kiếm việc làm và dự bị để được thăng cấp.

Toàn là những điều thực hành ngay được. Còn về kết quả thì trong sách tác giả đã đưa ra nhiều thí dụ có thật để chứng minh hiệu quả của phương pháp, nhưng chúng tôi tưởng chỉ có một quá khứ thành công của ông trong bốn ngành hoạt động khác nhau cũng đủ chứng thực nhiều rồi.

Tôi biết có bạn sẽ nói: “Bảy bước thang đó có vẻ khó leo quá! Phải có nghị này, phải luyện tánh, luyện trí này…”. Cũng hơi khó thật. Nếu dễ thì ai chẳng thành công và cuốn này không cần phải viết nữa. Nhưng chúng ta thử nghĩ kỹ xem quả có khó lắm không? Để giật được bằng Tú tài hay Cử nhân – chưa xét tới những bằng cấp cao hơn – chúng ta mất bao công khó nhọc? Học luôn trong 10, 15 năm, học ngày học đêm thì chúng ta đủ nghị lực theo đuổi tới cùng mà luyện tinh thần, thân thể, tính tình mỗi ngày một giờ trong năm ba năm thì sao lại không đủ nghị lực? Mà sự thành công trong việc làm ăn của ta so với sự thành công ở nhà trường bên nào quan trọng? Tạo sao ra khỏi trường lại không chịu học nữa? Tại sao? Nền giáo dục hồi xưa trọng đức dục hơn trí dục. Nay thì trái lại. Cả hai đều thiên lệch hết. Tôi tin rằng sau này thế nào nhân loại cũng phải dung hoà cả hai, những cuốn sách như cuốn này sẽ được dùng làm sách giáo khoa trong ban Trung học[3]. Ở trường, chúng ta đã chưa được học, thì ra đời, lại càng phải học. Mà có mất công gì đâu? Mỗi ngày chỉ cần một giờ thôi!

Sách có ích cho mọi hạng người. Ta đang gặp cảnh gió xuôi ư, thì sách sẽ là cánh buồm căng thẳng đẩy thuyền ta mau tới bến. Ta đương lung tung trong cảnh gió ngược ư, sách sẽ lấy cây sào chống đỡ thuyền ta cho khỏi thụt lùi, khỏi đâm vào mõm đá, để tiến lên – dù rất chậm chạp – và đợi lúc gió đổi chiều. Vì gió sẽ phải đổi chiều. Ta phải luôn luôn dự bị sẵn sàng để đón gió.

Vậy chúng tôi xin Độc giả đọc kỹ cuốn này. Nếu bạn có chút nghị lực thì nó sẽ đánh dấu một khúc quẹo trong đời của bạn và biết đâu chừng, nó chẳng mang lại cho bạn một ngọn gió mới để đưa bạn đến bến mà bạn hàng mong tưởng!

Sau cùng, còn một điều nữa, xin thưa trước với các bạn. Khi chúng tôi cho ra cuốn Đắc nhân tâm, chúng tôi được nhiều bạn xa gần khuyến khích và khuyên nên tóm tắt lại, nhưng vẫn giữ đủ ý của tác giả, để giá sách bớt cao, nhiều người mua được. Vì vậy cuốn này đáng lẽ dịch hết (sách dày trên 300 trang), chúng tôi thu lại còn khoảng 150 trang, và trong một vài đoạn, muốn cho được rõ ràng hơn chúng tôi đã sắp đặt lại ý của tác giả. Nhưng chúng tôi vẫn giữ đủ ý chính trong sách. Riêng về chương V, tác giả chỉ cách dùng tiếng Anh cho khéo, vì tác giả là người Anh, chúng tôi theo đúng đại ý mà áp dụng vào tiếng Việt. Ngoài ra, chúng tôi không dám thay đổi chút gì hết.

————
[1] Ông Khổng nói rằng: “Tài giả bồi chi, khuynh giả phúc chi” nghĩa là mình tốt thì trời đất giúp thêm cho, mà mình đã nghiêng đổ thì trời đất lại xô đạp thêm. (Phan Chu Trinh, Đạo đức và Luân lý Đông Tây, http://www.icevn.org/vi/DucDuc/Dao-D…an-Ly-Dong-Tay. (Goldfish).

[2] Cuốn này là cuốn thứ ba trong loại “Tổ chức” của chúng tôi. Trong hai cuốn trước chúng tôi đã chỉ cách “Tổ chức công việc theo khoa học”, và tổ chức việc học (tức cuốn Kim chỉ nam của học sinh). Cuốn thứ tư là cuốn Tổ chức gia đình và cuốn thứ năm nhan đề là Tổ chức công việc làm ăn.

[3] Trong cuốn “Tổ chức công việc theo khoa học”, chúng tôi lấy làm ngạc nhiên sao một môn quan trọng như vậy mà chưa được day trong các trường Đại học. Chúng tôi mới hay rằng ngày 20-8-1947 cả Quốc hội Pháp đã đồng lòng thoả thuận phải dạy môn đó trong các chương trình Đại học, và lần lần sẽ dạy trong các trường Trung học và Tiểu học nữa. Nền giáo dục hiện thời của chúng ta còn phải sửa đổi nhiều.

http://www.briantracy.com/blog/personal-success/seven-steps-to-success/

Seven Steps to Success (from Brian Tracy, author of “Change your thinking change your life” and “Getting rich your own way”)
There is a powerful seven step formula that you can use to set and achieve your goals for the rest of your life. Every single successful person uses this formula or some variation of this formula to achieve vastly more than the average person. And so can you. Here it is:

1. Decide What You Want
Step number one, decide exactly what it is you want in each part of your life. Become a “meaningful specific” rather than a “wandering generality.”

2. Write it Down
Second, write it down, clearly and in detail. Always think on paper. A goal that is not in writing is not a goal at all. It is merely a wish and it has no energy behind it.

3. Set a Deadline
Third, set a deadline for your goal. A deadline acts as a “forcing system” in your subconscious mind. It motivates you to do the things necessary to make your goal come true. If it is a big enough goal, set sub-deadlines as well. Don’t leave this to chance.

4. Make a List
Fourth, make a list of everything that you can think of that you are going to have to do to achieve your goal. When you think of new tasks and activities, write them on your list until your list is complete.

5. Organize Your List
Fifth, organize your list into a plan. Decide what you will have to do first and what you will have to do second. Decide what is more important and what is less important. And then write out your plan on paper, the same way you would develop a blueprint to build your dream house.

6. Take Action
The sixth step is for you to take action on your plan. Do something. Do anything. But get busy. Get going.

7. Do Something Every Day
Do something every single day that moves you in the direction of your most important goal at the moment. Develop the discipline of doing something 365 days each year that is moving you forward. You will be absolutely astonished at how much you accomplish when you utilize this formula in your life every single day.

Action Exercises
Here are two things you can do to put these ideas into action immediately.

First, decide exactly what you want, write it down with a deadline, make a plan and take action – on at least one goal – today!

Second, determine the price you will have to pay to achieve this goal and then get busy paying that price – whatever it is.

All good websites come from a good plan. Sounds redundant, but it’s true. If you want to create a good and solid website, you need a good and solid plan. I know it’s hard to do, and I know you want to keep poking and playing with this exciting program, but it is time to take a break away from your computer and turn to the old paper and pen. That’s right, we’re going back in time to when people actually wrote things down.

On a piece of notebook paper, or whatever is lying around, describe your site. Take five to twenty minutes to come up with a purpose for your site, or better yet, call it your Mission Statement.

Answer the following questions:

1. What am I going to do with this?
2. Who is going to read this?
3. What kinds of information will I be posting?
4. Why am I doing this?
5. Who am I doing this for?
6. How often am I going to be posting and adding information?

Now, compile this information into a paragraph so it looks like this:

This website will be dedicated to X, Y, and Z,

and cover the topics of A, B, and C. The audience will
be __________ ________________ _______. I will be adding
posts every _____________ about ________ _______ ______________.

I am doing this because _____________ _____________ __________________.

http://www.joelonsoftware.com/articles/fog0000000067.html

In 1992, James Gleick was having a lot of problems with buggy software. A new version of Microsoft Word for Windows had come out, which Gleick, a science writer, considered to be awful. He wrote a lengthy article in the Sunday New York Times Magazine which could only be described as a flame, skewering the Word team for being unresponsive to the requests of customers, and delivering an enormously buggy product.

Later, as a customer of a local Internet provider Panix (which also happens to be my Internet provider), he wanted a way to automatically sort and filter his mail. The UNIX tool for doing this is called procmail, which is really arcane and has the kind of interface that even the most hardcore UNIX groupies will admit is obscure.

Anyway, Mr. Gleick inadvertently made some kind of innocent typo in procmail which deleted all his email. In a rage, he decided that he was going to create his own Internet access company. Hiring Uday Ivatury, a programmer, he created Pipeline, which was really quite a bit ahead of its time: it was the first commercial provider of Internet access with any kind of graphical interface.

Now, Pipeline had its problems, of course. The very first version didn’t use any kind of error correction protocol, so it had a tendency to garble things up or crash. Like all software, it had bugs. I applied for a job at Pipeline in 1993. During the interview, I asked Mr. Gleick about the article he wrote. “Now that you’re on the other side of the fence,” I asked, “do you have a bit more of an appreciation for the difficultly of creating good software?”

Gleick was unrepentant. He denied that Pipeline had any bugs. He denied that it was anything as bad as Word. He told me: “one day, Joel, you too will come to hate Microsoft.” I was a little bit shocked that his year of experience as a software creator, not merely a software user, hadn’t given him a smidgen of appreciation for how hard it is to really get bug-free, easy to use software. So I fled, turning down the job offer.  (Pipeline was bought out, by PSI, the strangest Internet provider on earth, and then unceremoniously taken out and shot.)

Software has bugs. CPUs are outrageously finicky. They absolutely refuse to deal with things that they weren’t taught to deal with explicitly, and they tend to refuse in the most childish of ways. When my laptop is away from home, it tends to crash a lot because it can’t find the network printer it’s used to finding. What a baby. It probably comes down to a single line of code somewhere with a teensy tiny almost insignificant bug in it.

Which is why you positively, absolutely, need to have a QA department. You are going to need 1 tester for every 2 programmers (more if your software needs to work under a lot of complicated configurations or operating systems). Each programmer should work closely with a single tester, throwing them private builds as often as necessary.

The QA department should be independent and powerful, it must not report to the development team, in fact, the head of QA should have veto power over releasing any software that doesn’t meet muster.

My first real software job was at Microsoft; a company that is not exactly famous for its high quality code, but which does nonetheless hire a large number of software testers. So I had sort of assumed that every software operation had testers.

Many do. But a surprising number do not have testers. In fact, a lot of software teams don’t even believe in testing.

You would think that after all the Quality mania of the 80s, with all kinds of meaningless international “quality” certifications like ISO-9000 and buzzwords like “six-sigma”, managers today would understand that having high quality products makes good business sense. In fact, they do. Most have managed to get this through their heads. But they still come up with lots of reasons not to have software testers, all of which are wrong.

I hope I can explain to you why these ideas are wrong. If you’re in a hurry, skip the rest of this article, and go out and hire one full-time tester for every two full-time programmers on your team.

Here are the most common boo-hoo excuses I’ve heard for not hiring testers:

1. Bugs come from lazy programmers.

“If we hire testers”, this fantasy goes, “the programmers will get sloppy and write buggy code. By avoiding testers, we can force the programmers to write correct code in the first place.”

Sheesh. If you think that, you either have never written code, or you are remarkably dishonest about what writing code is like. Bugs, by definition, leak out because programmers did not see the bug in their own code. A lot of times it just takes a second set of eyes to see a bug.

When I was writing code at Juno, I tended to exercise my code the same way every time … I used my own habits, relying on the mouse a lot. Our marvelous, vastly overqualified tester had slightly different habits: she did more things with the keyboard (and actually rigorously tested the interface using every possible combination of inputs). This quickly uncovered a whole slew of bugs. In fact at times she actually told me that the interface flatly didn’t work, 100% did not work, even though it always worked for me. When I watched her repro the bug I had one of those whack-your-forehead moments. Alt! You’re holding down the Alt Key! Why didn’t I test that?

2. My software is on the web. I can fix bugs in a second.

Bwa ha ha ha ha! OK, it’s true, web distribution lets you distribute bug fixes much faster than the old days of packaged software. But don’t underestimate the cost of fixing a bug, even on a web site, after the project has already frozen. For one thing, you may introduce even more bugs when you fix the first one. But a worse problem is that if you look around at the process you have in place for rolling out new versions, you’ll realize that it may be quite an expensive proposition to roll out fixes on the web. Besides the bad impression you will make, which leads to:

3. My customers will test the software for me.

Ah, the dreaded “Netscape Defense”. This poor company did an almost supernatural amount of damage to its reputation through their “testing” methodology:

1. when the programmers are about halfway done, release the software on the web without any testing.
2. when the programmers say they are done, release the software on the web without any testing.
3. repeat six or seven times.
4. call one of those versions the “final version”
5. release .01, .02, .03 versions every time an embarrassing bug is mentioned on c|net.

This company pioneered the idea of “wide betas”. Literally millions of people would download these unfinished, buggy releases. In the first few years, almost everybody using Netscape was using some kind of pre-release or beta version. As a result, most people think that Netscape software is really buggy. Even if the final release was usually reasonably unbuggy, Netscape had so doggone many people using buggy versions that the average impression that most people have of the software was pretty poor.

Besides, the whole point of letting “your customers” do the testing is that they find the bugs, and you fix them. Unfortunately, neither Netscape, nor any other company on earth, has the manpower to sift through bug reports from 2,000,000 customers and decide what’s really important. When I reported bugs in Netscape 2.0, the bug reporting website repeatedly crashed and simply did not let me report a bug (which, of course, would have gone into a black hole anyway). But Netscape doesn’t learn. Testers of the current “preview” version, 6.0, have complained in newsgroups that the bug reporting website still just doesn’t allow submissions. Years later! Same problem!

Of those zillions of bug reports, I would bet that almost all of them were about the same set of 5 or 10 really obvious bugs, anyway. Buried in that haystack will be one or two interesting, difficult-to-find bugs that somebody has gone to the trouble of submitting, but nobody is looking at all these reports anyway, so it is lost.

The worst thing about this form of testing is the remarkably bad impression you will make of your company. When Userland released the first Windows version of their flagship Frontier product, I downloaded it and started working through the tutorial. Unfortunately, Frontier crashed several times. I was literally following the instructions exactly as they were printed in the tutorial, and I just could not get more than 2 minutes into the program. I felt like nobody at Userland had even done the minimum amount of testing, making sure that the tutorial works. The low perceived quality of the product turned me off of Frontier for an awfully long time.

4. Anybody qualified to be a good tester doesn’t want to work as a tester.

This one is painful. It’s very hard to hire good testers.

With testers, like programmers, the best ones are an order of magnitude better than the average ones. At Juno, we had one tester, Jill McFarlane, who found three times as many bugs as all four other testers, combined. I’m not exaggerating, I actually measured this. She was more than twelve times more productive than the average tester. When she quit, I sent an email to the CEO saying “I’d rather have Jill on Mondays and Tuesdays than the rest of the QA team put together”.

Unfortunately, most people who are that smart will tend to get bored with day-to-day testing, so the best testers tend to last for about 3 or 4 months and then move on.

The only thing to do about this problem is to recognize that it exists, and deal with it. Here are some suggestions:

• Use testing as a career move up from technical support. Tedious as testing may be, it sure beats dealing with irate users on the phone, and this may be a way to eliminate some of the churn from the technical support side.
• Allow testers to develop their careers by taking programming classes, and encourage the smarter ones to develop automated test suites using programming tools and scripting languages. This is a heck of a lot more interesting than testing the same dialog again and again and again.
• Recognize that you will have a lot of turnover among your top testers. Hire aggressively to keep a steady inflow of people. Don’t stop hiring just because you temporarily have a full manifest, ’cause da golden age ain’t gonna last.
• Look for “nontraditional” workers: smart teenagers, college kids, and retirees, working part time. You could create a stunningly good testing department with two or three top notch full timers and an army of kids from Bronx Science (a top-ranked high school in New York) working summers in exchange for college money.
• Hire temps. If you hire about 10 temps to come in and bang on your software for a few days, you’ll find a tremendous number of bugs. Two or three of those temps are likely to have good testing skills, in which case it’s worth buying out their contracts to get them full time. Recognize in advance that some of the temps are likely to be worthless as testers; send them home and move on. That’s what temp agencies are for.

Here’s one way not to deal with it:

• Don’t even think of trying to tell college CS graduates that they can come work for you, but “everyone has to do a stint in QA for a while before moving on to code”. I’ve seen a lot of this. Programmers do not make good testers, and you’ll lose a good programmer, who is a lot harder to replace.

And finally. The number one stupid reason people don’t hire testers:

5. I can’t afford testers!

This is the stupidest, and it’s the easiest to debunk.

No matter how hard it is to find testers, they are still cheaper than programmers. A lot cheaper.  And if you don’t hire testers, you’re going to have programmers doing testing. And if you think it’s bad when you have testers churning out, just wait till you see how expensive it is to replace that star programmer, at $100,000 a year, who got sick of being told to “spend a few weeks on testing before we release” and moved on to a more professional company. You could hire three testers for a year just to cover the recruiter’s fee on the replacement programmer.

Skimping on testers is such an outrageous false economy that I’m simply blown away that more people don’t recognize it.

http://www.joelonsoftware.com/uibook/chapters/fog0000000065.html

We’ve talked about the principles of good design, but principles only give you a way to evaluate and improve an existing design. But… how do you figure out what the dang design should be in the first place? Many people write big, functional outlines of all the features they thought up. Then they design each one, and hang it off of a menu item (or web page). When they’re done, the program (or web site) has all the functionality they wanted, but it doesn’t flow right. People sit down and they don’t know what it does, and they don’t know how to accomplish what they want.

Microsoft’s solution to this is something called Activity Based Planning. (As far as I can tell, this concept was invented by Mike Conte on the Excel team, who got bored with that and went on to a second career as a race car driver). The key insight is to figure out the activity that the user is doing, and focus on making it easy to accomplish that activity. This is best illustrated with an example.

You’ve decided to make a web site that lets people create greeting cards. Using a somewhat naïve approach, you might come up with a list of features like this:

1. Add text to card 2. Add picture to card 3. Get predesigned card from library 4. Send card: a. Using email b. By printing it out

For lack of any better way of thinking about the problem, this might lead itself to a typical Macintosh user interface, circa-1984: a program that starts out with a blank card, with menu items for adding text, pictures, loading cards from a library, and sending cards. And then what the user is going to have to do is sit down and browse through the menus, trying to figure out all the commands available, and then do their own synthesis of how to put these atomic commands together to create a card.

Now, activity based planning says that you need to come up with a list of activities that users might do. So, you talk to your potential users, and you come up with this “top three” list:

1. Birthday Greeting
2. Party Invitation
3. Anniversary Greeting

Now, instead of thinking about your program like a programmer (in terms of what features you need to have to make a card), you’re thinking about it like the user, in terms of, what activities is the user doing, specifically:

1. Sending a birthday card
2. Planning a party, and inviting people to it
3. Sending an anniversary card

Suddenly, all kinds of ideas will rush into your head. Instead of starting with a blank card, you might start with a menu like this:

What do you want to do? Send a birthday card Send an anniversary card Send a party invitation Start with a blank card

Suddenly users will find it much easier to get started with your program, without browsing around on the menus, since the program will virtually lead them through the steps to complete the activity. (There is a risk that if you didn’t pick the activities correctly, you will alienate or confuse users who might have been able to use your program, say, to send a Hanukah card, but don’t see that as a choice. So be careful in picking activities that blanket the majority of the market you want to target.)

Just looking at our list of three activities suggests some great features which you might want to add. For example, if you’re sending a birthday or anniversary card, you might want to be reminded next year to send a card to the same person… so you might add a checkbox that says “remind me next year”. And a party invitation needs a way to RSVP, so you might add a feature that lets you collect RSVPs from people electronically. Both of these feature ideas almost fell out of looking at the activity that users were performing instead of the features in the application.

This example is trivial; for any serious application, the rewards of activity based planning are even greater. When you’re designing a program from scratch, you already have a vision of what activities your users are going to be doing. Figuring out this vision is not hard at all, it takes almost no effort at all to do some brainstorming with coworkers, write down a list of potential activities, and then decide which ones you want to focus on. But forcing yourself to list these activities on paper will help your overall design enormously.

Activity based planning is even more important when you are working on version two of a product that people are already using. Here, it may be a matter of observing a sample of customers to see what they are using your program for.

In the days of Excel 1.0 through 4.0, most people at Microsoft thought that the most common user activity was doing financial what-if scenarios, where you do things like change the inflation rate and see how this affects your profitability.

When we were designing Excel 5.0, the first major release to use serious activity-based planning, we only had to watch about five customers using the product before we realized that an enormous number of people just use Excel to keep lists. They are not entering any formulas or doing any calculation at all! We hadn’t even considered this before. Keeping lists turned out to be far more popular than any other activity with Excel. And this led us to invent a whole slew of features that make it easier to keep lists: easier sorting, automatic data entry, the AutoFilter feature which helps you see a slice of your list, and multi-user features which let several people work on the same list at the same time while Excel automatically reconciles everything.

While Excel 5 was being designed, Lotus had shipped a “new paradigm” spreadsheet called Improv. According to the press releases, Improv was a whole new generation of spreadsheet, which was going to blow away everything that existed before it. For various strange reasons, Improv was first available on the NeXT, which certainly didn’t help its sales, but a lot of smart people believed that Improv would be to NeXT as VisiCalc was to the Apple II: it would be the killer app that made people go out and buy all new hardware just to run one program.

Of course, Improv is now a footnote in history. Search for it on the web, and the only links you’ll find are from very over-organized storeroom managers who have, for some reason, made a web site with an inventory of all the stuff they have collecting dust.

Why? Because in Improv, it was almost impossible to just make lists. The Improv designers thought that people were using spreadsheets to create complicated multi-dimensional financial models. Turns out, if they asked people, they would discover that making lists was so much more common than multi-dimensional financial models, and in Improv, making lists was a downright chore, if not impossible.

So activity based planning is helpful in the initial version of your application, where you have to make guesses about what people want to do, but it’s even more helpful when you’re planning the upgrade, because you understand what your customers are doing.

Another example, from the web, is the evolution of deja.com, which started out as an huge, searchable index of Usenet called dejanews. The original interface basically had an edit box and said “search Usenet for blah,” and that was it. In 1999 a bit of activity based planning showed that one common user activity was doing research on a product or service, of the “which car should I buy” nature. Deja was completely reorganized, and today, it is more of a product opinion research service: the Usenet searching ability is almost completely hidden. This annoyed the small number of users who were using the site to search for whether their Matrox video card worked with Redhat Linux 5.1, but it delighted the much larger population of users who just wanted to buy the best digital camera.

The other great thing about activity based planning is that it lets you make a list of what features not to do. When you create any kind of software, the reality is that you will come up with three times as many features as you have time to do. And one of the best ways to decide which features get done, and which features get left out, is to evaluate which features support the most important user activities.

Imaginary Users.

The very best UI designers in the industry all agree on one thing: you have to invent and describe some imaginary users before you can design your UI. You may remember back in the introduction to this book, I introduced an imaginary user Pete:

Pete is an accountant for a technical publisher who has used Windows for six years at the office and a bit at home. He is fairly competent and technical. He installs his own software; he reads PC Magazine, and he has even programmed some simple Word macros to help the secretaries in his office send invoices. He’s getting a cable modem at home. Pete has never used a Macintosh. “They’re too expensive,” he’ll tell you. “You can get a 700 Mhz PC with 128 Meg RAM for the price of…” OK, Pete. We get it.

When you read this, you can almost imagine a user. I could also have invented quite another type of user:

Patricia is an English professor who has written several well-received books of poetry. She has been using computers for word processing since 1980, although the only two programs she ever used are Nota Bene (an ancient academic word processor) and Microsoft Word. She doesn’t want to spend time learning the theory of how the computer works, and she tends to store all her documents in whatever directory they would go in if you didn’t know about directories.

Obviously, designing software for Pete is quite different from designing software for Patricia, who in turn is quite different from Mike, a 16 year old who runs Linux at home, talks on IRC for hours, and uses no “Micro$oft” software.

When you invent these users, thinking about whether your design is appropriate becomes much easier. For example, a lot of programmers tend to overestimate the ability of the typical user to figure things out. Whenever I write something about command line interfaces being hard to use, I get the inevitable email barrage saying that command line interfaces are ultra-powerful because you can do things like ‘gunzip foo.tar.gz | tar xvf -’. But as soon as you have to think about getting Patricia to type “gunzip…” it becomes obvious that that kind of interface just isn’t going to serve her needs, ever. Thinking about a “real” person gives you the empathy you need to make a feature that serves that person’s need. (Of course, if you’re making Linux backup software for advanced sysadmins, you need to invent a character like “Frank” who refuses to touch Windows, which he only refers to as an “operating system” in quotation marks, uses his own personally modified version of tcsh, and runs X11 with four tiled xterms all day long. And about 11 xperfs.)

To summarize, designing good software takes about six steps:

1. Invent some users
2. Figure out the important activities
3. Figure out the user model — how the user will expect to accomplish those activities
4. Sketch out the first draft of the design
5. Iterate over your design again and again, making it easier and easier until it’s well within the capabilities of your imaginary users
6. Watch real humans trying to use your software. Note the areas where people have trouble, which probably demonstrate areas where the program model isn’t matching the user model.

Good UI sells software, but it also makes people happy, because people are happy when they accomplish the task they wanted to accomplish. Which is why UI design is such a satisfying field to be in. Where else are you going to get a chance to make millions of people just a little bit happier?

http://www.joelonsoftware.com/uibook/chapters/fog0000000064.html

One of the early principles of GUI interfaces was that you shouldn’t ask people to remember things that the computer could remember. The classic example is the Open File dialog box, which shows people a list of files rather than asking them to recall and type the exact file name. People remember things a lot better when they are given some clues, and they’d always rather choose something from a list than have to recall it from memory.

Another example is the menus themselves. Historically, providing a complete menu of available commands replaced the old command-line interfaces, where you had to memorize the commands you wanted to use. And this is, fundamentally, the reason why command line interfaces are just not better than GUI interfaces, no matter what your UNIX friends tell you. Using a command line interface is like having to learn Korean to order food in a Seoul branch of McDonalds. Using a menu based interface is like being able to point to the food you want and nod your head vigorously: it conveys the same information with no learning curve.

Consider the file selection process in a typical graphics program:

Luckily, Windows 98 introduced thumbnail support, so you can see the files like this:

This makes it significantly easier to open the file you want; it doesn’t even take the mental effort to map words onto pictures.

You can see the minimum-memory principle at work in features like auto completion, too. Even if you need to type something, some programs make educated guesses about what you’re about to type:

In this example, as soon as you type “M”, Excel guesses that you are likely to be typing Male, because you’ve typed Male before in this column, and proposes that as the auto completion. But the “ale” is preselected so that if you didn’t mean to type Male, you can keep typing (perhaps “ystery”) and overwrite Excel’s guess with no lost effort.

Microsoft Word gets a little bit carried away guessing what you are about to type, as anybody that has ever used that product during the merry month of May has discovered:

Designing For People Who Have Better Things To Do With Their Lives, Redux

In the preceding chapters, I’ve brought up three principles:

• Users don’t read stuff (chapter 6)
• Users can’t use the mouse (chapter 7)
• Users can’t remember anything

You might be starting to get the impression that I think that users are dolts. It’s not true. Disrespecting your users is how arrogant software like Microsoft Bob gets created (and dumped in the trash bin), and nobody is very happy.

On the other hand, there is a much worse kind of arrogance in software design: the arrogant assumption that “my software is so damn cool, people are just going to have to warp their brains around it.” This kind of chutzpah is pretty common in the free software world. Hey, Linux is free! If you’re not smart enough to decipher it, you don’t deserve to be using it!

Human aptitude tends towards the bell curve. Maybe 98% of your customers are smart enough to use a television set. About 70% of them can use Windows. 15% can use Linux. 1% can program. But only 0.1% of them can program in a language like C++. And only 0.01% of them can figure out Microsoft ATL programming. (And all of them, without exception, have beards and glasses.)

The effect of this sharp drop-off is that whenever you “lower the bar” by even a small amount, making your program, say, 10% easier to use, you dramatically increase the number of people who can use it, say, by 50%.

So, I don’t really believe that people are dolts, but I think that if you constantly try to design your program so that it’s easy enough for dolts to use, you are going to make a popular, easy to use program that people like. And you will be surprised by how what seem like small usability improvements translate into lots more customers.

One good way to evaluate the usability of a program or dialog you’ve never seen before is to act a little stupid. Don’t read the words on the dialog. Make random assumptions about what things do without verifying. Try to use the mouse with just one finger. Make lots of mistakes, and generally thrash around. See if the program does what you want, or at least, gently guides you instead of blowing up. Be impatient. If you can’t do what you want right away, give up. If the UI can’t withstand your acting generally immature and stupid, it could use some work.

http://www.joelonsoftware.com/uibook/chapters/fog0000000063.html

When the Macintosh was new, Bruce “Tog” Tognazzini wrote a column in Apple’s developer magazine on UI. In his column, people wrote in with lots of interesting UI design problems, which he discussed. These columns continue to this day on his web site. They’ve also been collected and embellished in a couple of great books, like Tog on Software Design, which is a lot of fun and a great introduction to UI design. (Tog on Interface was even better, but it’s out of print.)

Tog invented the concept of the mile high menu bar to explain why the menu bar on the Macintosh, which is always glued to the top of the physical screen, is so much easier to use than menu bars on Windows, which appear inside each application window. When you want to point to the File menu on Windows, you have a target about half an inch wide and a quarter of an inch high to acquire. You must move and position the mouse fairly precisely in both the vertical and the horizontal dimensions.

But on a Macintosh, you can slam the mouse up to the top of the screen, without regard to how high you slam it, and it will stop at the physical edge of the screen – the correct vertical position for using the menu. So, effectively, you have a target that is still half an inch wide, but a mile high. Now you only need to worry about positioning the cursor horizontally, not vertically, so the task of clicking on a menu item is that much easier.

Based on this principle, Tog has a pop quiz: what are the five spots on the screen that are easiest to acquire (point to) with the mouse? The answer: all four corners of the screen (where you can literally slam the mouse over there in one fell swoop without any pointing at all), plus, the current position of the mouse, because it’s already there.

The principle of the mile-high menu bar is fairly well known, but it must not be entirely obvious, because the Windows 95 team missed the point completely with the Start push button, sitting almost in the bottom left corner of the screen, but not exactly. In fact, it’s about 2 pixels away from the bottom and 2 pixels from the left of the screen. So, for the sake of a couple of pixels, Microsoft literally “snatches defeat from the jaws of victory”, Tog writes, and makes it that much harder to acquire the start button. It could have been a mile square, absolutely trivial to hit with the mouse. For the sake of something, I don’t know what, it’s not. God help us.

In the previous chapter, we talked about how users hate reading, and will avoid it unless they absolutely cannot accomplish their task. Similarly:

Users can’t control the mouse very well.

I don’t mean this literally. What I mean is, you should design your program so that it does not require a tremendous amount of mouse-agility to use it right. Top six reasons:

1. Sometimes people are using sub-optimal pointing devices, like trackballs, trackpads, and the little red thingy on a ThinkPad, which are harder to control than true mice.
2. Sometimes people are using mice under bad conditions: a crowded desk; a dirty trackball making the mouse skip; or the mouse itself is a $5 clone which just doesn’t track right.
3. Some people are new to computers and have not yet developed the motor skills to use mice accurately.
4. Some people literally will never have the motor skills to use mice precisely, and never will. They may have arthritis, tremors, carpal tunnel; they may be very young or very old; or any other number of disabilities.
5. Many people find that it is extremely difficult to double-click without slightly moving the mouse. As a result they often drag things around on their screen when they mean to be launching applications. You can tell these people because their desktops are a mess because half the time they try to launch something, they wind up moving it instead.
6. Even in the best of situations, using the mouse a lot feels slow to people. If you force people to perform a multi-step operation using the mouse, they may feel like they are being stalled which in turn makes the UI feel unresponsive, which, as you should know by now, makes them unhappy.

In ye olden days when I worked on Excel, laptops didn’t come with pointing devices built in, so Microsoft made a clip-on trackball that clipped to the side of the keyboard. Now, a mouse is controlled with the wrist and most of the fingers. This is much like writing, and you probably developed very accurate motor skills for writing in elementary school. But a trackball is controlled entirely with the thumb. As a result, it’s much harder to control a trackball to the same degree of accuracy as a mouse. Most people find that they can control a mouse to within one or two pixels, but can only control a trackball to within 3 or 4 pixels. On the Excel team, I always urged people to try out their new UIs with the trackball, instead of only with a mouse, to see how it would feel to people who are not able to get the mouse to go exactly where they want it.

One of the UI elements which bothers me the most is the dropdown combo list box. That’s the one that looks like this:

When you click on the down arrow, it expands:

Think about how many detailed mouse clicks it’s going to take to choose, say, Times New Roman. First, you have to click on the down arrow. Then, using the scroll bar, you have to carefully scroll until Times New Roman is in view. Many of these dropdowns are carelessly designed to show only two or three items at a time, so this scrolling is none too easy, especially if you have a lot of fonts. It involves either carefully dragging the thumb (with such a small range of movement, it’s probably unlikely that this will work), or clicking repeatedly on the second down arrow, or trying to click in the area between the thumb and the down area — which will eventually stop working when the thumb gets low enough, annoying you even further. Finally, if you do manage to get Times New Roman into view, you have to click on it. If you miss, you get to start all over again. Now multiply by 10, if, say, you want to use a fancy font for the first letter in each of your chapters, and you’re really unhappy.

The poxy combo dropdown control is even more annoying because there’s such an easy solution: just make the dropdown long enough to contain all of the options. 90% of the combo boxes out there don’t even use all available space to drop down, which is a sin. If there is not enough room between the main edit box and the bottom of the screen, the dropdown should grow up until it fits all the items, even if it has to go all the way from the top of the physical screen to the bottom of the physical screen. And then, if there are still more items than fit, let the combo scroll automatically as the mouse approaches the edge, rather than requiring the poor user to mess with a teensy weensy scrollbar.

Furthermore, don’t make me click on the little tiny arrow to the right of the edit box before you pop up the combo: let me click anywhere on the combo box. This expands the click target about tenfold and makes it that much easier to acquire the target with the mouse pointer.

Let’s look at another problem with mousing: edit boxes. You may have noticed that almost every edit box on the Macintosh uses a fat, wide, bold font called Chicago which looks kind of ugly and distresses graphic designers to no end. Graphic designers (unlike UI designers) have been taught that thin, variable spaced fonts are more gracious, look better, and are easier to read. All this is true. But graphic designers learned their skills on paper, not on the screen. When you need to edit text, monospace has a major advantage over variable spaced fonts: it’s easier to see and select narrow letters like “l” and “i”. I learned this lesson after watching a sixty year old man in a usability test painfully trying to edit the name of his street, which was something like Fillmore Street. We were using 8 point Arial, so the edit box looked like this:

Notice that the I and the Ls are literally one pixel wide. The difference between a lower case I and a lower case L is literally one pixel. (Similarly, it is almost impossible to see the difference between “RN” and “M” in lower case, so this edit box might actually say Fillrnore.)

There are very few people who would notice if they mistyped Flilmore or Fiilmore or Fillrnore, and even if they did, they would have a heck of a time trying to use the mouse to select the offending letter and correct it. In fact, they would even have a hard time using the blinking cursor, which is two pixels wide, to select a single letter. Look how much easier it would have been if we had used a fat font (shown here with Courier Bold)

Fine, OK, so it takes up more space and doesn’t look as cool to your graphic designers. Deal with it! It’s much easier to use; it even feels better to use because as the user types, they get sharp, clear text, and it’s so much easier to edit.

Here’s a common programmer thought pattern: there are only three numbers: 0, 1, and n. If n is allowed, all n‘s are equally likely. This thought pattern comes from the belief (probably true) that you shouldn’t have any numeric constants in your code except for 0 and 1. (Constants other than 0 and 1 are referred to as “magic numbers”. I don’t even want to go into the gestalt of that.)

Thus, for example, programmers tend to think that if your program allows you to open multiple documents, it must allow you to open infinitely many documents (as memory allows), or at least 2^32, the only magic number programmers concede. A programmer would tend to look with disdain on a program which limited you to 20 open documents. What’s 20? Why 20? It’s not even a power of 2!

Another implication of all n’s are equally likely is that programmers have tended to think that if users are allowed to resize and move windows, they should have complete flexibility over where these windows go, right down to the last pixel. After all, positioning a window 2 pixels from the top of the screen is “equally likely” as positioning a window exactly at the top of the screen.

But it’s not true. As it turns out, there are lots of good reasons why you might want a window exactly at the top of the screen (it maximizes screen real estate), but there aren’t any reasons to leave 2 pixels between the top of the screen and the top of the window. So, in reality, 0 is much more likely than 2.

The programmers over at Nullsoft, creators of WinAmp, managed somehow to avoid the programmer-think that has imprisoned the rest of us for a decade. WinAmp has a great feature. When you start to drag the window near the edge of the screen, coming within a few pixels, it automatically snaps to the edge of the screen perfectly. Which is probably exactly what you wanted, since 0 is so much more likely than 2. (The Juno main window has a similar feature: it’s the only application I’ve ever seen that is “locked in a box” on the screen and cannot be dragged beyond the edge.)

You lose a little bit of flexibility, but in exchange, you get a user interface that recognizes that controlling the mouse precisely is hard, so why should you have to? This innovation (which every program could use) eases the burden of window management in an intelligent way. Look closely at your user interface, and give us all a break. Pretend that we are gorillas, or maybe smart orangutans, and we really have trouble with the mouse.

http://www.joelonsoftware.com/uibook/chapters/fog0000000062.html

When you design user interfaces, it’s a good idea to keep two principles in mind:

1. Users don’t have the manual, and if they did, they wouldn’t read it.
2. In fact, users can’t read anything, and if they could, they wouldn’t want to.

These are not, strictly speaking, facts, but you should act as if they are facts, for it will make your program easier and friendlier. Designing with these ideas in mind is called respecting the user, which means, not having much respect for the user. Confused? Let me explain.

What does it mean to make something easy to use? One way to measure this is to see what percentage of real-world users are able to complete tasks in a given amount of time. For example, suppose the goal of your program is to allow people to convert digital camera photos into a web photo album. If you sit down a group of average users with your program and ask them all to complete this task, then the more usable your program is, the higher the percentage of users that will be able to successfully create a web photo album. To be scientific about it, imagine 100 real world users. They are not necessarily familiar with computers. They have many diverse talents, but some of them distinctly do not have talents in the computer area. Some of them are being distracted while they try to use your program. The phone is ringing. WHAT? The baby is crying. WHAT? And the cat keeps jumping on the desk and batting around the mouse. I CAN’T HEAR YOU!

Now, even without going through with this experiment, I can state with some confidence that some of the users will simply fail to complete the task, or will take an extraordinary amount of time doing it. I don’t mean to say that these users are stupid. Quite the contrary, they are probably highly intelligent, or maybe they are accomplished athletes, but vis-à-vis your program, they are just not applying all of their motor skills and brain cells to the usage of your program. You’re only getting about 30% of their attention, so you have to make do with a user who, from inside the computer, does not appear to be playing with a full deck.

Users Don’t Read the Manual.

First of all, they actually don’t have the manual. There may not be a manual. If there is one, the user might not have it, for all kinds of logical reasons: they’re on the plane; they are using a downloaded demo version from your web site; they are at home and the manual is at work; their IS department never gave them the manual. Even if they have the manual, frankly, they are simply not going to read it unless they absolutely have no other choice. With very few exceptions, users will not cuddle up with your manual and read it through before they begin to use your software. In general, your users are trying to get something done, and they see reading the manual as a waste of time, or at the very least, as a distraction that keeps them from getting their task done.

The very fact that you’re reading this book puts you in an elite group of highly literate people. Yes, I know, people who use computers are by and large able to read, but I guarantee you that a good percentage of them will find reading to be a chore. The language in which the manual is written may not be their first language, and they may not be totally fluent. They may be kids! They can decipher the manual if they really must, but they sure ain’t gonna read it if they don’t have to. Users do just-in-time manual reading, on a strictly need-to-know basis.

The upshot of all this is that you probably have no choice but to design your software so that it does not need a manual in the first place. The only exception I can think of is if your users do not have any domain knowledge — they don’t really understand what the program is intended to do, but they know that they better learn. A great example of this is Intuit’s immensely popular small-business accounting program QuickBooks. Many of the people who use this program are small business owners who simply have no idea what’s involved in accounting. The manual for QuickBooks assumes this and assumes that it will have to teach people basic accounting principles. There’s no other way to do it. Still, if you do know accounting, QuickBooks is easy to use without the manual.

In fact, users don’t read anything.

This may sound a little harsh, but you’ll see, when you do usability tests, that there are quite a few users who simply do not read words that you put on the screen. If you pop up an error box of any sort, they simply will not read it. This may be disconcerting to you as a programmer, because you imagine yourself as conducting a dialog with the user. Hey, user! You can’t open that file, we don’t support that file format! Still, experience shows that the more words you put on that dialog box, the fewer people will actually read it.

The fact that users do not read the manual leads many software designers to assume that they are going to have to educate users by describing things as they go along. You see this all over the place in programs. In principle, it’s OK, but in reality, people’s aversion to reading means that this will almost always get you in trouble. Experienced UI designers literally try to minimize the number of words on dialogs to increase the chances that they will get read. When I worked on Juno, the UI people understood this principle and tried to write short, clear, simple text. Sadly, the CEO of the company had been an English major at an Ivy League college; he had no training in UI design or software engineering, but he sure thought he was a good editor of prose. So he vetoed the wording done by the professional UI designers and added lots of his own verbiage. A typical dialog in Juno looks like this:

Compare that to the equivalent dialog from Windows:

Intuitively, you might guess that the Juno version, with 80 words of instructions, would be “superior” (i.e., easier to use) than the Windows version, with 5 words of instructions. In reality, when you run a usability test on this kind of thing, you’ll find that

• advanced users skip over the instructions. They assume they know how to use things and don’t have time to read complicated instructions
• most novice users skip over the instructions. They don’t like reading too much and hope that the defaults will be OK
• the remaining novice users who do, earnestly, try to read the instructions (some of whom are only reading them because it’s a usability test and they feel obliged) are often confused by the sheer number of words and concepts. So even if they were pretty confident that they would be able to use the dialog when it first came up, the instructions actually confused them even more.

Now, Juno was obviously micro-managed beyond all reason. More to the point, if you’re an English major from Columbia, then you are in a whole different league of literacy than the average Joe, and you should be very careful about wording dialogs that look helpful to you. Shorten it, dumb it down, simplify, get rid of the complicated clauses in parentheses, and usability test. But do not write things that look like Ivy League faculty memos. Even adding the word “please” to a dialog, which may seem helpful and polite, is going to slow people down: the increased bulk of the wording is going to reduce, by some measurable percentage, the number of people who read the text.

Another important point is that many people are intimidated by computers. You probably know this, right? But you may not realize the implications of this. I was watching a friend try to exit Juno. For some reason she was having quite a bit of trouble. I noticed that when you try to exit Juno, the following dialog pops up:

She was hitting No, and then she was kind of surprised that Juno hadn’t exited. The very fact that Juno was questioning her choice made her immediately assume that she was doing something wrong. Usually, when programs ask you to confirm a command, it’s because you’re about to do something which you might regret. She had assumed that if the computer was questioning her judgment, then the computer must have been right, because, after all, computers are computers where as she was merely a human, so she hit “No.”

Is it too much to ask people to read 11 lousy words? Well, apparently. First of all, since exiting Juno has no deleterious effects, Juno should have just exited without prompting for confirmation, like every other GUI program in existence. But even if you are convinced that it is crucial that people confirm before exiting, you could do it in two words instead of 11:

Without the completely unnecessary “thank you” and the remorse-inspiring “are you sure?“, this dialog is a lot less likely to cause problems. Users will certainly read the two words, say “um, duh?” to the program, and pound the Yes key.

Sure, the Juno Exit Confirmation dialog trips up a few people, you say, but is it that big a deal? Everyone will eventually manage to get out of the program. But herein lies the difference between a program which is possible to use versus a program which is easy to use. Even smart, experienced, advanced users will appreciate things that you do to make it easy for the distracted, inexperienced, beginner users. Hotel bathtubs have big grab bars. They’re just there to help disabled people, but everybody uses them anyway to get out of the bathtub. They make life easier even for the physically fit.

In the next chapter, I’ll talk a bit about the mouse. Just like users don’t/won’t/can’t read, some are not very good at using the mouse, so you have to accommodate them.