Janet Six over at UXmatters posted her latest “Ask UXmatters” article. This time it’s about building UX teams. She featured a bunch of my thinking on how to prepare and change organizational cultures for more effective user experience implementations. Which was gratifying. I’m glad the field finds my content useful. (You can always read that stuff in my UX Kit, which I just happened to revise this week, adding some salary and job title updates).
But I thought the other Ask UXmatters contributors had some fantastic points and I want to call them out here.
Dan Szuc of Apogee lists a number of questions a UX team *should* be asking itself. I think he nailed it when he said this:
What do you see as success for your UX group?
To me Dan defined the essence of the issue: when you’re building a UX group, it’s critical to define what success looks like. It may be metrics-driven; e.g., “we shall be usability testing 80% of our company’s product line by EO 2010″, etc. It could be anything really. But of course it helps if your success definition is tied to and aligned with your larger organization’s goals…
Joel Grossman recommends taking a business-case approach to building a UX organization:
Start by preparing a business case, outlining the expected qualitative and quantitative benefits that will accrue to the organization,” suggests Joel. “Define a series of milestones that take you from the current state of affairs to an end-state that will maximize the benefits you’ve identified in the business case.
Agree and agree. Except: true “business case” documents are quite formal affairs. I certainly agree with Joel about demonstrating the qual and quant benefits. But I recommend against adopting a B-school format for your document. Keep it short and to the point. I’m pretty sure this is what Joel meant as well, but I wanted to clarify my thinking on this a bit.
Steve Baty of Meld warns against taking a centralized approach, which I heartily agree with:
I’d be cautious about moving toward a centralized service model in this case…Think instead about what you’re hoping to achieve through that move (i.e., of going centralized):
- consistency of approach
- efficient use of resources
- shared customer or user insights
- shared UX principles across interactions and touchpoints
I don’t know if Steve was reacting to my content or not. But I should say that I definitely do NOT advocate for centralizing UX in a big way. My view, which I think Steve shares, is that user experience efforts belong with the product teams they collaborate with. UX resources shouldn’t all be piled atop the organization in a service bureau model. And they certainly shouldn’t let themselves be seen as sitting on some fancy “UX throne” issuing UX directives from on high. And even when some centralized user experience concentration is called for, it should be about providing consistency and efficiency; i.e., some “UX glue” across the organization.
Having been on the wrong end of the barrel during several workforce reductions involving centralized UX functions, I have to say that UX contributors and managers are safer when they’re allied with (and aligned with) the product teams they serve. It’s all too easy to lay off an entire centralized UX group, because they’re not directly tied to any specific profit center. When things get tough, an embedded UX group has a much better chance of survival, albeit with attrition.
Pingback: uberVU - social comments