designing good software -- by Joel ("on Software")

[Darren Dirt]

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?

^ conclusion of Joel Spolsky's excellent (and surprisingly brief!) free eBook "User Interface Design For Programmers" (http://www.joelonsoftware.com/uibook/fog0000000249.html)

[Lazybones]

Too many assumptions:
- A product has not already been requested
- A time line has not been set
- The developer has a STRONG understanding of the business behind the target solution.
- The information about the target problem is accurate
- The developer is working for free without a budget.

[Darren Dirt]

Sorry I wasn't clear but I quoted the *summary conclusion* of a mini-book that Joel makes available on his website. Most of your assumptions are definitely important to address, however
if you read or skim the preceding chapters to get an idea of how he builds up to the conclusion, I believe you'll see that the focus of his book is on design considerations themselves (not PM issues) of an actually requested/needed product for which the developer has the benefit of both reasonable time and reasonable access to the potential end users of the finished app.

In other words, what kind of warnings/boundaries/goals the developer needs to keep in mind once he's got the "green light" and he's elbow deep in pie in the sky ideas (coming from himself or the client )


HTH

[Thorin]

Have you read the actual book, Darren?  My first employer in the IT field bought it and made sure all the programmers (all seven of us) read it cover to cover.  The book does not give any hard and fast rules, but does a good job of keeping you (if you're a detail-oriented person like most programmers are) on target to making a useful product.  I recommend it to any and all of us here that create software for clients on a daily basis.

[Darren Dirt]

No, I've been meaning to do more than just skim through the HTML-all-on-one-page version, but the Amazon reviews of the actual book (which presumably is the same content) seem pleased but not ecstatic about what it offers to the industry. I'm guessing a lot of them expected him to go into more detail about specifics, but from what I can understand Joel's intention (like many of his articles on his excellent website) is to encourage tech-minded developers to spend more quality time on the human side of development (especially user interface/interaction considerations). For that I'm appreciative -- imagine this eBook being given as "required reading" to first semester NAIT CST students

[Tom]

Is there a PDF of that anywhere? Thats a lot of HTML to go through...

[Mr. Analog]

Or you could check it out at the Library, right?

[Tom]

Or you could check it out at the Library, right?

But I'm lazier than Lazy

[Darren Dirt]

Here's Chapter 1:
http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html

A link to the next chapter (or related chapters) is included in the above.

Or you can do a "save as PDF" for the previous all-on-one-page link ^_^