An interview with a UX Guru

Extract of an Interview from November 2012

User Experience (UX) looks pretty simple can anyone do it?

No it’s a skill and knowledge based activity,

I look for communicators with formal science qualifications (BSc, MSc or PhD), standards knowledge, creativity and genius level intelligence, when I'm hiring

It's pretty common to look at the outputs and think they are simple things, the outputs are just communication devices, which through attrition and code limitations will change.

Wow you need to be a genius to do User Experience (UX)?

Not exactly, but it helps.

User Experience is a complex translation process, requirements are gathered from users, sometimes they have the solutions, they are than combined with the business requirements and both sets of requirements are tested with users and are transformed (creating project requirements). These project requirements are then filtered through standards and then transformed again into concepts. The concepts are then transformed into functional and non functional specification (mostly as user stories) which are transformed again into wireframes, annotations and models. Finally if its a digital product developers build UIs supported by User Experience which are then tested by User Experience, if its a Service it's modelled into a delivery mechanism, with a communication strategy and an interaction touchpoint strategy.

UX must be conducted under strict scientific rigour and be repeatable by another UX person

Most people who say they do User Experience simply can’t do this process. Often it's pure vanity, the desire to feel special at the cost of other Humans who must endure the awful thing that has been created by them.

If a UX solution cannot be found by another UX person with the same data, it's not repeatable, it's not UX

But everyone’s opinion is important?

No they are NOT.

Think about it why are companies looking for User Experience (UX)?

Companies need UX because they recognise that they need to build experiences that their customers want to have in order to have an active and continuing relationship

If you recognise this is a relationship between a business (that is the brand, ethos or product capability, not stakeholders) and end users or customers then they should be given at least equal priority in the project as the business. 

How do you get this equal priority to customers?

The business will have clear objective and sometimes an overarching strategy so usually that is clear. But to understand end users and customers objectives requires user research (a combination of quantitative and qualitative methods) by an experienced non-partisan User Experience practitioner.

The level of risk on non adoption, training required or out right ridicule (by the public on social media) has a direct inverse relationship to the quality and amount user research conducted

Often however stakeholders and IT opinions drive what is agreeable instead of the customers who are expected to adopt the experience.

So are UX people always right and other people on a project team are wrong?

No not at all, User Experience people are not speaking for themselves or protecting their solution, they speak for users and the best alignment of the users experience with the business.

Most importantly UX architects should be able to provide actual proof of why they offered the solution they have, as data analytics or interview notes, videos or voice recordings. UX is not for people with a big EGO, its for people willing to set aside their views for the views of the intended users.

User Experience (UX) why is it important?

User experience is so important because;

UX enables client companies to get to the heart of their relationship with their customers without marketing glamor, that hides how they really feel and what they really experience

Client companies spend a great deal of money creating myths about what they do and their relationship to their customers but they also need the reality that user experience research brings.

Ultimately UX is about the ability to make decisions based upon re-creatable rigorous scientific research (avoiding one person’s view or a tainted sample - project team members or stakeholders) 

UX involves real customers to create actionable information for solutions that meet the businesses tactical and strategic objectives

Real user experience (there is a lot of fake UX about) should be at the heart of the client company making the alignment between them, their products and their customers. User experience can also be the starting point to create new business opportunities changing the client company’s future, new products/services or creating entire new companies.

So you can change the future of a company or create new ones with User Experience (UX)?

Yes, in some way because user experience is seen as an add-on many people are missing the point.

User experience picks up on that entrepreneurial aspect that few people have

UX enables client companies to rapidly test and distill (through user requirements) the few great ideas from the thousands of ideas that enable them to engage with and transact with their customers, build trust and establish relationships or become iconic service or product supplier.

So User Requirements are the critical bit?

Yes, if you can work out what does the customer want to do and how do they expect to acquire products or services then the market is predefined and ready for engagement.

Are User Requirements hard to find?

Ha, ha, you mean is there an easy way to find them? One of my sayings is ‘something new for the sake of something great’

some user requirements seem obvious, but when tested with real customers are worthless

Other user requirements are only revealed in user research; I often find killer requirements in user research that make projects from a basic fix into a game changer or advantage UX. In one project I found 12 user requirements that would have made the software system better than the market leader ($150m to install without integration, our purpose built product cost $20m in total) but not all the requirements made it into the build.

So not all User Requirements make it into the project, why?

Partly it’s business and partly it’s personality. The business part is cost and time, there may only be a specific remit of the project defined by a static cost and a static delivery date. In these circumstances un-used requirements are allocated to later phases in a logical way so that they add value.

The second part personality goes to the expert culture, where people in a project team purposefully ignore or seek to limit user requirements because they want control, be seen to lead or be the expert. It’s quite sad as the expert culture is responsible for the 70/30 (though I think it’s more 90/10) where 70% of all technology projects fail. If people could be more objective and listen to the two expert groups the client company and the customers then we could change that ratio significantly. Unfortunately the expert culture will do almost anything to protect itself from be relegated to a mediator, even if that is it’s most effective and beneficial role.

When User Requirements don’t make it into a project does it affect the client outcomes?

Yes always, sometimes quite dramatically.

I worked with a digital agency (on another project) where they built a social network for a huge multinational. It was filled with lots of fun flash games based around a well-known household product. The client remit was we need to be involved in social media, the agency did no user research and the client company never asked for any. The result was a ￡1m spend on a social media system that had 88 (44 from the project team) people sign up.

The best way to understand this problem is to ask clients;

• Do they want to have a go? 90%.
• Do they want to fill a gap? 7%.
• Do they want to capture a market? 2%.
• Do they want to be iconic? 1% or less.

The 90% attitude is to have a go and they fail their original outcomes (but usually change the outcome to get something), 7% will fill a gap (because it’s new territory and they can’t qualify success), 2% will capture a market (but not hold it long, because they rest when they should push on to iconic) and 1% iconic because they got everything aligned before going to market and have considered a lifecycle that will need constant support as the product matures.

What happens to the people who reduce the client outcomes and limit User Requirements effect on a project?

This depends on what the client company expectation was. Many people go on as if it’s normal to not deliver advantage then wonder why clients move to new service providers.

I have provided consultancy at both ends of this spectrum. I offer vendor consultancy to see if the consultants who make the pitches actually have a considered (around the client) process or are just shovelling the same stuff for everyone. And I look at delivery divisions to see if they are fit for purpose in that area I have had people promoted, others removed for incompetence and in a few situations got the funding for the building of large internal teams.

When working with developers my question is always ‘your changing the user requirement now embed in a design (for whatever reason) if the project fails because of this change, you will be fired, do you still want to make the change?’

This goes to the heart of requirements they are not opinions, they are instructions, changing them should be at the peril of the person who changes them

there should always be a risk associated with a single perspective change, in the action and the management of the risk it creates.

Extract of an Interview from November 2012, this has been online for years.

Published for informational purposes only.