1. Introduction – Why Software Sucks

Lecture: Users think that today's software sucks. It's unsafe, unreliable and hard to use. These problems are not technical. We've been able to solve them for many years, but instead we've gotten a paper clip with eyebrows. Why? Software sucks because developers forget (or never knew) THE bedrock principle of software development: KNOW THY USER, FOR HE IS NOT THEE. For example, what do your customers come to you for? Hint: it's not software. For another example, do you think your users care about your application? They don't. Never have, never will. They care about accomplishing the task that it does. They don't want to think about you or your application at all. It's your job to care about them anyway. The talk will show good and bad examples from commercial software and web sites, those that understand and help their users, and those that treat users with contempt. For example, consider the ads for Microsoft Office that show non-upgrading users wearing plastic dinosaur heads. Developers fear looking like dinosaurs by not having the latest technology, but ordinary users fear breaking an installation that currently works, or having useless junk like dancing paper clips slow down their computers so they need to buy new ones. Your user is not you. We put this nation on wheels not by training the entire population as mechanics, but by improving cars so they didn't often need mechanics. The same transition needs to happen to the software industry. This talk provides sound design principles so that your software won't suck. Learn how blindness will improve your vision.

Lab: Discuss your current software products in light of the ideas put forth in this lecture. Identify areas of it that suck and areas that don’t. Discuss the sorts of design modifications that would be necessary to convert the former into the latter.

2. Using Roles and Personas for UI Design

Lecture: It’s very easy to say during the development process that, “the user wants this,” or “the user hates that.”  But this nebulous concept of “the user” leads to all sorts of misunderstandings. It is surprisingly difficult to nail down just who these user people are, what they like and what they don’t, what they need and what they want and what they only think they want, and what they are willing to tolerate. It’s even more complicated because most applications need to serve several different types of users.  Somehow “the user” always comes out resembling the developer asking the question, which is completely wrong.

This talk deals with the concept of a persona, a fictitious character that represents a particular class of user.  We’ll discuss generating personas based on the actual user population, assigning characteristics such as gender, ethnicity,  and technological expertise to the persona. We’ll add data and stories that flesh out the personas: “21-year old Diego lives on his iPhone all day every day, 42-year old Linda has three children and needs to be home by 3:30 no matter what, and 67-year old Harcourt won’t touch a keyboard and insists that his secretary print out all of his emails and take dictation of the replies.”  We’ll examine the process of comparing the generated personas to actual users. Finally, we’ll discuss using personas in the design process: “Diego would love that feature and would use it all the time, but Linda would never even consider using it, no matter how many times you showed her, because she doesn’t find it helpful, so you shouldn’t bother her with it.”

Lab: Develop personas for the design of your product that represent the classes of user that you have identified in your customer population. Expand them and document them as much as permitted by the time slot.

3. Using WPF for Good and Not Evil

Lecture: Putting the power of Windows Presentation Framework into the hands of developers who are unschooled in the art of user interface design is like giving liquor and Corvette keys to teenage boys. It's fun for them, temporarily, but the end results aren't pretty. “The first time they see it, they will think it is cute. The eleventh time they see it, they will think about killing you,“ writes etiquette columnist Miss Manners. Users don't give a flying fish about their applications in and of themselves. Never have; never will. They only care about accomplishing the tasks that they bought the software to get done, so that they can get on with eating and making love and living their lives. Forget about color gradients and button radii. Learn how to use WPF's power to accomplish good things that your users actually care about, not useless nonsense that does nothing but titillate the rococo vanity of socially misfit geeks.

We will examine the Family.Show WPF application, often cited as a paragon of good WPF design. We will study its use of three separate WPF features: color gradients, motion, and re-looking of controls. We will see cases in which the app uses each of these features well, quickly and easily improving the user experience far beyond anything Windows Forms could do. And we’ll also see different parts of the very same app using the very same WPF features to degrade the user experience, in once case inflicting genuine physical, not just mental, pain on its user.  We will discuss the underlying principles that cause e

Lab: Examine your proposed designs or your existing products in light of the examples in this lecture. Identify usages of advanced graphical features that help the user and those that do not. Propose strategies for converting the latter into the former.

4. Making Your Apps Just Work^tm

Lecture: Far too many programs are designed from the toolkit outwards – here’s what the toolkit does, so here’s what we will do, regardless of whether it makes the user happier. We’ll introduce the concept of user-centric design, the importance of putting the user experience designer into the user’s shoes, to design software that Just Works™. We’ll examine the case study of applying text styles in MS Word, between early versions that  required a drop-down selection and version 2007,  in which the user just hovers the mouse over a sample style. We’ll go into detail over the concept of the Undo operation and how it makes an application explorable, discuss various ways of implementing it, and consider how to handle actions that can’t be undone. (Hint: it’s not asking the user “are you sure?”). We’ll consider the case of saving data, the automatic saving in Money and One Note versus manual in Office. We’ll discuss the need to ensure that edge cases don’t degrade the mainstream cases, with a case study of the  Carbonite automatic disk backup program. We’ll also discuss the need to ensure that the more frequently used an operation is, the easier it is to do. Case study: Vonage VoIP telephone web user interface versus tray application.  Finally, we’ll talk about handling errors: recasting the concept of a user error, preventing them from occurring, and then minimizing that amount of thinking a user has to do if one does occur.

Lab: Identify areas in your current software design that sacrifice ease of use in return for flexibility and power. Discuss the sorts of modifications that would allow your app to maintain the flexibility and power, while making your app much easier to use without thinking for users who only wanted the most common cases.

5. Testing on Live Animals

Lecture: You never know how well anything works until you test it. Somehow this principle often gets lost when it comes to the user experience. What is obvious to a developer who uses an application all day every day is opaque to a casual user, or even a non-casual user who doesn’t understand (or want to understand) a program’s internal workings.  User interfaces need to be tested early and often so their efficacy, or lack therefore, can be determined.

We’ll discuss the timing of user interface testing, learn why waiting until the beta (or even alpha) phase is never enough. We’ll consider the frequency of testing iteration versus the number of users; why more tests with fewer users in each are better than fewer tests with more users.  We’ll address the issues and difficulties of recruiting the test subjects, and the pitfalls of Jakob Nielsen’s ideas on “hallway usability testing”. We’ll see how important is the exact wording of the tasks that you set for users and the data that you put in front of them. And because the user interface will evolve quickly as data becomes available, we’ll discuss ways of generating prototype user interfaces quickly.  Finally, we’ll discuss the art and science of making changes to the user interface based on what you learn during your testing, and strategies for handling the resistance that inevitably arises.

Lab: Perform a quick usability test on your company’s existing or proposed products. Discuss the information that you collect as a result, the lessons that it teaches, and the changes that you would make to your product as a result.

6. Instrumentation For Knowing Thy User

Lecture: The most important principle of user experience design is “Know Thy User, for He Is Not Thee.” However, it is very difficult to know exactly what users think of your application – what they find easy to use, what’s hard, what makes sense to them and what doesn’t. If you ask them, they don’t know, or can’t remember, or don’t want to admit they can’t use your application, or don’t want to insult you. Even finding users to ask is difficult, and current techniques such as focus groups almost always produce unrepresentative results.

The only way to know for sure is to instrument your application so that it reports user experiences over many sessions.  This talk will discuss ways in which this can be done and the design decisions that need to be made to accomplish it successfully. User experience tracking is different from other kinds of program instrumentation – it has to be very light, so that it doesn’t degrade performance at all.  Which sorts of events should you record? How do you convince users to opt in for data collection? How do you send and store the data, and how do you analyze it? A sample user experience tracking framework will be demonstrated. The silent majority has a lot to say, if you know how to listen to them.

Lab: Examine a working application containing a user instrumentation framework. Follow the flow of information from instrumented application to database to designer. Discuss how you would instrument your own applications.