UPA 2006 — Experienced Practitioners Track

The following is notes I took throughout the day which I am now expanding upon after a decent night’s sleep… Some of it still reads like notes, but I decided to leave it like that.

I’ve been to 4 UPA conferences and each time I opted to take a tutorial or two. Each time, with the exception of Steve Fadden’s tutorial on Task Analysis, I was greatly disappointed. The material was always too beginner. Now, I am not a usability guru, as I have gone to great lengths stating in the past, but I do know a thing or two about design and usability. The tutorials were either beginner level or not at all what was described in the advance program.

This year I wasn’t going to do a tutorial because of my history with them. But I saw they were offering an Experienced Practitioners track. That’s what I did yesterday and for the most part it was worthwhile. I hope they offer this again at next year’s conference. Good idea Dee Dee.

The format was a good one; it had a somewhat Unconference feel to it. The room was limited to about 40 people and we stayed in the one room throughout the day. The speakers stayed too. There were 5 different presentations, each lasting about 1.5 hours. The first prezo was on Integrating UCD with Requirements Engineering. Which frankly, with the overlap I’ve seen between what I do and what a requirements modeler does, makes sense.

The speakers were Lisa Battle, Rebecca Ray, and Karen Bachmann. Each brought a different perspective to the table. They did a great job of getting involvement from the attendees too.

Sidenote: I overheard Ginny Redish say she is writing a “How to write Web content book” which she hopes will be THE writing for the web book. Hey, how about this white paper I wrote! Six pages and it’s all you need to know! ;)

We talked a lot about how User-Centered Design (UCD) and Requirements Engineering (RE) have grown in parallel and often produce the same or similar documentation. Very generically speaking, UCDers facilitate the discovery of the user requirements, while REers facilitate the discovery of the system and business requirements. Loops must be closed people! I’ve had the experience of dealing with the overlap of REers and my work and somehow trying to steer the process when the SMEs and BAs are being pulled by two different, yet not so much with the different, processes.

Part of the problem, especially for timelines (this is a generalisation) is that I need the same people from the business side of things as the RE does and usually at the same time. The SMEs and BAs get pulled by us to focus on the system, no the user, no the system!

Which is why I just focus on the system and see the users as a usually intregal part. Much in the way designers have to become developers to understand why they can’t or won’t code something to spec, we also have to become REers and BAs, etc. I do it solely to keep my sanity and so I know what the heck is going on with the project. You have to be involved in everything. So you learn how to write use cases. And train the business people to look at actual workflows, not system needs which sometimes need input from an “Actor.” Sorry, got a little ranty there.

There was a lot of talk about early involvement, especially when you don’t own the requirements effort. I am not sure UCDers should own anything. Need to think more about that. More talk about where UCD fits. Frankly, it’s such a plastic methodology it can fit anywhere. The question is where does it provide the most value. Again it depends, but like voting it should be early and often.

I wonder how my perspective on UCD will change in the coming months. Now, I don’t not believe in UCD as a stand alone method.

Big U little u what beings with U? “Usr2.0” “Usr Next.” “Usrnext.com”

What do you document? What is to be, or what happened? What’s better? I am leaning toward “happened” when it is web and not greatly complex (different from complicated) and “to be” for complex and non-web. I make the distinction between web and non-web because web development is so damn fluid and malleable. Doesn’t work? Change it. Not so much with the next up-and-coming iPod killer. If it doesn’t work initially it won’t kill anything but itself. Unless it’s white and iPoddy.

How do the processes integrate? How do the people integrate? Processes are run by people, so it’s not about how the boxes line up on the process flow chart, but how the people interact within and throughout the boxes. Software Development is People!

People talk about institutionalizing UCD, I wonder if that is a good thing…

Categorizing goals/objectives by stakeholder. That is a good thing.

~~~Need to do some editing from here on down, but publishing for now~~~~

If I can record directly to my iPod, why the hell can’t I record directly via iTunes?

RE and UCDers use the same people to get what they need. Good to integrate or learn the opposite “skills” to add value.

My iBook needs a “conference battery” that can go for 8 hours… I still get 3-4 hours of use, but a conference day goes from 7am to 6pm. And often power is no where to be found (conveniently).

I need to put a TIP jar on my new desk.

The lack of a shelf.