Tuesday, October 21, 2008

Boats, Bridges and Buildings: structuring UX teams

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.

Saturday, October 04, 2008

Comparing UX methodologies

In order to extend the conversation Joshua Porter kicked up at bokardo.com on the benefits of activity-centred design and its possible superiority over other design methodologies, I'd like to offer up the following by way of evaluation criteria...

If you would like to proffer up some UX methodology as being superior to any other, then what you're effectively saying is that *any* UX team, working on *any* UX project, will produce a superior result by using that methodology.

In other words, to justify the assertion, you need to agree that the team members and project requirements are inconsequential with respect to the overall quality of the end result.

So now, think of those projects where the methodology has been identified as the key success factor and ask yourself: was it the methodology alone, or the combination of people, tasks, method & the specific requirements of the project all being aligned that made for such a successful end result? My guess is that the methodology is not a sufficient condition for success.

That means for your own team, and project, cast a critical eye over your team and think about the requirements of the project. Then choose the collection of tasks & process that best suits.