Thursday, April 28, 2005

ACM interactions: Whose profession is it anyway?

I've just been told that the May/June issue of ACM's interactions magazine is a special issue on "Whose profession is it anyway?"
(If you happen to maintain a subscription to ACM's Digital Library, the magazine can already be found here)

That must be a fun read if, like me, you are interested in defining the practice of User Experience.

I especially look forward to the following articles:
  • Making UX an engaging process for prospective user experience adopters, by Bob Goodman
  • Success with user-centered design management, by Jeremy Ashley and Kristin Desmond
  • The adaptive user experience organization, by IAI president Victor Lombardi
  • and User experience: back to business, by fellow Dutchies Peter Bogaards and Ruurd Priester
As soon as I receive the magazine I'll review these here. That means it may take 6 weeks: ACM's international shipping option sometimes makes me feel they use rowboats...

Sunday, April 24, 2005

T is the new X

It looks like I will be a freelancing UX practitioner for a short time while I'm negotiating with potential future employers.

The question is of course: What services does a freelance UX practitioner offer to potential employers?

Should I position myself as a generalist with 10 years of experience in designing interactive online applications (as I do in my resume) or as a specialist in formalizing processes for user experience teams (the stuff I've been working on for the last four years and presenting about recently)?

As I wrote in UX Generalist vs. Specialist, the good things about being a specialist are:
  • You can do one thing really, really well
  • You can communicate your stuff to others
  • You know when you're no longer needed
Then again, generalists have their advantages too:
  • You can do others things too
  • You understand team members better because you've had their role
  • You are always good to have around

I guess I'm somewhere in between: I like to apply my experience, working with teams on a project's wicked problems, even when they're not directly related to the Information Architecture deliverables I'm asked to create. But I also enjoy it when someone I work with realizes that creating UX processes is my focus and that I will look at the processes in place and most likely try to compare them to models I've implemented or seen elsewhere. I want to be a generalist and a specialist.

I guess I'm happy being T-shaped. But how do I tell my boss?

Wednesday, April 13, 2005

T-model: UX Generalist vs. Specialist

In a discussion I was having with a potential client yesterday the topic of UX generalist vs. specialist came up. I believe guerrilla versions of UX fields can be taught to specialists in order to become T-shaped UX practitioners, the good kind of generalists.

The potential client requested EzGov's help and estimated that he would need "1 UI lead and 3 UI designers for 6 months". Excellent, because that means a serious amount of work. The trouble is, none of our team members have a business card that says UI Designer.
The set of activities required ranged from "gathering requirements", through "expanding visual design guidelines" and "preparing and managing usability tests" to "creating HTML prototypes". We quickly identified 3 to 4 EzGov job titles that together covered all the skills requested: information architect, visual designer, producer and probably system analyst too. At EzGov we are specialists, not generalists. Now, is this a problem?

The client may see this as a problem: If he hires 4 UX team members he needs to first understand the specialisms and then decide what to ask from whom. Also, with more specialists more handover activities are required, introducing room for error and delays. Finally, instead of the exact 4 members for 6 months he might see 6, 7 or 8 people walk in and out of the project, each requiring some degree of ramping up and assistance in e.g. getting to know the people, getting access to project documents or even getting access to the building.

Of course we will reply with the argument that the people will be there only when they are needed improving their efficiency, and of course he is getting trained specialists, drastically improving the quality of the work. Also, since we are used to working together as a team, our handovers will be smooth.

I would say that there are two ways to look at generalists: The negative way is to say that a generalist is equally bad at everything and there is nothing he can do really good: he is shallow all the way. This could be said from someone who has at best has read a series of introductory books in our area and has designed and developed a small number of say, websites.
The positive way is to say that a generalist has broadened his horizon from initial deep knowledge in one area, gained through training and experience. This could be a formally trained visual designer who was given the chance to develop information architectures for interactive web applications under the guidance of an information architect mentor.

When I applied Jakob Nielsen's definition of guerrilla usability to information architecture (in A piece of IA pie) I must confess that I had the negative view of shallow generalists in mind. But of course Guerrilla IA can be taught to specialists in other areas, aiming to create T-shaped UX practitioners. That is what we have been doing with our visual designers, producers and system analysts too. That, plus mentoring, reviewing each other's work, lunch & learn sessions, and more, but teaching guerilla IA tactics helped.

In the end, what turned out to be really helpful to the client was the fact that we had documented our process and deliverables, and that in the introductory meeting I could show the client a clear overview of our way of working: at EzGov we have spent the last two years identifying and documenting user experience deliverables as well as the skills required to create them. The members of my UX team have different backgrounds and each contributed to the whole. And even though we have documented these deliverables in considerable detail, collected examples and created templates for everyone to use, we each have our specialty area but can function as practitioner in the other areas too. We are all T-shaped UX pratitioners.