UCD has an image problem

Much is made at events and on Twitter by those in the industry of how much UCD is misunderstood and not accepted by other disciplines. We all know this is a problem, but why?

Partly, it’s that UCD has only come close to mainstream in recent years and while there is obvious demand for these skills in the form of available jobs, this abundance does not reflect an understanding of what we do, or any appreciation for the skill or nuances. It merely displays a demand for either something that is required (say, for GDS) or something that is perceived to be a magic bullet.

Now, there will always be struggles, and there will always be resistance. Even Agile still struggles with perception despite the Mythical Man Month having been written in the mid 1970s. This is one of the challenges of being (relatively) new to the party.

This does not mean we should be inert, or accept the status quo as immovable. As practitioners we should be actively supporting and helping UCD become part of successful projects. Sadly, our discipline seems to fail miserably at this task. We are too often perceived as whiny, unwilling to compromise and difficult to work with. In part our discipline suffers from the tenacity of youth, not yet comfortably settled with rigour and familiarity.

It’s no wonder UCD struggles.

In this article I’m going to cover some of my key areas of concern and some of my favoured working practises for building understanding, respect and integration within teams and projects.

‘Evangelising’ or ‘how not to talk to co-workers’

‘Evangelising’ isn’t my favourite word. To me, it goes hand in hand with ‘proselytise’, ‘proclaim’ and ‘preach’ which all imply dogma or doctrine. I’m far too frequently embarrassed by what I hear being said by peers. Gushing over how vital design and research is to the development process or how UCD is the guiding force of any successful project. This nonsense is blurted out in front of conference audiences, and in front of the teams in which we work with seemingly no regard for how it might be perceived. We all know someone like this — most likely several.

It’s tantamount to standing at the doorway and shouting that you should be let into the room because what you do is vitally important. It might be, but that’s not the way to get what you want. The segregation which is frequently blamed on other disciplines not getting it is largely of our own making.

Superiority

I knew a team once that referred to their UCD practitioners as ‘the divas’. They refused to compromise, demanded a lot with little justification and became surly and, heaven forbid, churlish when denied. Now, while this is a bit of an extreme, it does hint at a deeper problem. There is a superiority complex in our industry, and it does not go unnoticed.

One of my least favourite ways this perpetuates is the renaming of The Process to The UCD Process, just to make it extra clear to the rest of the team how very important what we do is. It’s not always the intent, but it is almost always the effect to those we work with. As much as UCD may laud multi-disciplinary teams, it is rarely practiced. It’s bonkers.

To be clear, I am not tarring all with this brush. To be clear also, I am not stating that we should simply accept situations which would be detrimental to our team goals; advocating for beneficial activities is unquestionably part of the job. I am stating that design too often treats other disciplines as people who should listen and who should obey, instead of respected peers.

This attitude is perpetuated too in the upper echelons of our industry, and is passed on to more junior staff which is unhelpful not only to them, but to anyone they work with thereon.

Not sharing

Designers and researchers can be overprotective of their craft. For many years design and research has been perceived (by client representatives and delivery managers, usually) as lacking rigour or any kind of expertise. We have all had those conversations explaining yet again that yes, there is actual skill involved in what we do.

These repeated encounters put design and research on the back foot, and means practitioners are often defensive from the off, but putting a ring fence around what we do is counter-productive — decreasing interest and engagement. It is akin to shooting ourselves in the foot.

A solution: Practise, don’t preach

Far too many in our industry seem to forget our practices entirely. There is no problem facilitating and empowering users within the context of the job, yet our industry seems unable to apply these skills to other situations, notably our own.

We are fighting for acceptance into an already fairly well-established group. Tech, BA, product and PM have a long history together in the digital and service world. It’s not always harmonious, but it is established and accepted.

Other disciplines are not stupid, often operating on a principle that products and services have been implemented successfully for quite some time before we came along, and they’d be right — plenty failed too, of course.

Design has much to offer, but to be effective we need to apply our skills to our own environments, too. We are the stakeholders. Our goals? To be understood, trusted and able to collaborate effectively. Our hard-to-win-over colleagues? They’re users with needs, desires, behaviours and motivations. We need to understand those needs and use this information to shape our approach.

We should be thoroughly engaging our stakeholders and team. Encourage active involvement. This allows you to demonstrate your value over simply talking about it, but more importantly it can help them to become aware of how human behaviour can affect what they do.

I’m in no way suggesting your PO go solo facilitating user research or hold authority or ownership of research plans or design artefacts*. However, we do not work in a silo. Our work does not exist in a silo. There will always be external factors and input from other disciplines which affect and shape our work.

We have to play nicely with others in order to make headway, and to start to shift mindsets. We need to integrate far more than we are in order to enact change within our teams, our organisations or start to shift mindsets on our discipline as a whole. Tap into the wealth of experience within your team, let them see what we do and how it can benefit them. Share.

—

*To give a concrete example, I am typically accompanied by team members on research visits. They get to observe, take notes and have a go at facilitation under supervision. My design workshops are open and collaborative, drawing input and investment in our work from all team members, and where possible I co-facilitate too, building further bridges with delivery or tech.