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.
because it makes it so easy to mount things like iPods and download all your music to your new computer. It would have been harder on a Windows Machine, and even slightly harder on my mac. Now if I could only figure out how to install Lotus Notes…
Just a question. Feel free to introduce yourselves. 🙂
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.
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:
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 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.
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’.
…a little bit at a time.
So yesterday at TWU we had a session called Analysis in Context, which was (for me at least) exactly what I have been looking for in terms of lessons that I can wholeheartedly agree with. During the session, the “dirty secret of software development” was revealed to us. I’ll release the dirty secret for the whole wide interweb to hear:
Software Development might not be about software at all.
Can you believe it? I certainly can. Now, this is in no way meant to put down all those people who spend many of their waking hours writing code. I just mean to underscore the fact that software users don’t want or need to use software just for the sake of getting code to work…they just want to do their thing. People want help working on the things that they enjoy working on, which may or may not have anything to do with a computer.
Writing good software requires good research. One really has to figure out the nature of the problem at hand. It’s not about what the client or user wants, it’s about what they do.
As of today I am a member of my second blog aggregator. The first was Planet Informatics, the place for all thoughts Informatics. I’ve been welcomed now by ThoughtBlogs, the blog aggregator for ThoughtWorks, my new place of employment.
Yesterday’s article was commented heavily, and the responses were amazingly insightful and positively stated, even for an (it turns out) somewhat uninformed article. Thanks to all you ThoughtWorkers out there…you all make me excited to be here. 🙂
So we’ve started delving a little deeper into Agile Development today at TWU. Today we discussed the balance of quality and timebound delivery, as well as iterative software development and adaptive planning. Below I’d like to discuss an issue that is near and dear to my heart, an issue that really worries me about Agile methods, or really any kind of development that advocates the writing of code at an early stage.
In an Agile project, it is likely that a development team begins to write computer code nearly immediately when starting a project, or at least that’s my perception. By immediately, I mean to say that code is created within the first week of the project, if not the first or second day. Meanwhile, a team of Analysts goes and studies the work processes to help the customer figure out exactly what kind of software will be needed. I’m going to assume that at an early stage of a project, the development team makes some assumptions about what will be needed, and commits some ideas to code before they are sure that it will be needed.
This, for me, is where the problem begins. Whenever computer code is created for its own sake, or without proper research, there is potential for the developer to become married to their code. Here’s a scenario:
The team comes to a work site and meets with the client, who has asked that an internal system be created that helps employees communicate with each other, despite the fact that they are distributed around the world. One of the developers immediately thinks of a *great* feature: real-time chat. In the next few hours, he creates a web-based chat tool that can easily be plugged in to a system. He is really excited. This is something he has wanted to try to do for a long time, and finally has had the opportunity to do.
Meanwhile, one of the analysts has been chatting with some of the employees and realizes that all of the collocated employees in each office have no problem keeping in contact with each other simply through face to face communication. The problem, however, is that employees who work in different locations also work in different time zones, and are rarely ever working at the same time. Logically, this means that real-time chat is not a feature that will improve the communication system.
Now we have a real problem. Our developer has fallen in love with an idea, has created it, and will likely be reluctant to let it go. The analyst has evidence that the feature is not needed, and requests that the tool be removed. Now what? Is it an interpersonal problem? Will the developer take this personally? What about his precious time that was spent creating the tool?
Since the feature was created before the development and analysis teams really understood the nature of the design question at hand, it ran the risk of being unneeded. In this case, the tool turned out to be unneeded. The developer may take this event as a war story about “that time the analyst stole the glory and made him remove the best feature.”
But what about the users? The users don’t need it…so why code it? This is just one of the things that bugs me about Agile…code is created so early. Maybe I’m exaggerating the story a bit, but still, nobody likes to throw out work, right?
Maybe some of you agile experts out there can shine some light on the subject and help your soon-to-be peer clear some things up… 🙂
