Showing posts with label humor. Show all posts
Showing posts with label humor. Show all posts

Friday, November 16, 2007

Explaining your products to your customers

This video illustrates some useful Best Practices from a UX standpoint.



(Thanks to my colleague Tim Francis for pointing me to this video)

Wednesday, July 25, 2007

Via Croc o' Lyle: If architects had to work like programmers

Croc o' Lyle points us to a great faux letter that was apparently created by Software Technology Support Center. The letter is a PDF, but I've cut-n-pasted it here for your reading convenience:

Dear Mr. Architect:
Please design and build me a house. I am not quite sure what I need, so let’s get started. My house should have between two and 45 bedrooms. Just make sure the plans are such that the bedrooms can be easily added or deleted. When you bring the blueprints to me, I’ll make the final decision about what I want. Also, bring me the cost breakdowns for each configuration so I can arbitrarily pick one at a later time.

Keep in mind that the house I ultimately choose must cost less than the one I am currently living in. Make sure, however, that you correct all the deficiencies that exist in my current house (the floor of my kitchen vibrates when I walk across it, and the walls don’t have nearly enough insulation in them).

As you design, also keep in mind that I want to keep yearly maintenance costs as low as possible. This should mean the incorporation of extra-cost features like insulated windows or composite siding. (If you choose not to use Anderson insulated windows, be prepared to explain you decision.)

Please take care that modern design practices and the latest materials are used in construction of the house, as I want it to be a showplace for the most up-to-date ideas and methods. Be alerted, however, that the kitchen should accommodate (among other things) my 1952 Gibson refrigerator.

To assure that you are building the correct house for our entire family, you will need to contact each of my children and our in-laws. My mother-in-law will have very strong feelings about how the house should be designed, since she visits us at least once a year. Make sure you weigh all these options carefully and make recommendations. However, I retain the right to overrule any recommendation you make.

Please don’t bother me with small details right now. Your job is to develop the overall plans for the house and get the big picture. At this time, for example, it is not appropriate to be choosing the color of the carpeting; however, keep in mind that my wife likes blue.

Also, do not worry at this time about acquiring the resources to build the house itself. Your first priority is to develop detailed plans and specifications. Once I approve these plans, however, I would expect the house to be under roof within 48 hours.

While you are designing this house specifically for me, keep in mind that sooner or later I will have to sell it to someone else. It should — therefore appeal to a wide variety of potential buyers. Please make sure, before you finalize the plans, that there is a consensus of the potential home buyers in my area that they like the features of this house.

I advise you to run up and look at the house my neighbor built last year, as we like it a great deal. It has many things that we feel we need in our new home, particularly the 75-foot swimming pool. With careful engineering, I believe you can design this into our new house without impacting the construction cost.

Please prepare a complete set of blueprints. It is not necessary at this time to do the real design, since they will be used only for construction bids. Be advised, however, that you will be held accountable for any increase of construction cost as a result of later design changes.

You must be thrilled to be working on such an interesting project! To be able to use the latest techniques and materials and to be given such freedom in your designs is something that can’t happen very often. Contact me as soon as possible with your ideas and completed plans.

Sincerely,
The Client

PS: My wife just told me she disagrees with many of the instructions I have given you in this letter. As the architect, it is your responsibility to resolve these differences. I have tried in the past and have failed to accomplish this. If you can’t handle this responsibility, I will have to find another architect.

PPS: Perhaps what I need is not a house at all, but a travel trailer. Please advise me as soon as possible if this is the case.

I think the part about the 1952 Gibson refrigerator is my favorite.

Wednesday, May 23, 2007

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.