Something I’ve noticed that has gone unchanged all of my years as a UX person is that, when it comes to product development & UX, companies want to know what their users are currently doing. That’s fine–companies need to be aware of the current user experience. And it’s even more fine if the company knows that what their users are currently doing is what they need to be doing, but in many instances I’ve not found that to be the case. So, much of my work has been helping companies to band aid their existing user experiences rather than innovate to repair or improve.

But it is a bit difficult getting companies to understand that, while it’s fine to constantly tinker with things here or there in an effort to fix what’s broken when it comes up, attention needs to be paid to the development of experiences based around what people need to do. Often times asking people the question, “Is this what your customer needs to do at this point?” is met with, “Well, that’s what we let them do currently.” And the discussion from that point goes on to how to develop the same experience in a new package. If I dig further to understand why the current experience is what it is, I usually find that little or no research has been done around actual tasks. So, many times I see companies creating processes based around “We know someone wants to buy a kitchen cart.” But there is no consideration to how people think about certain activites and when they need to perform those activities.

The other sad–and frustrating–thing I have found is, companies are not leveraging their researchers appropriately. Most of the time the researchers are relegated to a lab environment where the methodology is canned: Limited activities are performed with restricted outputs. This gets old and useless very quick. Allowing UX researchers to study what users need is an integral part of product development as, not only will it lead to the creation of a better user experience when all is said and done, but it also saves the company money in the long term by cutting down on nitpicky fixes that cost man hours and development dollars.

Alas, it is that last point that is the hardest to communicate despite being the most important. But it is one worth insisting upon communicating to others. It not only benefits the company overall, but it also keeps the UX team relevant within the organization.

Often times, UX teams are the baseball bats used by business and design teams to batter one another into submission. This is natural: UX research makes it a point to call out the good and the bad in a design, and other teams will hang on these findings to use them as ammunition against one another. At some point this is not the only kind of attention you want to be getting as it makes a UX team seem limited. Whether or not a team can move beyond that depends partly on the team and partly on the environment in which it operates. My personal experience has shown that the more restrictive a UX team lead is, the more likely a UX team is to be perceived as ‘limited’. (And in some instances, the more likely it is that team members are bored and unhappy.)

For instance, offering only design commentary is limiting because the UX team isn’t helping to solve the problems–or even encouraging solving the problems. Offering only design commentary is similar to being a trained monkey: You test a design, report the test results, and give the results to the project team. But what happens after that? What benefit does the UX team offer beyond “10 out of 12 users did X when on Y page?” Not a lot. The next time anyone will think of the UX team after that will be when they need to “prove” or “disprove” something to some other group in the organization. And after a while, project teams will begin to learn that certain things don’t work while certain others do–thereby making the UX team less useful.

So what’s my point here? My point is this: MAKE PROJECT TEAMS THINK. It’s very easy to report what you see in a study, and maybe occasionally point out some vague suggestion for improvement. However, it’s more interesting to start discussions around adapting designs to advancing technology, or revolutionizing existing designs by presenting common tasks in novel ways. As UXers, we should have some basic understanding of recent technological advancements, and be able to talk about what those advancements mean for design and user behavior. We should be fostering innovation if we want to get attention.

Yet this seems to be frowned upon by some team leads. To someone like me, who has worn the hats of information architect, interaction designer, and researcher, this is puzzling and frustrating. UXers should be strong in one particular area, but competent in others if they are to be truly effective as UX people. And demonstrating the ability to work with some reasonable competency in multiple areas–and speak intelligently about each area–is a way to gain the attention and respect of other teams. It’s a way of remaining relevant.

How is that bad?