This is not a blog post about definitions. It most certainly isn’t a blog post about job titles. Its a blog post written to humbly request a different viewpoint on the world in which we work.
As anybody who has worked in our community for a while will testify, every few months or so a conversation will start up about defining what we do. Levels of granularity will be endlessly argued on Twitter. Overlapping skill sets debated. Accusations of land grabs by X discipline over Y discipline will fly.
I don’t care. This is why.
If you are working in the context of multi channel digital delivery in 2014 then you will be familiar with some of the following skill sets:
- Service Design
- Content strategy
- Information Architecture
- User Research
- Interaction Design
- Visual Design
- Front End Development
- Back End Development
When you look at the list above, I ask you not to see a list of job titles but a list of design considerations that must be completed in order for the project to be successfully delivered.
A number of steps that must be gone through. A set of things that when done correctly, lead onto other happier things. If any of these things are not done then the likelihood of our project suffering is high.
We need to be considering accessibility from the start. We need to be thinking about structured content. We need to be considering what our users need and want. We need to be thinking about brand application. I could go on…
The reason I don’t care for definitions and job titles is that as long as the things in the list above are being competently handled on my project, I don’t really care who does them.
Assuming your project team has competence in all of the above disciplines, your project will be ok.
Specialisation and project teams
Its the nature of a maturing industry that over time a wider range of specialisations will start to appear, quickly followed by the establishment of umbrella terms (user experience anyone?).
Those specialisms, in my opinion, arise over time because the community starts to discover an intrinsic value in their practice. The community discovers that when they do a thing from the list of disciplines above, more often than not their projects benefit. Any discipline or skill set that did not offer value to a project design process would quickly whither on the vine and die.
For example, at some point in time somebody realised the inherent benefits of talking to end users. A few years later the “user researcher” specialism is born. I would therefore propose that user research offers intrinsic value to a design process.
But does it necessarily have to be completed by a “user researcher”? If its a big project team with a properly qualified user researcher on the team then sure go ahead. But what if I also had a fully qualified Information Architect who also happens to be competent at user research on the project team? Hmmm, dilemma time.
I don’t care who does it. As long as the user research (you know that intrinsic value adding thing that is really important) is competently handled, I really don’t care.
Don’t have an accessibility consultant on your project but do have a cracking front end developer who specialises in web accessibility. Great!
Got a content strategist and an information architect on the same team? Let them fight to the death using blunt spoons in a pit of tar. Ahem. I digress…
My blindingly obvious point is that when viewed in the context of getting stuff done, suddenly job titles and definitions just don’t seem that important anymore.
There is a whole range of value adding activities that need to be completed for a project to be successful. They are things that simply need to happen. As long as they are done correctly, who does them is just academic.
Therefore next time you are assembling a project team don’t tick off job titles, tick off competencies instead.
Thanks for reading!
If you enjoyed what you read then please do share it, I’m always appreciative of the support. You can also follow me on Twitter here.