Comments on Building the UX Dreamteam

Richard Dalton — Fri, 30 Nov 2007 21:39:45 GMT

I think “personality traits” or more general “competencies” are actually more interesting and important in hiring full-time staff, I would have led with that for part one!

Jamie Owen — Fri, 30 Nov 2007 16:33:13 GMT

What happens when someone in Terry’s position (as team leader) has members of different cultures on his team? How does one mediate the cultural influence on an individual’s contribution to the team? Do the differing values held by a multicultural team mean that there will by more internal conflicts to sort out? For example, does a team member of one culture dismiss the contributions of another (for whatever reason)? Or given the results of user research on a population whose culture is different from that of the design and development team, how does the design impact a business goal aimed at this audience?

Rhetorical questions, yeah—and I don’t have the answers. But I think they bring up realistic issues as technology shrinks the globe.

Terry Bleizeffer — Wed, 16 Jan 2008 20:34:49 GMT

At the risk of over-commenting, there’s another area where I’m struggling, and that’s the distinction between “architecture” and “design”. You touch on this in the section about “Information Architecture” and “Interaction Design” but I’m still not comfortable with it. Maybe I’m just dissatisfied with the term “Information Architect” (I can hear the cries of “blasphemer!” already), but I think there’s a “UX Architect” role that’s also important that doesn’t exist in your list. Maybe Information Architecture is a subset of UX Architecture or maybe it’s something different – I haven’t gotten my head around it yet.

Anecdote: I was talking to an Agile Development evangelist recently who was saying that design is done during Agile milestones in an iterative fashion. I asked, “Okay, but what about architecture? Are you distinguishing between architecture and design, and if so, when is architecture done?” He replied, “Oh, the architecture should all be done before the first milestone even begins.” I said, “Great. Can you tell me how you know when you’ve stopped doing architecture and you’ve started doing design?” And he replied, “Um… no.”

So I’m not alone in my confusion, which is comforting. Maybe an example would help clarify. I would expect a UX architect to be involved in a decision regarding what technology should be used to implement a user interface. Thick or thin client? HTML/CSS or AJAX? Flex or WebForms? Obviously this decision can have a profound impact on the user experience, but I would neither call it design nor information architecture. And skills and experience in these types of decisions can be critical to a hiring decision… whatever the role is called.

Terry Bleizeffer — Fri, 30 Nov 2007 12:00:57 GMT

@ Todd: Are you talking about coding skills that allow a designer to code a prototype, or coding skills that allow a designer to code in the same technology as the product, so that the code can actually be shipped as part of the product?

If you mean the former, I agree with you that this is something else to look for when evaluating candidates. So under Anthony’s “Screening tips” section, I’d want to look for prototyping skills in Visual Basic, HTML/CSS/JavaScript, Flex, Flash, Powerpoint, etc. Heck, I’d want to see real example of prototypes that they’ve created.

If you mean the latter, I agree with Anthony that that’s the exception to the rule and probably wouldn’t be useful in making a hiring decision, because it’s so rare and in many shops it might even be inappropriate. However, I will add that I think this IS a skill that designers should learn. True GUI development is really difficult and I would expect designers to be able to code all the externals from soup to nuts… but a designer that can produce solid, ship-quality code for the final on-the-glass pieces is valuable indeed, and in many cases that technology is not that difficult to learn… no more difficult than it is to become a Powerpoint guru.

Terry Bleizeffer — Sat, 12 Jul 2008 05:42:12 GMT

Thanks for the article, Anthony. As I am in the process of bringing in several new folks to my team, it is a very timely topic.

A couple comments about roles where I seem to draw boundaries in different places than you have. First, I think it’s useful to separate out “usability testing” from “user research”. If we step back far enough and squint, we can say, “They both involve collecting data from users,” but in practice the differences are more interesting than the similarities. User research tends to be done in advance of the release process, or as input into the release process, while testing is done after design (hopefully in an iterative fashion, of course). In other words, user research produces collateral to enable good design decisions, testing validates whether good design decisions were made. In many projects, user research on the next release is being done at the same that testing is being done on the current release, so having one person responsible for both is problematic. Second, user researchers tend to be more experienced in the domain, because it takes quite a bit of experience to understand where the gaps exist, while testing is done with the assumption that the gaps have already been identified. In other words, it’s always harder to find something that’s missing completely than it is to find something that exists but is broken. And third, in my experience the deliverables coming out of user research activities (personas, task analyses, conceptual design) are both different and more difficult to do well than the deliverables coming out of testing activities (reports, defects). Bluntly, I consider a good user researcher far too valuable to spend their time performing testing.

I also think there’s a useful distinction between graphic designers and visual designers. Graphic designer create the building blocks, visual designers put them together. I’ve worked with brilliant graphic designers that seemed to have a preternatural gift for turning a vaguely-defined object into an icon that was both attractive and informative… but had absolutely no skills whatsoever in, say, properly laying out a panel. The opposite is true as well – folks with a deep understanding of white space and grid layouts and visual primacy, but no particular skills in “pure” graphic design (which I loosely define as the art of creating an image). If I need a visual designer and I hire a graphic designer, I may end up disappointed.

Robert Skrobe — Fri, 30 Nov 2007 06:44:47 GMT

Great article so far. I especially liked the bits contrasting IA’s and IxD’s and their crossovers in terms of roles and deliverables (and realizing I do a lot of both currently).

With your section on writing skills, could this aspect potentially bridge several related disciplines? For example, could you lump a content management specialist, a technical writer and a marketing specialist in the same realm, if all three rely on demonstrating a command of their languages and/or ability to craft a particular voice in their work?

Anthony Colfelt — Fri, 30 Nov 2007 01:48:59 GMT

Thanks for the feedback and thoughts. The second part is still not fully baked yet, so I’ll encorporate these notions.

Aynne Valencia — Thu, 29 Nov 2007 18:56:51 GMT

Great post!
I think this also provides a good overview of our job description.
I would also say that business acumen and strategic thinking is also critical.

David Royer — Wed, 16 Jan 2008 20:32:52 GMT

Interesting post, I am looking forward to the second part.

I think one of those less tangible qualities that is very important is a designers ability to reflect. Reflective designers are always improving and learning from previous projects and experiences. I think this is as valuable as any skill listed in this article.

Anthony Colfelt — Tue, 18 Dec 2007 09:43:08 GMT

Todd > I don’t know how common it is to expect interaction designers to code. As a general rule, I think they don’t at the moment. Perhaps the industry will trend that way, but I don’t know. I’m trying to write for the now, however.
Christian > Stay tuned for part II. That’s when we talk about personality traits…
Patrick > Thanks for catching that… oops!
Alexander > This isn’t supposed to suggest you find one person that can do all these things, but rather that these are the skills that are out there. When hiring, you need to analyse what you need before choosing a candidate with some or one of these. The next part will clarify this point.

Alexander Wilms — Wed, 16 Jan 2008 20:32:29 GMT

Imagine this beeing only the first part of the article – thats an impressive list of skills that a dream candidate should bring in. If you are not in the lucky situation of hiring a whole team of specialists you will always have to live with compromises.
One question though – does “hiring” relates to hiring a new person for an internal job or does hiring refer to hire a freelancer? I think there might be differences here – if I am hiring a freelancer I might focus on his ability, proven track record or work he/she has done before. Soft skills may be of minor importance. If I hire a person for a permanent position her/his soft skills or leadership abilities (motivation – Patrick is right here) might be of higher importance – he/she has to fit in the existing team. He or she needs to aquire new skills and “that is the way how its done here” anyway.
In my mind any professional in the field of UX needs to bring tons of patience and a quick mind, beeing able to understand what the customer really needs and to come up with some ideas that create additional value. And she or he must be able to admit that an idea was not so great after all and start afresh.
By the way – I’d liked Christophs statement about the most complex industrial design process – I’ll write that on my wall!

Patrick Lauke — Fri, 07 Dec 2007 18:49:41 GMT

“Finding the right person to compliment your User Experience team”

that would be somebody whose job it is to come in each morning to say “hey guys…you’re doing a great job.”

I’m sure you meant “complement”...

Christian Bogner — Sun, 02 Mar 2008 02:46:02 GMT

I think, you mentioned some important skills which are indeed necessary to build interactive systems. Hiwever, in my opinion, social and communicative skills might even be more crucial than any of these rather “hard” skills when creating systems to fit human needs. Let me explain: what I learned about user centered design was not only that this might be one of the most complex industrial development processes I can imagine but this is also a process that is rich in trade-offs and conflicts, too. Without having members on the team which are capable of dealing with that many different stakeholders, ideas and needs I’m strongly convinced that interaction design will fail.

Todd Walker — Sat, 02 Feb 2008 02:56:27 GMT

Something that seems glaringly missing is any sort of coding or programming skills, for prototyping (barely mentioned under interaction design). I think it’s more and more important that ID folks be able to actually build and tinker to quickly iterate through ideas and see if they are workable. I’d say that’s a more important skill than Graphic Design, though I’d always want that too.

Holger Maassen — Wed, 28 Nov 2007 08:56:06 GMT

Excellent article and a interesting approach – Anthony.
I am working on a related story – UXdesign + planning is not a one-man-show – http://www.boxesandarrows.com/idea/view/13449

I’m curious about your next part / step.