5 User Experience (Customer Journey) lies, damn lies and absolute myths

1. Anyone can do user experience, nope!

I meet a lot of people claiming to do user experience, process and deliverables aside, they don’t have a usability background so they cannot do user experience.

User experience is a solution capability based upon usability principles and research findings not design aspirations

User experience is a solution capability (not all usability people can do user experience) based upon the experience of conducting usability testing and user research. Usability testing and user research provides the standards and experience of the user that is needed to understand their perspective, elicit the correct (there are wrong ones) requirements in workshops or testing and represent them in projects.

I met (in 2006) a UX expert, I’m always worried when I meet UX experts, because I am a UX expert. Anyway she was moving from Razorfish into the freelance world for the big bucks and working a large project for Honda cars through a digital agency. Unfortunately she did not know how to use any software apart from word, so I checked her out sure enough she was a PA at Razorfish not a UX architect as claimed.

This happens so often it’s shocking, my favourite one has to be the PHd student I met working as an accessibility consultant repackaging W3C guidelines as work for several agencies. What I love about this guy is he does public speaking and has even done UX London and people wonder why I’m not interested in these conferences!

There are loads more fakes some of them milking huge daily rates from major companies, as these companies don’t do any checking it’s their own fault, but it makes me quite sad that clients and employment agencies can’t tell the quality from the junk.

Not only is the user experience world full of fakes, I’d go as far to say that of the people I’ve met in the last 13 years involved in UX;

80% (8 in 10) of UX people are fakes and have no idea what they are doing

These fakes can certainly sell themselves and get work (now in some very senior positions) because the clients did not then and still don’t know what they should be getting out of a user experience professional.

2. User experience can be learned from reading books, nope!

Absolutely read books, but read lots of them, but don’t quote them like the Bible that’s a bit odd. But reading about someone else’s experience does not mean you have any or in fact really understand the context or scope of those experiences.

Do some testing and research, I’m seeing a great deal of roles advertised for UX researcher or UX workshopping this is a great concern as the priority of discovered requirements and their interrelation is almost impossible to communicate in written documents. This critical project information should always be available.

Separating UX research from the UX solution activity may make sense for IT activity but for User Experience Professionals it does not

I assume this was a bright idea of someone who doesn’t actually know anything about UX regardless of their job title.

3. User experience is an IT activity, nope!

User Experience is not an IT process, it starts in the business area before IT is involved

I know a lot of company IT departments have tried to subsume User Experience into their IT process; user experience is considerably less effective this way.

User Experience leads the projects speaking for the End User Stakeholders (customers) as the Business Stakeholders speak for the Business

User Experience fits better into Agile DevOps, Change Management, Operations or as separate Standards Authority within organizations.

4. User experience is a design activity, nope!

Not exactly no, it sets the project brief and requirements then latterly gets involved in research first before creating solution concepts, user testing concepts then defining the final solution.

If there is no research, user experience solutions are not possible

5. The cost of user experience is going down, nope!

Perhaps a better understanding is that the market is flooded with willing bodies, the quality goes down and so does the price because people find it difficult to sell invisible clothing (the kings new cloths) even to people who like the colour and the cut, so accept a reduced price.

So the value of the job title is going down.

User experience should provide major cost benefits and advancements to companies who wish to stand out from the crowd, provided they find people who know how to do UX correctly.

This is the same problem that Agile is going through, people have picked up the language and use one or two of the activities incorrectly but don’t exceed the current status quo because they don’t know how to.

Great Agile is fast and accurate, flexible and delivers usable software and change, just as Great User Experience should provide the experience that customers want and allow them to interact with the client, accurately and often.

Great User Experience delivers increased transactions, interactions and communications towards relationship building.

Tagged : / / / / / / / / /

Welcome to my blog

About Karl Smith

Karl Smith works globally with directors, stakeholders and customers of multi-national enterprises across all verticals and technology stacks whose focus is on new concepts and capabilities that drive customer engagement, interaction and retention.

He creates digital companies, strategies and services that drive customer centricity into the core of client companies, that in turn enable them to realise their ambitions to engage with and establish a consistent two-way communication and interaction with their customers.

These new companies and capabilities are underwritten with tailored blue sky work, digital strategy, management consulting and program planning fitting to tight timescales, strategically correct, fully featured, useable, governable, scalable, efficient, end to end business propositions, service designs, applications, integrations and software systems.

Karl Smith Practical Skills

He is a highly competent, personable, creative and motivated person with a keen insight and definition ability. He is a critical thinker and able to rapidly discover the essence of problems then define, communicate, create buy-in and deliver end to end digital and process solutions. He positively motivates those around him and is able to engender a great team dynamic by leading from the front. He has business experience since 1989 at comparable levels in fields including defence, industry, energy, pharmaceutical, biomedical, construction, fashion, finance, banking, FMCG, property, publishing, healthcare, travel, policing, crown office, local and central government. He has specialist banking experience with investment, private, commercial, business, trading, wealth management in Europe, USA, China, Australia, Japan and Russia.

Karl Smith is a Founder and Director of UCD UK Conferences.

Karl has worked with several companies to define for launch or redefine their service offerings, business structures or digital presence including;

  • Avaloq AG – Setting up enterprise wide adoption of design thinking principals, master plan delivered in just two months.
  • Wipro Digital – Launch Wipro Digital, Design Thinking, Service Design, Creative Technology Services, User Experience Strategy, Creative Design Services, M&A Designit – 2014
  • Accenture – Launch of Enterprise User Experience, Digital Services Launch, M&A Fjord – 2012
  • Pearson Publishing – Digital Services Restructuring – 2011
  • Deutsche Bank – Self Service Paradigm Shift – 2011
  • RBS – Risk Management – 2010
  • The Oxford University Press – Mobile First Digital Strategy – 2009

Karl Smith has a wide experience in management consultancy and digital technology including business management, start-up, business strategy, digital strategy, advertising, customer experience, user experience, productisation, governance, change management, project management (waterfall & Agile), enterprise architecture and project definition, design, optimisation, delivery and digital marketing. He has been honoured by the British Computer Society for his eminence and significant contribution to the fields of UCD and User Experience with a Fellowship.

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

#Agile #User #stories is a #UX #method

User stories is another name for a Cognitive Walkthrough

I have been involved in Agile for a very long time, mainly because it uses methods from the human computer interaction scientific process (CHI/HCI).

I’m surprise no one else has blogged about the use of CHI/HCI processes in Agile before, but though I should say something as I keep getting told that it’s interesting how many CHI/HCI people have embraced Agile. In fact it’s the other way around

Agile has imply appropriated UX techniques that have new Agile names

The main one is User Stories; they are in fact a reuse of the Cognitive Walkthrough, but I’ll let you draw your own conclusion.

Cognitive Walkthrough

Cognitive Walkthrough is a method utilised to express how the system works from a user perspective it exposes potential usability failures and defines happy and unhappy pathways

The method starts with a task analysis that specifies the sequence of steps or actions required by a user to accomplish a specified task. The system response to each action is noted. The designers and developers of the software then walk through the steps as a group this enables an agreed view. They ask themselves a set of defined questions at each step to determine all the potential outcomes. Afterwards a report of potential issues is compiled and the project team has a clear focus on the various user pathways including happy paths, risky paths, error paths and failure paths.

User Stories

User Stories are a quick method to determine the who, the what and the why of a business requirement and are produced in a narrative format as if a user was walking through their use of an interactive system

User stores are written at two levels Epic Stories that define groups of functionality (registration) and User Stories that define a single piece of functionality (sign in).

User stories are written by the product owner (an Agile tile for stakeholder or product manager) a user experience architect or a business project manager (not a scrum master) or the development team when they break down stories that are too large (these are then confirmed by the product owner).

The method starts with defining the Epic stories, then breaking these down into smaller stories that relate to an encapsulated (self standing) component. In design and development these stories can be parcelled to the various specialisations including user research (end user validation, How It Works), visual design, user experience design, back-end development (feature and service delivery), security and front end development. These stories will have their interlinks (to other components) stubbed out until those stories are built and can be integrated.

Agile + CHI/HCI = User Centred Requirements, Human Centered Design and Human Centered Development.

They are not exactly the same but the essential method is,

  1. think like a user
  2. describe what you can do
  3. build the system that enables a user to complete a task or aquire a feature

 

Author Links

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

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;

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

#User #Experience #UX #Process

Process thinking in User Experience (UX)

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 single standard method but rather there is an armoury of methods each with associated risks, limitations and plus points. Anyone offering a standardise method without flexibility should be asked to leave as they about to cost you a fortune.

Karl Smith User Experience Research Testing 200711

Offering user experience services is a bit like dungeons and dragons in that you role your 12 sided dice and hope the business does not throw some trolls at you.

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 solutions as they focus on the solutions 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, most importantly users change over time, in what they want and mean by their actions.

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 much they really want to be successful rather than just being seen to be doing something.

Understand the problem (concurrent with 2.)

  1. Do research
  2. Analyse research
  3. Get validation of what has been discovered by Target Users and Stakeholders

Define the audience (actors) this is the detail level the Target Users

  1. Create personas a tool used by the entire project team BA’s, PM’s and Developers to be acquainted with who will use the systemResearch persona types, activities, attitudes etc.
  2. Define critical tasks Research tasks ecosystem and review engagement strategy
  3. Define key pathways Main pathway
  4. Alternative pathways
  5. Failure pathways

Compose concepts

  1. Create buy-in with Stakeholders

Set the tone of voice

  1. Type of language
  2. Level of formality
  3. Use of jargon, brand identity or subject specific words
  4. Content style
  5. Meta standards
  6. Content object model
  7. SEO if web based

Wireframes

  1. Selection of type & method
  2. Wireframe Concepts
  3. User testing of Wireframe Concepts
  4. Wireframe sketches

Client sign off

Wireframe prototypes

  1. User testing of Wireframe prototypes

Client review

Wireframe & Visual design integration (prior to this point the use of high fidelity images are counter productive)

Functional specification & analytics specification

  1. Instruct development
  2. Usability Test plan
  3. Accessibility Test plan
  4. Functional & Content Test plan

Testing with participant screening document

  1. Review testing results
  2. Modify labels, interactions & structure in line with findings

Done, until …..

Check interactions based upon analytics and more user testing

Offer enhancements to clients

Some people will look at this list and think it takes years, depending on the project complexity it can take days or weeks for simple web or mobile applications and only months on complex software systems.

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 : / / / / / / / / / / / /

User centered design to ISO 13407

User centered design (UCD) is a project approach that puts the intended users (audience) of a product or piece of technology at the centre of its research, design and development. It does this by talking directly to the user at key points in the project to make sure the product or piece of technology will deliver upon their perceived requirements and align the client with their market.

The following elements operate in a cycle being repeated until the project’s objectives have been attained. This makes it critical that the participants in these methods accurately reflect the profile of actual consumers.

Simple user centered design project lifecycle visualization
Simple user centered design project lifecycle visualization

ISO 13407 outlines four essential activities in a user centered design project:

Requirements gathering – Understanding and specifying the context of use
Requirements specification – Specifying the user, organisational, technological and standards requirements
Design – Producing concepts, architectures, visual designs and prototypes
Evaluation – Carrying out user based assessment of the product or technology

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

12 #UX things you need to know

Getting into user experience, what you need to know?

What will a person need to be able to do to get into user experience;

1. Can you think?

Not the most subtle way to ask, but can you be creative? Thinking at the beginning of a project can save a huge amount of money and time later, but many user experience people blast their way into a project by starting on wireframes, without knowing what they are doing.

A huge amount of user experience simply is not user experience, its pretty pictures with poor justifications ‘it’s best practice’ my usual response is ‘prove that it’s best practice’.

2. Can you find things out?

Do you have a critical mind, can you work out what is missing from the information you have been given.

A project requires a bit of detective work because there are always gaps in the information provided to user experience, mainly because clients and IT don’t know what to provide or what is provided has had the juicy bits (outlier views) removed because clients and IT don’t know they are important.

3. Are you objective?

Having a strong opinion on user experience is really important, but it must always be tempered with an open non judgemental attitude. Are you willing to be changed by what your client, users or IT people know?

User experience people are not the gate keepers of an absolute set of rules, we have two ears and one mouth, we should listen twice as much as we speak.

4. Can you discern Fact from Fiction?

Again talking with clients, users or IT people can be pretty confusing unless you can work out if what they are talking about is still within the boundaries and various time lines of the project. A quick guide;

  • Clients tend to talk about the desired end state
  • Users tend to talk about any snippets they have heard about the project or their hopes for it
  • IT tends to take the pragmatic approach by thinking ‘what can we really deliver’

They are all true or were true at some point, or may be true if we had more time and money etc.

5. Can you deal with the politics?

Can you avoid taking sides in the various feuds that were going on before you got there and not flame the fires of distrust between business and IT.

6. Will you understand the business you are serving?

Your in a service relationship with the business, helping them get past their assumptions about their users and giving them some facts to act upon.

7. Will you understand the users you are serving?

Your in a service relationship with the users, helping them get what they need and desire.

8. Can you test – concepts, theories, business thinking, user perceptions etc?

Your going to need a lot of guts to question other peoples thinking.

User experience people reserve the right to ask stupid questions, in order to avoid doing stupid things, by Karl Smith 1999.

I’ve been saying this since 1999, I say it on every project.

9. Can you seek validation?

The user experience person is not right, they can come up with concepts and questions but a user experience person never decides they are right, they must check out what they do with other people. Often this process of seeking validation reveals more information and opens door to previously inaccessible people.

10. Can you communicate – findings and concepts?

Can you talk to people and provide information to them in a digestible way? The best way to work is to not use jargon, not assume that people understand anything especially verbal references to famous people or design principals.

You need to be able to package your information in the users and stakeholders own verbal environment, so that they recognise and understand it when they hear it.

11. Can you understand and benefit from the project teams expertise?

Do you know what other people on the project do? For example do you know enough about technology to carry out research with developers to pre-scope extra user requirements.

Can you cope with the give and take that happens during development and know which things to fight for?

12. Finally do you keep your common sense active?

Can you spot a non sensible request, a great example of this was NASA spending $1,000,000 on a pen that would work in space, while Roscosmos (USSR) gave their astronauts a pencil. Can you give a reasoned non personalised argument for not doing something?

Related

Author Links

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

#Lies damn lies and #user #experience

User experience has in recent years become the greatest area of fraud and theft in business. Because the output documents appear simple huge numbers of people without any formal knowledge of what goes into them are having a go.

Be careful of Fakes

Avoid designers, look for Architects and Consultants, with an MSc and good client references (but not a portfolio) which can be viewed on LinkedIn.

The most common request for people involved in user experience is to produce wireframes (low fidelity pictures) a task that a child could do.

Wireframes should be the container document for standards, insights into target audience expectations, business KPI’s and brand values.

Ignorance in UX can be costly

The real problem is that recruiters and clients don’t know what they should be getting for their money.

A good indicator that someone is ignorant is a request for a portfolio. A portfolio is a set of images that express the capability of a designer involved in architecture, graphics, fashion design etc, but it is not relevant for UX. The reason it’s not relevant is that the complex ideas within wireframes need an expert to review and validate them against standards.

People who want to see a Portfolio are incompetent

If the interviewer does not know the standards, frankly they deserve to be fleeced, it’s like employing a plumber to represent your interests in court instead of a solicitor because they can make a good argument. The action of the argument is not important, even if there are lots of buzz words included because legal matters like usability matters are complex interrelated sets of rules and dependencies.

So unless an expert does the review the activity is pointless, a secondary but probably more damaging problem is ownership, rights and breach of contract.

Wireframes contain information on “How it Works” not “How it Looks”

How something works is the inventive element and belongs to the client. If clients are not protecting their Intellectual Property in UX, they really should be quite aggressive about it, but all contracts have a provision for this protection asking to see UX work from clients is a breach of contract and breach of IP.

Asking people to show a UX portfolio is asking people to breach their contracts.

If you or your team require training on interviewing UX people please contact me.

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