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.

Tagged : / / / / / / / / / /

Getting #UX done the UX #engagement #process

UX is a highly complex set of research tools and outputs, the use of which is dependant upon time, cost and the clients willingness to accept them.

Question 1, why are you there?

If the client were to think in best practice terms which for them would deliver exactly what they require then everyone would have a great experience of the process. Unfortunately it is pretty much a given that clients want to prove themselves knowledgable about well everything, in control and this is one of the main problems. I often hear clients say “I understand our users” or “I built this company so I know what users want” maybe they did or used to, but the fact they have called in an agency or consultancy means they don’t anymore. What clients mostly mean is I have my agenda and I want you to listen to it and agree with me. That way is the road to mediocrity.

What does the client really want?

It’s worth at this point asking the client what they want out of the process. If they only want a pat on the head and to be told they are great, best to give them that, do the job get paid and don’t put it on your CV.

If the client (really) wants their products or services to have higher impact, increased transactions, market share and gain advantage, then explain what your doing, how they gain and that great ux will fundamentally change how they work.

Question 2, what does your client understand about what your doing there?

UX is not UI, the experience is not only the interface, it’s what you can do with the interface, what tasks can be completed, what data can be inputted, transformed or called into the UI.

The real pitch for real UX.

The pitch to a new client is not we can make your product or service like your competitors it’s “we can make your offering stand out from the crowd”. Great ux is about shouting over the noise and changing the rules, “don’t catch up – great ux creates the opportunity to jump ahead”.

Question 3, how will your client know they have succeeded?

This is not a KPI hunt, clients are not really interested in you proving success, they already have their own success metrics, strategic plans and objectives they need to report up the chain. They may not be able to directly tell you as these things are highly confidential the important thing from an engagement perspective is can you work them out? Then can you articulate these back to the client in ux terms.

The real job of ux, find out about the users.

The real job of ux is to align the business with the users, from the user perspective. Users ask “what’s in it for me”, “what do I personally gain”. This means that user research is required by the clients customers, in order to work out what they want for from the business in order to take up their services or buy their products, how they will want to interact and what they will give the business for a relationship.

Tagged : / / / / / / / / / / /

#Getting into #User #Experience Part 2

Doing user experience

The first step in user experience needs to be the recognition that every problem is different and will require a separate solution. Because if they are not, then every business is the same which they are clearly not.

In effect there is no quick fix or standard solution method but rather there is an armoury of methods each with associated risks, limitations and plus points. Anyone offering a standardise method for user experience without flexibility should be ask to leave as they about to cost you a fortune.

I have worked with very well known agencies who are unable to get their clients to understand the importance of user experience – research, testing and design as they focus on the design component without proper understanding that it is only one part of a three stage process. The reason that clients give for not paying for research and testing is the assumption that user experience people a such great experts that they can do their job in total isolation from the business and the end users. Maybe ‘Super User Experience Person’ does exist but I doubt it, more importantly users change.

Some process steps for user experience

This process list is based on personal experience and is open to reduction or extension based upon just how savvy the client is and how must they really want to be successful rather than just being seen to be doing something.

PART A
1. Understand the problem (better to appear to be stupid, than to actually be so) UX reserves the right to ask stupid question to avoid doing stupid things.
When trying to find out what the problem is try to get an associative answer, what else that they see is it like.
What other businesses and systems are they similar to them? What works for these other people?
What insights do the clients have to the problem and where do they want to end up?
What are their perceived expectations and what are the levels they see as Resolution, Gain or Advantage.
Don’t skew or try to influence the client in what’s wrong or imply the solution is simple (that’s just rude).

2. Do research find out what the problem means, don’t assume that your understanding is the correct one.
Language is fascinating in how it drives understanding, but understanding is also a derivative of culture and personal experience. If you grew up in the same family, house and town as your client you would have many cultural touch points in understanding ‘what things really mean’. But you may still be wrong as you can’t see through someone else’s eyes or fully understand their motivation without taliking to them.

3. Analyse of research with an open mind, again don’t fix the results to fit an easy answer. To analyse research in any area you need to define expected or hoped for results and outliers that reflect a diverse perspective. Combining and noting these variants enable a true view of the research that does not hide inconvenient perspectives.

I come across a lot of trite analysis with recommendations that reads as though the practitioner has not done any research at all.

For example the client wants to assure users that they are important to them. A trite recommendation is to;

  • Enable users to complete a feedback form

Well that just tells the user the company quite insecure and most people unless they have a problem won’t respond.

How about providing;

  • Confirmations
  • Expected timelines
  • Tracking

These are things that assure users that their issues are important to the company and therefore they are also.

4. Get validation
5. Compose concepts
6. Create buy-in

PART B
7. Define the audience (actors)
8. Create personas
8.1 Research
9. Define critical tasks
9.1 Research
10. Define key pathways
10.1 Main pathway
10.2 Alternative pathways
10.3 Failure pathways
10.4 Build sitemap (iterative process)
10.5 Select pages / interactions / responses that will be wireframed

PART C
11. Set the tone of voice
11.1 Type of language
11.2 Level of formality
11.3 Use of jargon, brand identity or subject specific words
11.4 Content style
11.4.1 Meta standards
11.4.2 Content object model
11.5 SEO if web based

12: Wireframes (iterative process)
12.1 Selection of type and method of production
12.1 Wireframe Concepts
12.1.1 User testing
12.2 Wireframe sketches – Client sign off
12.3 Wireframe prototypes
12.3.1 User testing – Client review
12.4 Wireframe and Visual design integration (template definition)

13. Functional specification and analytics specification – Pass to development

PART D
14. Usability Test plan
15. Accessibility Test plan
16. Functional and Content Test plan

17. Testing handover with participant screening document
18. Review testing results

PART E
19. Modify labels,  interactions and structure in line with findings

PART F to Z and A
20. Done, until …..
21. Check interactions based upon analytics and more user testing.
22. Offer enhancements to clients.

Related

Tagged : / / / / / / / / / / / /

#Getting #User #Experience #UX to work with #Clients

Setting the scene for user experience to work

I have over the last few months had several rants about people claiming to be involved in user experience who are not regardless of their job titles.

I came across a great blog post by Whitney Hess (I don’t want to steal her traffic so here is just a link) about what shows your not a user experience person, but I though maybe I should point to what does show your are one to get some balance here.

Training clients what to expect

Does your client know what they want, this sounds obvious, but user experience is unlike a purely functional activity (asking developers to make sign in work), most clients just want better, but don’t know how to quantify better. This is not the time to set KPI’s except in the broadest terms, but clients do need to know where they ARE in a quantifiable way, ‘things are bad now and we want better‘ is not a good starting point.

What things, set against what standards or targets based upon what business or research rules (who wrote them and why) are BAD and what level of better is better, just to get a transaction, getting a reuse or becoming friend for life type of BETTER?

If you don’t set your clients expectations in a realistic manner they will come up with unrealistic expectations that you will never be able to meet. But to do that you’ll need a starting point, mid point and end point, that uses your clients own language and the only way to establish these things is through research.

Does your client understand that user experience involves thinking as well as making things?

User experience is not a headless chicken activity, involving lots of running around, thousands of meetings about meetings, it requires complex thought and strategy. I like many other user experience people find going for a walk while thinking about the complex interactive and logic of use in the initial part of a project very useful, either that or people can watch my head explode.

User experience is not a production exercise;

  • User experience leads
  • User experience finds out
  • User experience tests
  • User experience communicates

so trying to cost plan it or manage it in the same way as development does not work very well.

Does your client understand that there is a set of formal methods that will make the user experience work?

For some reason everyone focuses on wireframes. Wireframes are of the least importance in user experience and are the culmination (after a lot of versions) of the user experience research. Wireframes are low quality pictures for the most part (or should be, prototypes are something else) and should be as sketchy as possible to allow stakeholders to focus on signing off the interactions rather than focusing on pixel level graphics and colour.

I have previously mentioned about the avoidance of research by clients on the bases that they cannot see its value in the final deliverable. This stems from clients being misinformed by business journals (I have read some great howlers by highly reputable journals) and sales people not understanding that the user experience research is the deliverable and that wireframes or functional specifications are the communication tool.

Related

Author Links

Tagged : / / / / / / / / / / / /