Karl Smith User Experience Consultant It's all about making peoples experiences good ones

Interview with a User Experience Guru part 2

User Experience (UX) why is it important?

User experience is so important because it enables client companies to get to the heart of their relationship with their customers without the 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 user experience is about the ability to make decisions based upon re-creatable rigorous scientific research (avoiding one person’s view) involving real customers to create actionable information for design and the businesses strategic and tactical objectives.

Real user experience 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 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 something new or an add-on many people are missing the point. User experience picks up on that entrepreneurial aspect that few people have by enabling 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 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. In one project I found 12 user requirements that would have made the software system better than the market leader ($150m to install) 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?
• Do they want to fill a gap?
• Do they want to capture a market?
• Do they want to be iconic?

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.

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 shoveling the same stuff for everyone. And looking at delivery divisions to see if they are fit for purpose in that area I have had people promoted and other fired for incompetence.

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.