Hey ThoughtWorkers,

So at TWU we learned about a ton of different ways to test software: Unit Tests, Functional Testing, GUI Testing, etc. Here’s my question:

What’s the point of a tested tool that the user (or perhaps customer, if you prefer) finds difficult to actually use? What about Usability Testing? How about testing to see if your deliverables meet the problems found during analysis? Where do these kinds of testing come in?

Sincerely,

Josh

I just wanted to make a note that the experiences of those who live in the Diamond District’s (infamous?) G-Block live a very different life from those of us who live in other parts of the District. Not that I’m whining, you should just realize that there are some major differences in your experiences. Here’s a list of things I’ve noted:

• Your beds are amazing. Our beds are wooden.
• Your flats are decorated. Ours are plain jane.
• Your kitchens are outfitted with machines that heat food. In ours this is not guaranteed.
• Your flats come furnished with living plants. Ours most definitely do not.
• Your furniture is poofy and comfortable. Ours is not poofy (but is generally comfortable).
• You generally have few people and many rooms. We generally have one room per person (but sometimes more people than rooms).
• Your block is secured by a 3-5 person security team. Ours are protected by one guy…who’s generally asleep.

Am I missing anything?

(Or at least ThoughtWorks India)

Rarely does one ever hear the sound of phones ringing in the office. I didn’t realize this until this afternoon when an office phone rang…a sound that was oddly unfamiliar to me.

My hypothesis is that all the interaction is either happening in-person or over instant messenger, rendering the telephone relatively useless. TWIers, any opinions?

100_2024

Originally uploaded by josh.ev9.

Just another day at ThoughtWorks, or at least ThoughtWorks University. While we were designing the interface (and experience) for a new internal tool, we involved some real future users. In this photo, the Analyst team is carrying out a study with a low fidelity prototype, which led to a pretty sweet interface design, if I do say so myself.

Pictured, from the left: Deepti, Bonna, (anonymous user), Stuart, and me (Josh). Not pictured: Zaynab, who’s taking notes behind the camera.

TWU Class of Monsoon2006

Originally uploaded by josh.ev9.

We did it! Check out the ThoughtWorks University class of Monsoon2006, just post-graduation.

I know, I know. You’re all going to scold me, I’m sure. I haven’t blogged in a while, and you, my ever-patient readership have become quite used to me not spewing out any of the drivel that you’re used to seeing on my weblog. I’ll try to do better. I really will.

The past few weeks have been intense. Last week, the 5th week of ThoughtWorks University, the Analyst team had a number of late nights. We carried out a ThoughtWorks Quickstart, a short and intense period of analysis. I think these generally take a few weeks or perhaps a month, but we only had one week. We created over 40 stories, with detailed narratives, as well as awesome lo-fi and mid-fi prototypes. Of course, we also carried out some Usability, which solidified a lot of our ideas and interface designs. All in all, our “customers” (who were really just a few of our trainers) seemed happy with our results and we were hurdled into a frenzied development week that has been taking place over the past few days.

Development has been CRAZY! It turns out that we completely overestimated our velocity when we created our high-level release plan. We kind of knew this when we set out on the week, but I don’t think we realized the resulting implications of such an overestimation. Having to tell a client that you’re behind schedule, and then having to do it again the next day (and then again the next day) is just plain ol’ tough. Even if the “customer” is really just a trainer who’s posing as an unhappy client.

Still, the learning experience has been great. Tomorrow we’ll hopefully have some sort of release, then we’ll graduate from TWU. What a journey. So fast, and so educational, in oh-so-many ways. What a journey…

I was inspired this evening by this post on Creating Passionate Users. It reminded me of one of my favorite phrases from all of graduate school:

Design Like You Give a Damn.

Don’t just think about the design you should be doing. Actually do the design. Actually care for the people you’re designing for, and help them find the solutions they’re looking for. Like Kathy says, this is a really “Duh” thought, but are you REALLY doing it? I like to think I am.

The infamous poseOriginally uploaded by josh.ev9.

Sure, I could have posted one of my more skilled shots of the Taj Mahal, but I did not. Instead, the infamous pose.

This weekend a group of us went up to Agra, via Delhi, for a trip to the Taj Mahal. That’s the start of the story. Let me skip quickly to the end, for your delightment.

The Amazing Race

On Sunday afternoon, a number of people in our group received text messages announcing that Air Deccan, with whom we had booked our flight tickets, had cancelled our flight back to Bangalore. “Wonderful,” we all thought. After doing some work to reconcile the situation, we figured out that we had two options:

1. Fly back on the first flight in the morning and get back to Bangalore at 9:30. Our classes start at 9.
2. Receive a refund for our tickets.

Let me set a little more context. This weekend, we were travelling in supreme style. Let’s just say that somebody knew somebody, which means that the 9 of us had a caravan of vehicles and a police escort. That means when the light on the street says “red,” we continue on…no stop. Still, the traffic in Indian cities cannot be understated. It is dead slow.

Ok, so back to the flight situation. We decide that the best thing we can do at this point is to get to the airport as soon as possible. Tell that to a group of drivers in state-owned vehicles, here’s what they do: look around at each other, grin, and drive like hell. It was amazing.

You know those movie chase scenes where there’s a car running all over the place at top speed, on the wrong side of the road, with more cars chasing behind? That was us.

Needless to say, we got to the airport relatively quickly, and eventually tricked the system into selling us tickets for only $100 more than we had paid originally (compared with $400 if not tricked). Good stuff.

The Taj Herself

The greater part of the weekend was spent looking at tombs, forts, homes, and other old, old stone buildings. The Taj Mahal was amazing, and perfectly symmetrical. The things the designer of this building thought about was amazing. For example, the turrets on the corners are all angled out 5 degrees, so that from far away they look straight.The most impressive thing about the Taj Mahal (and the other historic buildings in Agra) is the fine detailed stone carvings. There is no paint on this building. Every time you see color on the building, you must realize that that color has been engrained in the skin of the building, not painted on. That means somebody has chiseled away the area that needs color, and implanted stone that is the needed color. Multiply that by a factor of huge. I call that impressive.

The Taj Mahal, and all the other sights of Agra are highly recommended. The expectation is true: if you come to India, you must go to the Taj Mahal.

Awesome Accomodations

I won’t go on too long about the accomodations, let’s just say those were taken care of as well. We stayed at the Mughal Sheraton, a 5 Star, no holds barred facility. It was quite nice…especially the beds (a haven of softness after nights and nights of hard hard beds).

Alright, I’ll end the oozing there. Here’s the point: if you come to India, to to Taj Mahal. (And have somebody upgrade your stay…by the way…we owe a big thanks to the person who upgraded ours, but I’ll protect her anonymity here, either way, Thank You.)

When I came to ThoughtWorks University a little less than a month ago, I set as my main goal the task of discovering what kinds of User Centered Design practices were occuring at ThoughtWorks, and how I could help progress those tasks. After two blazingly fast weeks of class, I’ve learned a lot, hopefully taught a little, and have come to this point surprisingly impressed at the user-centric ideas that shine through in the lessons here at TW, and possibly in Agile Development in general.

Many of the analysis techniques in use here align closely with a number of standard HCI practices. For example, last week we were taught a lesson about how to best gain knowledge about the organization, business process, and/or needs of the client. The lesson reminded me so much of Contextual Design, an analysis and design methodology that has been around the HCI field since the early-1990s, which makes it quite ancient in the field. I was completely staggered to learn that the lesson was not based on CD, and even more surprised to learn that the trainer had not heard of it at all.

Further lessons have discussed External Cognition (pdf link), process modeling, and interview techniques that would make most HCI-designers proud. We’ve also learned about how to incorporate Personas and Scenarios into our analysis work. Not to mention the fact that user stories, which guide the development of specific software functionality, are based directly on user needs (as mentioned earlier).

The fact that these practices are built directly into the system is uplifting for an Interaction Designer like myself. Now, I take it as part of my responsibility to point out when these known techniques are used, teach people their formal names, and discover how we can further leverage their strengths, while being aware of their weaknesses. Of course, it’s also important to add new tools to the TW toolkit, which I plan on doing.

So far, though, I am impressed by the User Centricity of the processes here at ThoughtWorks. Score one for the users.

As noted in my first agile worry, I am often scared that features of a given piece of software will be built based on reasons other than user needs. Yesterday I learned that story cards are, indeed, quite user centered.

The format we learned for creating a card is as follows:

As a [ person ]
I’d like to [ action ]
so that [ reason for action ]

This card is used as a discussion piece with clients, and is eventually used by developers to create particular functionality.

What excites me most about these story cards is the fact that right at the start, a person is identified for whom the functionality is important. This means that one cannot simply create a story for a feature that is “cool,” nor one that is simply unneeded. Also, the cards are to be specific, so the user cannot simply be some general party involved, such as “customer,” “client,” “computer user,” etc. User needs are heeded in a feature-by-feature manner, so the people who will eventually use the software simply cannot be ignored.

Now, there are still a number of ways in which a particular piece of software can veer from user-centredness. A bad interface to a set of features, for example, will make all other attempts at user centered design moot. Also, simply because the features of a piece of software have user needs in mind, the package of features may be counter to this spirit. Among other things I hope to learn at TWU is how to apply standard User Experience Design principles to Agile Methods so that the process and product are excellent for the builders and users of software, respectively. Hopefully what I will learn in the coming weeks (not to mention months and years) will help contribute to the growing knowledge in these combined fields.

For the moment, I am excited about agile…keep it comin’.