Tom Allison — Fri, 07 Jan 2011 20:43:03 GMT

@ Anthony: really great article! Just the kind of balanced and experience-derived take that makes Boxes & Arrows such a great professional forum.

(also @ liliskirman)) Have you heard of Menlo Innovations (http://beta.menloinnovations.com/)?

They are an Agile (XP) and UX (“High-tech Anthropology®”) custom software shop in Ann Arbor, MI that has been successfully wrangling with all of these issues since *2001* (do you know of anybody else that was trying to do this that long ago?). I worked with them for a couple of years before bouncing across the pond (Germany) and found it a deeply satisfying way to make software. I’m very hopeful that this model of development will catch on much more widely. Articles such as this one which attempts to clearly map the terrain are a big step in that direction. Thanks!

In my experience, it does tend to be developers who are particularly drawn to Agile—and it has all to do with the battle lines between them and business sponsors, but slowly, as the practice matures, it’s being recognized that simply taking a willing user hostage for the duration of a project may not be the best way to cover the UX role ;).

@ Michael: I’ve got to say that while I not-infrequently wanted to yell at my computer screen while reading your posts, I do very much appreciate your taking the time to spell out your position so thoroughly. “Design” is an over-burdened word (here in Germany, for example, it nearly exclusively means “Graphic Design” and given how much half-English/half-German one tends to speak in the context of software dev, you can imagine the confusion when a word that is not entirely clear in English, means yet something else in the native tongue). I think we can actually all agree that the intellectual and creative process we native English speakers tend to mean when we say “design” takes place at every level of a software development team (especially if they’re doing OO). To the extent that there’s anything innovative going on (and every new project demands some innovation), somebody has to make sure it fits with surrounding patterns and will function across all the imagined contexts for which it is intended – that is, somebody has to design it. That happens at many different levels—from the size, type, placement and labels on the UI controls to the deepest level data repository. If anywhere along this chain, the models used don’t map to those in the mind of the targeted end-user, the thing just doesn’t work, period. Yes, the deeper layers have a grandeur all their own that is appreciated by far too few (though competence on this level is certainly well-compensated—so it’s some other sort of “appreciation” we’re talking about…), but how exactly do you propose that the designer of that deepest layer should map his design to the model in the head of its eventual end-users? I’m sure all of us have had experiences with databases that were wicked fast and theoretically sound, but that spit out nonsense and/or refused to take our input as we normally conceived it. And, unless we’re talking about a team of one, it’s not only important that the db designer know that end-user mental model, but that her understanding of it is shared with everyone else on the team, including the sponsor. To that end, somebody is going to have to go out and meet the putative end-users “in the field” and get a deep enough sense of their goals and desires to represent that back to the team. I don’t know what tools you would propose for this process, but in my experience that is best accomplished by describing the persona for whom the system is to be designed and following that up with the design of the initial contact points between the user and the system (the UI). From there, those whose design and other skills are more in the area of modeling abstract, logical spaces and articulating them in some version of machine code can pick up the torch and carry it forward. If your plan is to make software tailored to the end-user, then you’ve got to have a model of said user in mind. Absent an articulated persona, that role will be filled by any of a variety of agents, and likely not the same one for any two members of the project team (to say nothing of the sponsor – who knows what exactly they have in mind!). Such situations often do not end well. It doesn’t have to be that way. (Of course, if you are a dev team of one-three people and you are all similar and designing for people just like you and you don’t develop any idiosyncrasies during the project based on your “inside” perspective that won’t be shared by your intended users, then, sure, it would probably work out – without any more than the usual software dev project pain.)

My sense – yes, we are all designers. I don’t’ mean that trivially. It’s important to remember. Further, for a project of any size, one brain (actually I prefer two, and paired) should be modeling and facilitating the selection of a targeted end-user based on first-hand field observation and interactions, while another brain (or, again, a set of brains, working in pairs) is modeling the mechanisms that can empower that end-user to achieve the goals that are motivating her interaction with the machine, in the first place. And, of course, this all has to happen in a project context given its contours by clearly articulated business goals (teasing out clear statements of goals and posting them where everybody can see them is something UX folk are quite good at ;)).

Hmm, do I have to put an “End Rant” tag, here, now?

Tom Allison — Fri, 07 Jan 2011 20:43:03 GMT

>> “They are an Agile (XP) and UX (“High-tech Anthropology®”) custom software shop… ...since *2001* (do you know of anybody else that was trying to do this that long ago?).”

The only other contender that comes immediately to mind (for UX + Agile) is ThoughtWorks, of course, but I’m not sure when they added UX to their XP—was it from the beginning (in terms of XP that would be 1999, I believe)?

I don’t want to have my history way off, here—I’d be interested to know if Menlo has bragging rights in this dept…

Boxes and Arrows: Comments by Tom Allison