Interrobang's Journal: Preliminary Course Proposal: Design for Developers

(...and friends.)

A friend of mine sent me this big long e-mail about "yak-shaving," which in this case involved wanting to do something with a piece of software, discovering that it wanted access to a particular library he didn't have, trying to find, and then trying to install the library, just to get back to the original task. He mentioned what I noticed ages ago, which is that a lot of open-source stuff doesn't always include everything you need to get the software up and running, I think in part because the developer(s) assume you already have it (they're funny like that).

That got me thinking about a lot of the crap I've seen both in OSS projects and in proprietary projects -- I have to say, proprietary software has definitely got the drop on OSS in terms of including everything (hell, the other day I got an e-mail with a link to Acrobat Reader download in it, just in case you wanted to grab a linked PDF, and were the last person on earth still without a PDF reader, case in point). And I thought a lot of these problems reflect a lack of basic design knowledge on the part of most software developers.

By "design" I mean "visual, textual, and informational rhetoric," rather than "how to put together a program in a way that works and makes sense."

That got me thinking...

"Every CS programme should include a course on design fundamentals, tailored to the specific wants and needs of software development. I should write a syllabus for a course like that, and post it five or six different places, so the meme gets out..."

So, uh, if you were developing a postsecondary (2nd year+ university or third-year college) course on design fundamentals for software developers, what would you include?

What I'd propose would look something like this:

• Unit 1: Introduction, What Is Design and Why Do You Care?
• Unit 2: Audience (User) Analysis: Who are your users? What are their wants and needs? What can you assume about them? What shouldn't you assume about them?; Bias; How to find out
• Unit 3: Information architecture and management for code, UI, and documentation
• Unit 4: Documentation: Commenting and in-code documentation; User and peripheral documentation; Web documentation; documentation design
• Unit 5: UI Design Issues: Consistency (ordered lists, menus, workalikes, labels, navigation controls, buttons), Layout, feature placement
• Unit 6: International Issues in Design: Design for translation, localisation, language bias, interface bloopers, Basic English
• Unit 7: Metaphorics, Analogy, and Software Design: Introduction to metaphorics, metaphorics and user analysis, metaphorics and assumptions, critical analysis. Assignment: Critique an application using metaphorics principles learned in class (instructor approved topic), 15%.
• Unit 8: Troubleshooting Design Problems Before they Happen: Avoiding common problems (yak-shaving, inconsistencies, typos, the Comprehensible Only If Known problem), user acceptance testing with a design focus. Assignment: Using the application from the last assignment, devise a simple testing scenario to evaluate a design feature. 10%
• Final Assignment: Subject to instructor approval of the application/critique, prepare a critique of a well-known application using at least three of the principles discussed in the course. Max. length 3500 words, 35%, include screenshots.

Note: I know that's only 70% of the total mark accounted for; I'm assuming 10% attendance and 20% in 5% five-finger exercises, or a midterm exam or something...

____
Interface Blooper Example: I still remember from grad school, doing an analysis of Netscape as it appeared in four different languages, and finding that in German, what was then the "Guide" button in English was "Guide" in the German version as well. A quick trip to the English-German dictionary showed why -- according to that dictionary, anyway, the standard German word for "Guide" is "Fuhrer." *headdesk*

I can hear Eth's feet whistling as he descends from 30 000 feet to jump all over me for that, but I'm just reporting what that particular dictionary said, and obviously it was of some concern, since they'd left the button untranslated (as far as we could tell).

Design isn't the only problem...

[FortKnox]

The problem isn't just design. Its every aspect of a project minus the implementation step. No OSS project ever has a true project manager. And, to be honest, most developers either:
A.) Don't WANT to be a project manager or
B.) Are bad project managers.

It takes a personality that most developers, especially OSS developers don't have...

Re:

[Interrobang]

Well, yeah, that's true, but a lot of the problems I've been seeing in my tech writing experience (admittedly with shareware and commercial software), and the problems I've noticed in OSS as well, are directly attributable to design. I'm talking about stuff like icons that don't match the application/function, labels that are inconsistent across a project, typos in the interface, control sets that are non-standard and non-standardised, poor use of metaphor, a complete lack of user analysis/understanding, e

Re:

[ces]

The problem is even worse than that. In my experience most project/product managers aren't very good at what they do either. So much so that when you do get effective ones it ends up being a notable exception.

Some of this problem lies not with the project or product manager themselves but with the organization not giving them the tools and support they need to do their jobs.