Is there such a thing as too much technical knowledge?

When I started my career in User Experience, back before it was called User Experience, I proudly avoided becoming too advanced in my technical knowledge of the product I was supporting. There was a perception at the time that if a UXer became a domain expert they'd lose touch with how user's perceive the product (or at least novice users). We even coined a term for when a UXer would get a little too close to the development team -- "going native". If we caught a UXer saying things like, "Well, if users don't understand shell scripts, they shouldn't be using the product", they were quickly admonished for going native.

Obviously every UXer had to have some domain knowledge, but there was a largely unspoken agreement that we should avoid going too far with it. Bear in mind, when it comes to enterprise software, technical domain mastery is very expensive. For example, my first job was working on DB2 on the mainframe... becoming a domain expert could take a decade. But the issue isn't laziness, it was philosophical -- a UXer should be an expert in design and usability methodologies, not in whatever product domain they happen to be supporting. AND not only is domain knowledge not necessary, it could also be dangerous, because it could cause the UXer to not see usability problems that a non-expert would encounter.

I now think I was completely wrong.

Well, not completely wrong. I still believe that many design issues require no domain knowledge to recognize and fix, and most product designs are so bad that a decent UXer can spend many releases just trying to fix standard design problems without ever needing more in-depth knowledge about the product. In other words, I don't need to know anything about a product to point out that the developer's grandiose tabs-within-tabs-within-tabs design might be flawed.

But at some point you start to hit the really tough design decisions. Where the answers are not obvious, and it becomes unreasonable and expensive to always address those questions with "let's run another usability test." This is where the intersection of design abilities and technical domain knowledge becomes truly valuable. The technical architects have the domain knowledge and they care about the users, but they (usually) aren't design experts and unlike the UX professional, they have many competing incentives. The UXer only cares about the user.

I now believe that technical domain knowledge is one of the most important tools in a UXer's toolbox, and should be pursued with vigor.