You and Your UX Department

One of the discussions I hear occasionally from user experience types is how to get good user-centered design into actual products. Most products come from companies whose core competency is something other than design; they are product or software or finance-centric. And that's fine.

A common refrain is, as recently discussed here is that UX should never be a department, but must be ingrained in the company. The theory is that if it's one department then no one else will bother to work on it.

There's only one problem with that concept: no one but us UX folks have this discussion. There is no reason good design, or user-centered-anything will occur without an organizational structure to guide them to it. You can be sad about this, but I've learned to live with the truth that this is how corporate entities work.

That's not really a bad thing, though. People do like to work together. Policy and procedure get followed, at least in principle, so your activities will be performed. And when you understand the systems, you can work within them. I have been contacted a lot (when I worked at a Fortune 50 company) by people who had only a vague notion of what our team did, but had heard good things about us from others who had executed projects.

1. Exist – You have to have a department. However small it is, make sure it's a single team with a name that means something. If you have a choice, and you might later on as your company reorganizes itself, where is the best place to be? I am not sure. I suspect getting a C-level team would be good (with your boss, the Chief User Experience Officer) but how likely is that. I've worked in or with teams in Marketing, Product Development, Operations and IT (and probably others) and none were perfect or terrible. But do understand the culture in which you are operating; IT and Marketing have different measures of success.
2. Get in the process – Assuming you are talking about interactive design, software development processes rule the world. Whether this is good, or any process is well-designed, is a whole other disucssion and not something you will be able to influence right away. You need to get in the process, formally. This will take a couple steps alone:
   1. Understand the process – Most people do not understand software development processes. However, most developers don't either, or have forgotten over time. Get some books, hire the right people, and talk to the process managers (they probably exist). You can use the process to your favor if you know it well. Also note, many software processes (though not many web processes) have an interaction design phase, that is just poorly understood.
   2. Sell your position – You need to be able to talk to VPs, product managers and process boards. You'll need all the knowledge of why UX is important, why this will improve development, why this will help the company bottom line and be able to do it off the top of your head. You might not be able to do this; when building a team, often the manager is a key job for the core designers to find. Get someone who can do this for you.
   3. Build the process – Once a line item is accepted as being your responsibility, you aren't done. There are still options as to how it gets worked, and those will determine how much influence your design actually has.
   4. Defend your step – You have to keep working as you said you would, maybe even push the boundaries, and explain the value all the time. Being complacent or skipping out of some projects can cause you to be left behind, even if the official paperwork says you have a seat at the table.
   Getting signature authority is best; no project can proceed without your department's approval. But this will not happen day one, and with it comes extra responsibilities. Can your team support these efforts with it's current headcount?
3. Market yourself – As implied above, it's largely political. You need to sell your job role, and keep selling it over time. Teams change, processes and priorities change and new products emerge all the time. You need to make an active effort to market the value of your team all the time. This freaks out a lot of people, who think marketing internally is evil, and confuse marketing with advertising. Look up some definitions, and think about how you approach product design; expressing core values is not that different for your team.

If you still think this is just cynical and short-sighted, so be it. My long-term goal when at the big company was still to get everyone thinking about user experience (and customer experience, and related topics) and I've seen it start working. Design leadership and examples of how you can help, are good ways to start moving your company in the right direction.

This sounds similar to the groups I’ve worked with in verification and documentation. It’s all well and good to say “Everyone should be thinking about 'X’” where 'X’ is UX, verification, documentation, or some other thing that “real programmers” don’t think has much to do with “real programming”.

Get a department. Get in the process. Get the power. Then (if you can keep the power) the “real programmers” will come to you and say “How can we make this easier so that the process moves more smoothly?”