Just wondering aloud about which departments in your organization employ Human Factors / Usability / User Experience?
In my experience with business organizations, "User Experience" (UE) professionals are typically brought into one of 3 organizational silos:
1) Information Technology / Product Development -- UE professionals are assimilated into development teams, are heavily focused on a single product, and those with good technology skills survive.
2) Product Management -- UE professionals contribute to the shaping of a product in early stages, but have a tough time getting support from development teams in follow up and monitoring activities. Good product managers are a UE professionals greatest ally.
3) Sales -- UE professionals are called in to support a variety of needs (such as justification behind product claims), but their tenure is short-lived.
This is gross oversimplification, as there are some blurring lines and responsibilities, but for the most part I've unfortunately seen these roles often pigeon-holed into organizational silos. This means that if the UE professional only works with one department, (s)he gets much less than half of the exposure they need within the organization. The lack of crossover severely limits the organizational insight the role requires.
Your mileage may vary. Do you agree with these categories? Are you or your UE professionals crossing organizational boundaries? If not, what can you do to hald change this?
Sunday, June 15, 2008
Subscribe to:
Post Comments (Atom)
1 comments:
Brad, this is an interesting categorization and I suspect you are correct. However, I feel quite strongly that the best use usability professionals will be the technical ones. I hold this view for similar reasons that I believe an architect should code or that the DBA should not be a separate entity.
My view is that all on a project should all be part of the development team and all produce code. As with the architect who is not engaged, they can draw great pictures and postulate how great it can be. They are however, often out of touch with reality and are don't take responsibility for delivering software.
Post a Comment