Tech Talk with Mom: Explaining what I do

Me: ...as I've explained before, I'm the Lead Architect for User Experience for the WebSphere Foundation.

Mom: That's nice, dear.

Me: Uh, thanks. Basically, I try to improve the usability of software products. Usability and user experience or pretty much the same thing. It's also known as human factors, user-centered design, outside-in design, human-computer interaction, consumability, interaction design, user engineering...

Mom: You engineer users?

Me: Well, no... okay, so that might not be the best term.

Mom: So your job is to make things simple?

Me: Exactly!

Mom: If making things simple is your goal, why do you have twenty different names for what you do?

Me: Have you ever played Whack-a-Mole? It's the same basic idea.

Mom: Uh huh.

Me: Anyway... we have a team of usability professionals who work on IBM WebSphere products to help simplify the design. We have teams of developers who write the code, and we work with them on new features that are going into the product.

Mom: Why can't the developers do their own design?

Me: Well, they can. They do. There are different types of design. First there's the design of the code itself. Developing code is difficult work, they need to figure out the best way to design their code to anticipate future enhancements and extensions, they need the code to perform well, they need their code to work with the other hundred developers in their organization, and so on. On top of this, developers are constantly being asked to pick up new programming models and languages. It's a tough job.

Mom: If you aren't a developer, how do you know how tough it is?

Me: I hang out with developers, and they love to talk about this stuff when they've been drinking. They think it attracts the ladies.

Mom: Does it?

Me: Not so much. Though I've seen the "polymorphism" line work a few times. The point is that developers design the code, but our team focuses on the user interfaces. Developers often are asked to design user interfaces as well, but it's tough for them to do.

Mom: Why?

Me: The biggest problem is probably a conflict of interest. Developers everywhere are under intense pressure to get their code done as fast as possible.

Mom: That's dumb.

Me: Well, not completely. Remember, we're talking about developers here, not normal people. They actually like to write code. They're like kids drawing pictures in kindergarten -- you need to know when to take away their crayons. But more importantly, by definition the developers are intimately knowledgeable about the inner workings of the program, which makes it very difficult for them to put themselves into the head of a user who is just getting started. It's very difficult for people to remember what it's like to not know something.

Mom: So you're saying that your ignorance is actually a job skill?

Me: Exactly!

Mom: Your father will be so proud.

Me: So even though it might seem like a strange system, it's actually setup so that different people have different focuses... the developer wants to get the code done on schedule, the usability person wants the design to be simple, the tester wants the code to function reliably, the guy in marketing wants every new requirement in the product by next Tuesday... and then by all of us working together, we try to achieve the right balance between all the competing interests.

Mom: You're not going to start singing Kumbayah again, are you?

Me: Dad says I have a nice singing voice.

Mom: He also thinks Gilligan's Island is the funniest show on TV.

Me: Good point. So... it's tough for developers to focus their attention on creating usable user interfaces while juggling all their other responsibilities as well. But there's another piece to what we do - we test our designs with users before the product ships so we can know that we've done a good job. That way we're able to catch a lot of problems that otherwise wouldn't be noticed until after the product ships. So basically we work as customer advocates, sometimes based on actual customer feedback, sometimes via general customer knowledge, and sometimes by just making sure that the customer needs aren't forgotten in the push to get the products out the door.

Mom: So you're ignorant about the code, and when you don't know how to design something, you just go talk to customers?

Me: Pretty much.

Mom: And they pay you for this?

Me: It's a great job, yeah. But it's not really as easy as it sounds. Even though we're not developers, we need to develop a good technical knowledge about our area if we really want to contribute decent design. Plus there's different design guidelines depending on whether you're designing for a web application, a website, an installed program, an installation process, a command line interface, a scripting interface... and so on. It takes experience to tell the difference between a minor design issue that will be mildly confusing for users and a major design problem that will cause hundreds of support calls. Designing usability sessions so that you get actionable results is a unique skill. And understanding the right balance between customer requirements, usability concerns, marketing needs, schedule pressures... these are things that never get easy. And that's not to mention trying to understand the impact that things like SOA or open-source software or new programming languages will have on the product's usability priorities in the future. See? So that's what I do.

Mom: That's nice, dear.