Monday…Another week, another observation…

Something I’ve noticed while working with technology is that remaining a moving target is a good thing. Take Apple, for example. Back in the day when the iPod was all the rage (despite that awful, awful clickwheel), other manufacturers immediately jumped in the ring with their portable MP3 player offerings, like Samsung, Rio, and Microsoft. So, by virtue of being first to market, Apple exposed the consumer want/need for portable MP3 players and also the weaknesses of the iPod for exploitation by competitors. But then Apple evolved the iPod product line–nano, shuffle, touch–all of these came over the following years accompanied by general improvements in hardware and advances in the programming languages used to support the devices’ functionality.

Basically, as the lineup of Apple products evolved so did the customer’s experience. This happened on two levels. First, there was just the validation that came with owning an Apple product. By owning an Apple portable music player, you were seen as someone who was in on the latest-and-greatest technology. And as a result you were someone who probably became a bit more fluent in the changing interaction language of portable devices that Apple was driving. The interactions that came with these devices were the second part of the evolved experience. These interactions were more physical. So, instead of interacting with menus through some thingy you probably couldn’t name on the outside of the device, you were randomizing song order by shaking your device or directly tapping the item on your device’s screen. Such interactions were novel, cool, and gave users an increased perception of control over their device.

The combination of how Apple played into the perception of their customers and the way they evolved their products made them stand out even more from their competitors. In fact, it even made some of their competitors look silly by comparison. And now, everyone is trying to do what Apple did. Some companies are doing a good job of evolving their devices to compete with Apple, but they are lacking in how they validate perceptions of their users. Other companies have done a great job of offering a good user experience and creating a validated perception of their users. For example, think of owners of Android-based phones vs. iPhone owners. Both groups of owners can claim pretty decent user experiences (depending on what they do with their device). Both definitely perceive themselves in certain ways, and the companies that market their products to each base do what they can to support those perceptions. As a result, there is some pretty heavy competition between Android and iOS. But between other mobile phones and them? Not so much.

I’m going to be curious in the coming months to see which companies it begins to hit home that good user–customer–experience can set competitors apart.

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?