There's a recurring theme in discussions within the user experience design community on the most appropriate team structure and composition for a UX project. A range of issues tend to crop up: methodology, skills, deliverables, structure - all aimed at resulting in a 'best practice' notion.
For me, this is often akin to saying "I'm going to build something; what should my team look like?" There's simply no meaningful way to answer that question without know what it is you're going to build.
If my aim is to construct a boat, then some water and flotation modelling might be in order. A nautical engineer might be able to help me with that. They can design the actual boat for me, too. Or I might use a specialist ship designer. I'll need a master shipwright as well, and probably a bunch of shipwrights to help them. There'll be carpenters and plumbers - for the walls, floors and interiors; and lets not forget a mechanical engineer to put together and install an actual engine.
All of which would be completely useless, and pointless, if my aim were to build a bridge or a large building.
But there'd be similarities too. Instead of modelling how the boat handles high seas, I might carry out computer simulations - or small-scale prototypes - to test out how my bridge handles high winds or earthquakes. My ship designer would be replaced by an architect; my master shipwright by a civil engineer; my shipwrights by a host of construction workers; etc etc.
My bridge doesn't have an interior, so no need for interior designers, carpenters, plumbers and the like.
And, of course, all three types of building project could do with the services of a project manager.
There be similarities, too, in the types of deliverables we'd need in the early stages (especially) of the process. Detailed blueprints are common to all construction projects; materials estimates; project plans; prototypes; 3D renderings; to name a few.
The thing is: everybody knows this already. No-one would expect to take the ship-building team over to the river and get them to build a bridge; or put up a two-storey house. So why would we expect the UX team who designs a complex piece of desktop software to pick up and design - with equal proficiency - the sales and fulfilment process for an online business. Of course the requirements of the two projects are different. Of course the team, methodology, structure, skills & deliverables need to be matched to the characteristics of the project.
Thinking otherwise is to simplify the notion of experience design into an undifferentiated umbrella term that fails to reflect the complexity of the activity.
Posts
Goodbye Logic+Emotion, Hello Armano Design Group
3 years ago
2 comments:
You're right, Steve. In an ideal world you would assemble the right team for the job only once the job has been defined.
But many (most?) teams are assembled according to fulfil a generic need; possibly including working on a bridge, boat and house from month to month.
While I would like to think an organisation would have a more sharply defined purpose, in my experience that's not the case. What happens is the team is expected to be able to tackle anything that the business--or should that be 'sales'?--comes up with.
In particular, agencies follow this pattern. There's usually little discrimination in terms of the business they attempt to tackle. So you do get people who design websites also attempting to sort out the sales and fulfilment process for an online business (or even 'better' the data warehousing strategy for a large travel retailer).
Thus, everyone keeps asking about the ideal, generic make-up of a UX team. It's a compromise, no doubt, but there's not enough consistency in the skills required from one project to the next to approach it in any other way.
Pat That is a good and valid point. Do we then construct our teams from generalists rather than specialists, or should we be looking at adopting more flexible staffing arrangements?
I made the (subtle) distinction that a team design suitable for one project wouldn't be able to work as effectively or with the same level of quality on a different type of project, but perhaps I should have been focused on how to either: a) get the most out of a team of generalists; or b) retire the notion of permanent in-house teams in mixed-project environments.
Thanks for the comment: that's helped crystalise some of my thinking!
Steve
Post a Comment