Compartmentalists, Specialists, and Generalists

Jared Spool just posted an interesting article on the ideal makeup of a UX team . He makes a useful distinction between a specialist and a compartmentalist:

While the former is about having the majority of your experience in a single discipline, the latter is about only having experience in that discipline… . A compartmentalist isolates themselves from the other disciplines around them, not really learning what they do or how they do it. Compartmentalism is bad for teams, because it means you have to have enough work to keep that individual busy within that discipline, and if needs shift or emergencies crop up, their value is dramatically diminished.

I would also add that a compartmentalist tends to make decisions that cause problems for other team members—the compartmentalized user researcher makes design recommendations that don’t meet the needs the business analyst identified previously; the designer designs something that will take $5 million to implement; the HTML coder who transforms those ultra-accessible semantic forms into screen-reader nightmares for the blind.

So I agree with Spool that compartmentalism is bad. But he also says that the main reason to choose a specialist over a generalist is economic; if a specialist is available and affordable, you would hire a specialist, according to the article. But aren’t there times when specialization is a negative for the project? Even if I could afford a specialist HTML coder, business analyst, interaction designer, and user researcher… isn’t there some inherent value in having the same person play one or more of those roles, depending on project size, complexity, or a host of other factors?

I don’t think economics is the only factor.

posted by ted on Monday, Nov 17, 2008 · 7 comments

Project “Soul Searching”

In our jobs, working for the LDS Church, we work on projects that do not generate financial income. This is very different than the corporate world that I’m used to, but also a very good thing. The projects we work on do not generate income, but they do use financial resources of the Church, and the bar is set very high to use those resources in the most effective way possible. This environment requires an extra level of vigilance and “project soul searching” that may not happen (although it probably should) in the corporate world. In this quest for meaning, I’ve been bombarded with questions. The process of questioning doesn’t always get to the answer. In fact, if you’ve got all the answers, the chances are that you don’t really understand the problem. The purpose of questioning is to gain a better understanding of the problem, where your solution fits in, and what effect it will really have on your customers and end users.

• What am I doing?
• Why am I doing it?
• Who am I doing it for?
• Why do they need it?
• Is it really an issue for them, or is it for me?
• Is what I am doing useful?
• Is it necessary?
• Am I really hungry already?
• What is the Issue?
• Why is it an Issue?
• How important is the Issue?
• What would happen if I didn’t try to solve the issue?
• Are there other options for addressing the issue?
• Is there already a solution that addresses the issue?
• Has the existing solution been implemented?
• If so, why hasn’t that fixed the issue?
• What is this isn’t really the issue?
• Is there an issue bigger than the issue I think I’m trying to solve?
• Where am I going to go for lunch?
• Is there a smaller, more focused issue that I haven’t thought of that would be easier to solve?
• What is the proposed solution?
• Why is that a solution and not a new problem?
• What is the objective of that solution?
• Who is going to use that solution?
• Why are they going to use it?
• What is the solution going to change?
• How are you going to know that it will really change?
• How important is that solutions, really?
• Is that solution possible?
• Are you sure that it is not possible?
• How much money do I have for lunch?
• Do you have the resources (time, money) to implement the solution?
• Do you really want to implement the solution?
• Are there situations or circumstances where the solution won’t work like you expect it to?
• Are there other solutions that this new solution will replace?
• Are there new solutions that must be developed because of this solution?
• Is it lunch time yet?

Andy Rutledge makes some good points on this also in his article “Seek Understading, Not Answers”

posted by john on Wednesday, Aug 23, 2006 · 0 comments