It’s pretty hard to believe that I got my first job in User Experience six months ago. As I reflect on these six or so months, I have found that there are a few topics my mind has been fixated on. This is the first in a series of posts that will talk about my first lessons learned in my job as a UX generalist.

UI and UX are not the same thing- something that countless other blogs have said time and time again. The truth is that in an enterprise of thousands of people, your visible output is predominantly your interfaces. As a result, many projects I end up seeing are UI updates, reskins, and the like. But I've found that even though a large portion of my day is spent in Axure, Keeping a wider view of UX allows me to add value through the invisible areas without any real recognition that it's going on.

I recently had a project that was handed to me as a straight reskin. While a reskin would have been easy, I discovered very quickly that the process behind the interface, and the use cases for the system I was to reskin were not well defined. I did some of my own research and found that a full quarter of the interface was not necessary. I came back to the team with the research, excited because I was going to be able to save so much time for some very overworked associates…. And was stymied because it was outside the scope of the project (even though it didn't make sense to have in the project in the first place).

I couldn't believe it. I come from an academic background… when you show good data in academia, the idea is that change can begin to happen. And now, I'm in the professional world, where creating efficiencies is supposed to be a big deal. But when I show valid research that suggests "hey… maybe this isn't a great place for that function…" I am told that it's not my job to look for these efficiencies.

I don't want to sound like I'm complaining. Everyone has a lot on their plates, and I understand that raising new issues can be perceived as additional work.

How did I solve this? Well, it's still in progress, but my strategy so far has been to create two versions of my prototype- one with the research applied, and one with it not applied. I have kept the project team in the loop to show what it would look like both ways, and the team agrees the research backed method works better.

I don’t know whether my recommendations will be implemented, but UX professionals have to be crafty sometimes, and this was a good wake up call in that department.