UX: Who the hell ends up doing what? (part 2)

So recapping from the previous post (part 1), there are around 10 different UX roles that I get asked about regularly and good few more from time to time. The titles and the skill sets consistently fail to match, and ironically finding the correct UX expert has now become a complicated user experience in its own right. As UXers I believe that we need to eat our own dog food here and ensure there is a simpler taxonomy and consistent, intuitive labelling system for our discipline, or others will continue to create more and more spurious roles on our behalf. If I may quote Edmund Burke :

All that is required for chaos to prevail is for good UXers to do nothing.

Ok, I may have tweaked the quote a little, but I truly believe this, and the requirement for UX roles to evolve towards a consolidated and intuitive set of UX functions should be very obvious, particularly to a group of people who's discipline is supposed to be that of creating order from chaos (us). But, how many UX roles should there really be and how do we define them? As Einstein said:

Everything should be made as simple as possible, but not simpler

So, how do we make it as simple as possible? We need a taxonomy.

The 3 Ds model

The 3 D model is a widely used problem solving model that operates as a taxonomy for us because our skills fall naturally into each of the three phases. In fact its a bit unfair to even call it a model as its the simplest of common sense. It exists as a model really in order to ensure a consistent common sense approach that can be articulated to management and clients alike. Anyone who does logic for a living will be wondering why we need a model for something this obvious. However, as well as ensuring we all play by the same rules, it prevents those who are logic-impaired from sabotaging a project as a result of their need to contribute. It is used widely across digital industries and it is simple, consistent, clear and still the easiest problem solving formula for all of life's scenarios and honestly, isn't that what UX is all about?

It breaks any requirement into 3 simple phases/categories:

1. Discover - What's the problem? Research and establish the scope, opportunity and limitations of the requirement.
2. Define - What's the solution? Architect a solution based on the output of the Discovery phase, embracing simplification and innovation
3. Deploy - Create and deliver the solution architected in the Definition phase

Let's look at each of these Ds in a little more depth and see where the UX roles listed in part 1 fall:

1. Discover Phase

The tasks in the discovery phase are: to profile the requirement, challenge assumptions, gather business goals and discover end-user needs, look for inefficiencies and explore where value can be added through simplification and innovation. We also take note of any environmental limitations. We then align all of these to produce a 'landscape' view of the requirements, consisting of a number of documents and artefacts, to be presented to the client and used in the next phase, to define the solution.

Traditionally only the Business Analyst role was expected to cover the Discovery phase comprehensively, but I have also carried out many Information Architect roles where I was expected to do all the Discovery phase as well as the Definition phase and this is a good example of how little UX titles mean at the moment. These are the roles that usually cover some or all of the Discovery phase tasks:

Business Analyst,

Information Architect,

User Research,

Usability Analysts,

UX Designers,

UX Architect

2. Define Phase

The tasks of the Definition phase are simple: to produce guidance to solve the discovered requirement. This generally includes wire framing, prototyping and user testing, but can include all manner of solution modelling and presentation documentation and artefacts. These are the roles that usually cover some or all of the Definition phase tasks:

Information Architect,

Interaction Designer,

UX Designers,

UX Architect,

UX Developer

3. Deploy Phase

The tasks of the Deploy phase are: to design the creative elements in high fidelity and to create the code to layout the design and execute all defined interaction in a platform agnostic way (mobile, tablet, desktop etc responsive). This follows UX best practice guidelines and includes testing the solution in mock release environments. These are the roles that usually cover some or all of the Deploy phase tasks:

UI Designer,

UI Developer,

UX Architect,

UX Developer

Spidey...Senses...Tingling

Do you feel that? Its your UX spidey-sense tingling because many of these roles break this taxonomy by coming under more than one of the Ds. This is because many of them seem to be arbitrarily titled around a clients misguided sense of what UX is, not around the discrete skill sets needed to carry out these phases of UX. UX titles cannot continue to have these inconsistent meanings!

UX skill sets work naturally within these 3Ds (Discover, Define, Deploy). I'm not just saying this, I live it, I work it, I have had the opportunity to try it, test it and experiment with it for over a decade (as I'm certain many of my peers have) and this is the natural order of things. All methods, disciplines and processes fall naturally and intuitively into place when you drop them into a 3D taxonomy. It's common sense and the most fundamental of logic: It's as simple as possible, but not simpler.

Ok, that's probably enough to mull over for one post. In part 3 I will finally put forward what I believe are the obvious discipline skill sets and notional role titles to simplify UX roles into a taxonomy that is axiomatically correct for us, clients and recruiters - for comment and debate no doubt ;)