All sorts of automated tests happen on projects at ThoughtWorks. There are Unit Tests, Functional tests, GUI tests, and others that make sure the software we’re building runs well from the most back-end function all the way to the user’s interface.

One thing we don’t test, however, is where particular elements land on a screen. We make sure that the drop-down box you were expecting to be on a given page is there, and that it holds the values that should be there, but we don’t make sure it lines up right next to the label that explains what it is for.

I’ve brought this up a few times while on projects, and developers have told me that we don’t test for screen position because we just can’t. I wonder how true this is.

When it comes to visual design, the placement of elements on an interface does matter. When doing a visual assessment, it’s important to me that all the pixels on the left-hand side of the screen are aligned to a grid line. It’s important that that drop-down is placed right next to its label. It’s vital that the company’s logo is always on the top left. And even on a low resolution monitor, this input box needs to align with the others. On and on…there are plenty examples.

I understand that testing for screen position is a hard problem, and is impossible with our current automated testing tools. But is it really impossible altogether?

Hey all you developers out there, weigh in with your opinions. And for anybody else out there…how important would a tool that does this be to you?

One of the ideas that I try to progress when I join a new project is that much of my job will simply be about exploring options. If I do my job right, more than half of the options will end up in the trash bin, so that’s to be expected. Many people have a hard time with this. Questions I receive from clients and coworkers: “Why would we work on an idea that likely won’t get implemented?” and “Why would you bring up a functionality that isn’t even close to something that’s on our story list?”

The reason is that in order to get to a great design, we need to start with options. Very rarely is the first idea the best, so we have to work through early ideas in order to get to better ideas.

This is a common, fundamental thought in the world of design. The car you drive is the result of thousands of hours of clay modeling. A given advertisement in a magazine has likely been created and recreated 100s of times (in pencil, ink, and finally by a series of printers). You think the final design of the iPod just fell out of somebody’s head? They sketched and modeled that thing for months before anything physical was created.

Martin Hardee, who works and blogs for Sun Microsystems, wrote a great piece about working through visual design options. He describes how their design team walked through a series of Comps (which I learned was an abbreviation for “Compositions,” but Martin says it means “Comparatives”) in order to get to a final design.

Compare those little Comp images with the way the page looks today. Pretty different, no? That’s called iteration. Not the same kind of iteration that they do in XP, but still a similar idea. Let’s not get into that though…differences in type of iteration are for another post. Either way, I think the design looks good, and there is evidence of some ideas progressing into the present day, while others were cut right from the start.

If you’re responsible for the visual design of a website, piece of software, or really anything, try your hand at creating a few options to choose from. Even if you just sketch ideas on paper, your design is sure to improve. Giving yourself options is a great way to get to a more successful visual design.

One distinction many people make when defining a design project is whether the design will be another evolution of an existing technique, set of tools, or technologies, or if it will be a revolutionary implementation. This decision is most often made implicitly, generally without any direct thought about revolutionary design…the creation of ideas that enable a new paradigm of designed interactions.

Such was the case in the mobile phone industry until last month. For years we had seen absolute crap when it came to the design of mobile phones. Motorola, Nokia, LG, Samsung…they’re all guilty. Each of them simply evolved their phone solutions, simply adding functonality year after year, rather than assessing how users’ experiences might be enhanced as technology evolved.

Now, Apple has designed the iPhone, which rethinks how people can interact with their mobile phones. Apple didn’t simply sit around and design the next thing that makes sense…they did the leg work of thinking how the mobile phone could be simplified, how specific interactions could be made easier, how to make functionality make better sense.

Why was Apple able to do this? Why is it ok for them to rethink the design of the phone, while all the other big names just sat around and evolved? I’ve got a few ideas:

1. They had nothing to lose.
2. They’re not afraid of losing a few customers to excite many others.
3. They realize that good design doesn’t necessarily cater to everyone, but works well for those who are meant to use it.
4. Design is a first class citizen at Apple.

We should all take a lesson from Apple and their iPhone. Sometimes playing it safe, and simply evolving, is not the best progress. Sometimes it is ok to shock and awe…when the end product is much better than anything else available. We need to rethink our interactions with customers, and not necessarily just stand by the same ol’ same old, but rethinking the way the computer can enhance human performance.

There’s just something about working with others that makes the job so much more enjoyable. In many agile development frameworks, the idea of “Pairing” prevails as a key concept. When pairing occurs, two developers work together to progress a single user story, working together weave code into coherent, valuable functionality.

There are many reasons why this makes the code better. Sure, all of a sudden you’re using two people to do the job that is more traditionally done by one, but cleaner code, a sense of mutually owned work, and nearly interruption-free coding (you can’t chat with your friend on IM all day if there’s a coworker looking at the screen as well) make it worth it.

Yesterday it struck me, though, that there’s something else about pairing that makes it all the more powerful of a concept. Now, I’m not a developer, but us non-dev types like to pair on our work sometimes too. Yesterday I was working with a new ThoughtWorker (who’s in orientation as we speak) on a ThoughtWorks-led open-source side project that you’re all soon to hear about. As we argued over mundane details in the UI mockups we we had created, something struck me that hadn’t struck me in a while:

This stuff is fun!

Simply riffing with someone over why a particular UI element will or won’t work is amazingly interesting to me…who knows why. Either way, my point is that not only is Pairing all of the things I mentioned above, but with a good pair work is so much more interesting and enjoyable. And, as I’ve ranted about before, all workers should be able to enjoy the work they are doing.

Here’s to working together, and to making ThoughtWorks all that much better of a place to be.

Friend and colleague Jeff Patton floated an idea a few weeks ago around the thought that there are 3 types of User Experience Professionals: Before-, During-, and After-People. I think this is a brilliant way to characterize UXers…simple and to the point, with no big-giant-confusing-wordiness. Of course, all the qualities of these different types of people should exist in every User Experience Pro, but naturally we’ve all got our strengths and weaknesses.

So what kind of User Experience Professional am I? In true self-report form, I’ll this is how I categorize myself at this very moment:

It’s important to note, though, that I don’t intend for my pie to look like that forever. I’ve got big goals for my talents, and most of these goals reside in the “During-people” stage. As of now, I’ve got alright Graphic Design skills, but I can tell that they’re still somewhat raw. One day, I hope my pie looks more like this: Of course I think the “After-people” part of UX work is important, and I’m pretty highly trained in that area, but I just don’t find it all that interesting. I really enjoy being part of the Design side of UX, as opposed to Evaluation. But that’s just me.

Hey all my User Experience friends out there. What does your pie look like? What would you like it to look like? Oh yeah, and, what do you think my pie looks like?

In response to me beaming about my job, Kevin wrote:

Would you say that you are doing all the things you were trained to do at the School of Informatics?

I got to see Matt and Apurva over the weekend, and one of the things that came up was how little their jobs resembled what we do. Apurva took a job that doesn’t really understand HCI, and Matt spends the bulk of his time doing wireframes.

I know you took an extra course, essentially, when you started your job, but where does the School of Informatics training fit in?

Well, I think I should respond to that. I’ll take them a paragraph at a time…

Would you say that you are doing all the things you were trained to do at the School of Informatics?

Kinda. I’m doing a lot of stuff that I was trained to do at the School of Informatics. Still, I’m doing my fair share of wireframes, lo-mid-hi fidelity prototypes, and the like. A lot of what I do simply has to do with communicating exactly what I am trained to do, so that I can go forth and do it. This takes a lot of trust from my coworkers…generally when I explain my game plan at the outset of a project, I’ll get strange looks. By the end, though, so far it seems that people think the results are noticeably better than the inputs.

The most invaluable part of my IU HCI/d education has been the “d.” Without a doubt, the tools that earn me the most gratification are my Design sensibilities, which Marty, Eli, Erik, Youn, my Graphic Design courses, as well as all my classmates, helped me to find. Ideas like Computer Imagination still inspire me, but a lot of our clients generally aren’t ready to think in terms of “pie in the sky” ideas…they want grounded results, ASAP. As I gain experience, I hope to be a stronger advocate of Computer Imagination in my workplace, but for now I’m simply here to make my clients & their customers happy.

I got to see Matt and Apurva over the weekend, and one of the things that came up was how little their jobs resembled what we do. Apurva took a job that doesn’t really understand HCI, and Matt spends the bulk of his time doing wireframes.

Look, I’m not saying my job is perfect. There are times when I get fed up with technology-centered thinking, and am frustrated and feel like an outsider. The difference with a place like ThoughtWorks is that the people are really open to new ways of thought, especially if they’re backed by some academic rigor. Many people here don’t necessarily understand HCI, especially the intricate differences between Usability, UI Design, Interaction Design, and the like…but my coworkers have been very interested to learn about them.

Just a few weeks ago I taught a room full of about 30 coworkers and clients about User Centered Design. They were psyched to see how easy lo-fi prototyping and basic usability testing can be, and some of them planned on carrying the ideas out on their own projects. The people around me yearn to learn, and that makes my job somewhat easier.

There have been lows though. Like when I was told I should go read the Windows User Interface Manual. And when people have kurtly told me to “make the app pretty.” It’s at this point that I know that I have my real work cut out…not only do I have to do what they ask for, but also get them into a state where they can be ready to learn about what an Interaction Designer is meant to do. Yeah, I guess a lot of my job is just about being accepting of opinions and doing some work that I don’t love in order to open the doors to the stuff I love to do, like talking to real users.

Hey Matt & Apurva (and others) - if you want a piece of this action, let me know. I can hook you up with a recruiter.

I know you took an extra course, essentially, when you started your job, but where does the School of Informatics training fit in?

ThoughtWorks University was a fantastic educational experience, and I am so glad I was able to take part in that. The most important part of that experience was meeting and hanging out with my new coworkers from all over the world for 6 weeks in a foreign country. The next best part was learning about the techniques that ThoughtWorks uses with our clients, which generally fall into the category of Agile Development. Now, the somewhat highly structured Development methodologies like the ones that fall under the category of Agile are far different from Eli & Marty’s PRInCiPleS, which encourages free thought…but there are still many overlaps between the two. Being able to think above standard practices and processes served me well at TWU, and I think I have Informatics to thank for that.

You can’t forget the 7 Themes. Those come up all the time.

My graphic design classes in the School of Fine Arts were also invaluable. I highly recommend those to all HCI/d folks.

Above all else, the School of Informatics gave me the confidence to walk into a growing company and feel like a leader in my field. I can talk with authority on subjects ranging from Design to Usability to HCI to Innovation, and on and on.

Finally, there’s a lot of talk around TW about how they recruit and hire the best and brightest. This can be intimidating to many. It hasn’t been all that intimidating for me, though…I’ve been among the best and brightest in the world of HCI/d for the past 2 years…so I know I can hold my own in a room full of brilliant people. (It sounds cheesy, but it’s true.)

What else?

Of course, there’s some stuff that I learned before I came to IU that has helped me as well. I had a degree that said “HCI” before I came to the School of Informatics. Studying the Contextual Design process changed my life at UCSD, and becoming familiar with the literature that has come out of the field of HCI over the past 30 or so years definitely helped. So yeah, some mad props are also in order for my other alma mater.

So yeah, I hope that answers your questions, Kevin. And I also hope it wasn’t overkill.

So, Marc says User Centered Design is compatible with Agile. I think I agree, but with a caveat or two.

They’ve Got Different Foci

The User Centered Design methodology is based on one simple concept: the person who will eventually use the system should be the focus of the design process. There are many processes, techniques, and tricks that flow from this principle, but they all take the user as the core element to be studied in order to come to a design specification. In my studies, I haven’t come across any examples of a UCD process specifying exactly how the tool should be built, rather, the design process specifies tool that is to be built.
In contrast, Agile methods guide the development of a tool that is being actively specified. XP and its brethren guide a development process, not a design process. Design plus development are made to be together. It has been this way since the beginning of industrial design, architecture, and other older, more standardized design fields.

Agile is what you make it

As much as many Agile backers may think otherwise, I believe there is no standardized Design practice within Agile practices. Sure we create UI prototypes. Sure we work with the Customer to make sure they’re getting what they want, which seems somewhat similar to Participatory Design practices started in the 1970s. But there isn’t much of a true Design practice in most Agile projects, at least the ones that I’ve read about and seen on the job.

I’m not yet ready to give up hope, though. Remember back from the thesis of this entry, I agree with Marc’s sentiments. Agile methods that I’ve seen in practice have been so extensible and open to change (I guess that’s sort of the definition of agile) that I see no reason that UCD and general Design practices can be built into Agile frameworks. In fact, I think we’re pioneering some of these practices at ThoughtWorks every day.

With a little work, and some tweaks in the design and development process, I think we can make it easy to marry the dependable, successful development brought about by Agile methods with the UCD processes that regularly create excellent, user (and customer) accepted software tools. We’re not there yet, but each day we’re getting a little closer, at least within the walls of TW.

I’m not here to help build mediocre software. Quite the opposite, actually. No one should be subjected to sub-par tools, whether they’re using their software at home, school, work, or somewhere in-between.

One of my UCD-minded colleagues pointed out to me last week that often business users are considered a “special” set of users because they’re expected (nay, demanded) to use specific software to do their jobs. If the time & expenses tracking software isn’t usable, there isn’t much an individual employee can do about it. In contrast, home or non-business users have many options when it comes to their software. If a person decides Mapquest just isn’t good enough, the mapper can switch to Google Maps. If TaxCut sucks, TurboTax is just around the corner.

There is definitely something wrong with this picture. Giving home users options is a great thing, but why must enterprise users be subjected to second-rate tools? Just because someone joins an organization does not mean their work should be monopolized by crap tools, right?

So I ask, why shouldn’t all the User-Centered methods employed ubiquitously throughout the consumer market applied to business software as well?

I’m sure the ThoughtWorkers will love this:

Over the last 2 days, I’ve met damn near a million people at my current project. The project has been going on for a few months now, so everybody else knows everybody else, and there’s a constant rhythm that comes from people knowing what they’re supposed to be doing. Everybody works together, and each person (ThoughtWorkers and Client Employees alike) are all working seemlessly together. This is a great thing, but for somebody new to the team (me, for example), it can be confusing.

I want to be able to know who the ThoughtWorkers right from the get go. Have any of the other TWers run into this problem? My solution is to create a ThoughtWorker “sign.” Something that we all know, but is sly enough to keep somewhat secret. That way when we meet we can both flash the sign and know we’re on the same page…or at least that we work for the same company.

Am I out of my mind? Is this totally unneeded? And of course, who’s got a recommendation for what the sign should be?