When Introducing UCD in an Organization, Technical Capability is Only Half the Story

If both these teams were very talented and technically capable, what exactly did one team do so right and the other so wrong? They both had the same destination, but took different paths in order to achieve it. The successful team put in extra effort, just as much as it did to technically implement its usability evaluations, to make sure that all their stakeholders—business leads, technical leads, product bosses, programmers and marketing folks—were happy and upbeat about the entire process, right from day one, whatever compromise it required. The other team simply conducted usability tests and cold bloodedly revealed its findings, which basically rather openly razed much of the work that the other teams were doing.

Takeaway

When you are trying to introduce UCD techniques in your organization and your goal is to ultimately integrate UCD into your organization’s Product Development Life Cycle, then arming yourself with technical capability is only half the story. The other half is your team’s ability to effectively deal with soft issues and successfully engage with stakeholders. With either part missing, you will not be able to go very far.

Technical capability is your team’s ability to make use of their collective knowledge of user research and usability evaluation along with IA and IxD methods so they can use the correct one or a combination of them in order to find out who the users are of a product and what they want and need. They can then validate assumptions about how users will use a product, and gather information continually about how easily the product being developed can be used by its intended users.

If you have strong technical capability (and by that I mean having a good understanding or experience of how to execute UCD techniques), you will naturally be able to demonstrate how valuable UCD can be when used on a project. But doing so is not as straight forward as it seems. When you try to do this, you will be met with varying levels of skepticism and quiet opposition. This is because, while you are in essence trying to simply improve the efficiency and effectiveness of the overall product life cycle, it is often interpreted by the others as showing inefficiency in the current way they are working, which is not a good thing for them. Nobody wants to look bad, especially when they can avoid doing so.

In order to implement your technical skills, you need to get hold of opportunities to demonstrate value in the first place. Then, you need to be appreciated for the work you are doing and get the right noises made so stakeholders and other influential people in your organization hear about the value the product has derived out of it. Going further, you need willingness from your stakeholders to take a few pains themselves in order to help you get further projects and set the ball rolling. In order to do so, you will need to effectively deal with soft issues all the way and successfully engage with your stakeholders. Otherwise known as ‘soft skills’, I will refer to it as soft capability.

Who are your stakeholders? They are everyone and anyone who is affected by your actions. This includes folks in product or project management, business, programming, analytics and marketing. That’s a lot of people, and that’s just how much opposition you might face when your user research actively crosses their paths. Folks from the product team may already go with the marketing guys for conducting interviews with users (they probably do focus groups too).

The product guys already use sales and customer checkpoint data to keep a pulse on what the user feels about the product and the programmers simply don’t agree with the itsy bitsy changes you make to the interface and flow to enhance the user experience as it increases their work load in an already tight plan.

You may think that soft skills are not unique to the situation I’m describing and that they are required in any sort of occupation across the industry. That’s correct. But the difference here is ‘how important’ is it? The difference is about ‘good to have’ versus ‘required’. Let’s say, if an organization has a systematic usability process in place, then technical capability basically translates to successful implementation of UCD techniques for you. Here, dealing with soft issues, just as in any other work area, will help increase efficiency of the department. But if you are trying to introduce UCD methods into your organization, then technical capability does not translate into successful implementation.

It is here that technical capability is indeed half the story, and ‘soft’ capability is the other half. You will be able to get a better understanding of what ‘soft capabilities’ are and how and when can they be used in the following two stories.

Pages: 1 2 3 4 5