How to Incorporate User Experience in Organizations

Last month Keikendo presented a model to identify the maturity level of user experience within an organization. We call it the Keikendo Maturity Model and is the result of over 10 years experience shared by Keikendo founders in organizations of different types, sizes and markets.

While each organization may have goals, processes, techniques and teams with special characteristics, in terms of user experience we have seen similar situations regardless of the type of organization.

Such situations can be described from the barriers to the adoption of user experience within an organization. The model describes 20 barriers clustered into 5 levels:

• Unintentional
• Self-referential
• Expert
• Centralized
• Distributed

It is highly feasable that the 20 barriers do not cover all situations in all organizations, but the most common. They are a sort of average of the most common situations, and each organization may add those applicable to it.

In this article I will describe only the most common barriers that occur at each level, along with the tools that I consider most powerful to overcome them.

1. Unintentional

• Level description: for organizations in this level user experience isn´t designed proactively but is a consequence of certain business goals and IT constraints. Generally speaking, there are no resources with knowledge of user experience or with the intention of incorporating its processes or technics.
• Common barriers: unknowledge and rejection.
• Tools: formal training (courses, events, etc.) or informal (internal presentations, lectures, etc.)

2. Self-referencial

• Level description: at this level organizations design products as if users were like them. Users are fictionally made up, often idealized, but they don´t really participate in the design process. UX can begin to be part of the organization´s public communications but in general it is no more than an slogan.
• Common barriers: budget, time and resources constraints. 
• Tools: user testing is the most powerful tool for overcoming resistances of this level. When observing real people using a product or interface, many preconceptions fall apart and it is possible to discover where and why they are failing. 

3. Expert

• Level description: at this level emerges one person or small team within the organization with concerns about user experience. It is possible that a new technique has been applied, at least once, which usually is user testing.
• Common barriers: formalization, expansion and deepening of the process. The UX technique that has been implemented can not be a consistent part of the design process. On the other hand, it is difficult to replicate it in other projects and even incorporate other complementary techniques.
• Tools: quantification of user testing to measure results and compare projects where UX techniques were applied to those who were not.

4. Centralized

• Level description: organizations that are at this level have a user experience team consisting of at least three roles: interaction design, information architecture and usability. Several UX techniques are applied and user testing is a consistent part of the design process.
• Common barriers: issues are related to UX team scalability. The value of UX has increased and different departments within the organization ask for more resources and better skills but it is difficult for the UX team to meet these demands. Generally this is because UX still is an internal service instead of a strategic area with its own budget.
• Tools: in this level is very important that UX metrics are linked to KPIs (Key Performance Indicators) and expose the impact that they have.

5. Distributed

• Level description: User Experience is an strategic area of the company at the same level of Marketing or Finance. UX is part of the organizational culture and participates in the phases of discovery, design and development for products and services. 
• Common barriers: barriers usually show up in the consolidation phase of UX as a strategic area of the organization. In general they are caused by generational issues and unknowledge of senior executives, including the CEO. 
• Tools: show how User Experience improves ROI (Return On Investment).

Maturity progreses one level at a time, organizations can not skip levels because each one of them requires the integration of knowledge, skills, specific profiles and changes at the internal processes that can last years.

To achieve higher levels of maturity (4 and 5) are two important changes have to occur within organizations:

• Organization goals
• Power balance

The first one involves incorporating new variables in the economic and financial business ecuation: focus on users. The product and service development cycle changed, the organization begins to think about the design of products with users in the center of the process, actively involving them from discovery and research phases, to design, development and support. The organization understands that users are the most important variable to achieve their business goals.

The second issue requires changes that affect all organization levels particularly middle management and directors including the CEO. It entails the participation of users into the decision-making process, which is a situation that could limit management control. In organizations with a personalistic management culture this can be difficult and requires gradual changes that would have to be always supported by positive results.

For each of the described levels there are tools that can overcome barriers. The contributions of the Keikendo Maturity Model are that it provides a map where each organization can be located throughout the identification of symptoms of distress, and to provide an action plan to incorporate user experience in order to improve business results.

5 things you need to have in mind when moderating a usability test.

Moderating a usability test may seem a simple task. When viewed from the outside, it appears that the moderator is simply talking to the user and taking notes, and that folks is something that anybody can do.

However, conducting a usability test requires special skills that must be combined and put into play concurrently during each session.

The five logging levels

We could say that there are five levels or channels on which the test moderator acts:

• Conversational level: it is an active mode and consists of what the moderator tells to the user.  Usually it is based on a predefined script with the scenarios and tasks for the users. Special attention should be paid to how the moderator says what it says, because his words could influence user behavior.
• Listening level: is an active-passive mode and is listening to what the user says and how he says it. In particular it is important to be aware of how the user named concepts or interface elements.
• Observational level: is a passive mode that consist of observing user behavior, what the user does on the interface and also his/her nonverbal communication: gestures, posture, facial expressions, movements, etc.
• Environmental level: the moderator is the highest authority in the room in which the tests are performed, and is also responsible for creating an environment where the user feel comfortable and can concentrate on the tasks requested. This includes from offering something to drink for the user, to assure that the other people present in the room (assistant, observer, etc.) do not disturb the user.
• Timing: This is the most difficult skill to obtain. It is knowing when to leave aside the script to investigate a particular aspect of what the user has done or said. What to inquire, in what way and to what extent are decisions to be taken by the moderator while the test runs. 

The more control is gained in each of these levels, the tests will have more depth and accurate results about what happens to users while using a product.

Finally, the only way to master all levels is training, which means making hundreds of usability tests and after each one wonder what could have been done better.

What Lean UX really means for UX professionals?

Lean UX is a concept that has been going around for a couple of years. Does it really means  something new to the field and professionals of UX or is just another way of naming what we are already doing?

Jeff Gothelf, one of the dominant voices in the movement, defined in an article Lean UX  as "the practice of bringing the true nature of our work to light faster, with less emphasis on deliverables and greater focus on the actual experience being designed.

Jeff is right when he suggests putting less emphasis on deliverables. Over the years, User Experience professionals have created a long list of documents with which often we torture our clients. In a quick mental review I could mention:

• Heuristic evaluations
• Personas
• Usability tests
• Iterative prototyping
• Mind maps
• Concept maps
• Sitemaps
• Wireframes
• Storyboards
• Scenarios
• Content inventories 

And so on. For many years it was necessary for us to create this corpus because our disciplines needed techniques, tools and deliverables that position themselves against others. But in the process we lost focus on our customers to whom we spoke an incomprehensible language or at best very distant to his, the business language.

Does Lean UX means that we should not create more deliverables?

No. Lean UX means to me a process for designing products and services that progressively, quickly and efficiently can refine the value proposal for users.

This definition does not include the deliverables as a core concept of what is or is not Lean UX, because often the generation of specific deliverables (although not directly linked to product design) is necessary to achieve the project objectives.

Let me explain this: in the context in which startups move, where Lean UX has its maximum applicability, one of the most important milestones is to raise capital. To do this, entrepreneurs need some kind of documentation (eg. usability testing reports) to investors to justify the need for more money to polish defective product areas or even rethink it completely .

The origins of Lean UX

Most of the concepts behind Lean UX arised with the Lean Startup movement, which was based in Lean methodologies, a particular type of agile processes. The Lean Startup movement was founded by Eric Ries and is based on five principles:

• There are entrepreneurs everywhere
• Entrepreneurship is administered
• Generate validated knowledge
• Innovation measurable
• Process Build-Measure-Learn (build - measure - learn)

Lean terminology, new names for old processes

Although the terminology used by Ries and the Lean Startup movement is different from the one we used as UX professionals, is closely related to processes or techniques we use frequently:

• Generate validated knowledge: is nothing else than doing user testings to obtain information with the purpose of validating the assumptions made during the design phase of a product.
• Measurable innovation: means taking metrics when testing with users, which perfectly could be typical usability metrics (effectiveness, efficiency and satisfaction).
• Pivot: is one of the central concepts of Lean terminology. Describes the possibility of changing the course of product design based on knowledge obtained in usability tests.
• MVP (Minimum Viable Product) is what we call a testable prototype.
• Customer development: refers to leaving the cubicle and researching the way users use the product in a real context. It's what we call fieldwork either participant observation, contextual interviews or contextual surveys.

The Lean work process is iterative

The work process suggested by Eric Ries and called Build-Measure-Learn is an iterative process as commonly used in projects of User Centered Design:

What brings Lean UX?

Lean UX brings two changes that I consider interesting for the UX  field :

• A new way of communicate what we do: for many years UX professionals have spoken a foreign  and boring language for business people: "Usability Testing" "Heuristic Evaluation" "Personas" "Mental maps" are some of the strangest and abstract words ever invented. By contrast, the terminology proposed by Lean UX is much closer to the language used within an enterprise, and allows a better understanding and a connection with what we do and the results demanded by the business.
• A refocus of our work: Lean UX proposes to focus on the two most important partners of our iterations: business representatives and users. We must act as interpreters between two actors that at the begging may seem strangers but at the end must become best friends.

What means Lean UX for user experience professionals?

Working under Lean methodology requires some changes to the professionals capacity to deliver better results. Among them:

• Better understanding of the business: this is perhaps the greatest deficit of designers and developers who are well trained in the technical and operational aspects of their disciplines but often lacking and resist the business vision, and results orientation.
• Increased flexibility: the thoroughness that apply certain UX techniques can often make it more difficult to provide rapid and valuable inside to the business. Working with hybrid techniques is a possibility to avoid this.
• Higher speed: means to do all this faster.

Why users are reluctant to provide their Facebook or Twitter permits?

In many of the projects we've been working on recently, we found that asking prematurely for Facebook or Twitter permits motivates drops on conversion rates.

This situation is very similar to what happened 10 years ago when eCommerce web sites requested registration as a first step in order to make a purchase. There were also worst cases, like requiring registration for using basic functions such as the search engine.

Fortunately we overcome this stage: Today most sites allow a full purchase process without the need to register or do so in the last step, for example, when the shooping cart is complete.

However, the bad habit of asking the user data before they are needed or even when they are not necessary remains. Today the most common example is to ask for Facebook or Twitter permissions in order to use a website or mobile application. For many users this represents a strong barrier that they are unwilling to overcome easily.

Why users could be reluctant to give Facebook or Twitter permissions?

The main reason is the mistrust, so the key to prevent drops in conversion rates or early leavers is to design strategies for building trust.

Among the most effectives are:

• Allow the user to test the product without having to accept permissions.
• Express, in a way that the user can clearly perceive, what is the value proposition of the product.
• Communicate what will make the application or site with the user data.
• Communicate the benefits or enhanced features that the user could access if he accepts permissions.
• Virality: show the user's contacts that already are using the application.

How to create a shared understanding among development teams and clients.

In addition to allowing the detection of usability issues, user testings are instances to build a shared understanding between team members and clients.

This understanding is built progressively at each iteration during the project. The first step on that path is to get rid of the notion of self-referential design.

What is self-referential design?

Self-referentiality is an immature stage that design and development teams go across characterized by the belief that  users are the same as those who design the interface.

During this stage the product decisions are made based on what each team member:

• Knows
• Likes
• Thinks is good
• Has been told is good
• Has seen elsewhere

The problem with this situation is that it usually produces cyclical discussions based on personal opinions rather than observed facts. This can severely erode relationships and generate significant roundabouts in a project.

Testing with users provides information based on what people actually do when they use a product. Thus,  personal opinions are set aside and relegated because of the evidence surveyed during observation.

Implementation phase

The second instance where user testings are valuable for building shared knowledge is when the project enters the implementation phase. During this stage, technological constrains fully manifest, either by the chosen platform, implementation schedule or other external processes that affect the product.

Many of these constrains lead programmers to make decisions that end up modifying the interface. Usually this is solved with documentation (costly to produce, always incomplete, and that nobody reads in full) or through team meetings that try to build consensus through fragmented views of the product.

In this moment, user testing brings back the focus on what is important for end users and gives factual information to understand the impact of technological restrictions.

Build a shared knowledge with the client

Sometimes organizations have strong opinions about the characteristics that a solution must have or what  users need. Often these opinions are not based on factual information about users and what they actually do with a product or service. A frequent cause of this problem is the use of innapropiate survey techniques for  interface design, such as, focus groups.

There seems to always be a gap between the organization's goal and what users can or are willing to do with a product or service. Therefore, the participation of the customer during testing sessions is essential, as it allows to know which part of the organization's vision is validated by the user behavior and what part need adjustments.

Frequently it is hard to convince customers of the importance of participating in user testings because, user testing is mistakenly considered a technical issue and not relevant. However, the effect of witnessing user testing sessions is not comparable to reading a report with a few static slides summarizing results, and prepared by a third party.

Benefits of involving clients in usability testing sessions:

• Dispel suspicions of manipulation or error in the results.
• Generate less documentation.
• Get consensus on the main problems to be solved.
• Develop new hypotheses to solve those problems.

It is important to note that any observers participating in user testings should be present in most of the sessions, following the rule of that the smaller the number of users, the greater the number of tests that must be witnessed (seeing only one or two tests can lead to wrong conclusions).

For example, if you have decided to test a total of six users, observers should be present in all six of them to correctly identify behavior patterns and not draw conclusions based solely on a couple of observations.

Why a Focus Group shouldn't be used to evaluate usability.

One of the techniques most commonly used by companies and their marketing areas for audience research is the focus group. This technique is characterized by gathering a group of people (not more than 10 or 12) representing a potential customer segment aimed at a particular product or service to ask for their opinion about the characteristics of that product or service.  

Some of the questions that attempt to be answered by a focus group are whether consumers: 

• Would buy a product or service
• Under what circumstances.
• If they like the product or not.
• Why would they choose one product instead of another?
• If they could change something: What would it be and how would they do it?

Focus groups are useful research tools when you want to know opinions of people, their motivations, and expectations for a product or service. 

The main mistake committed in relation to focus groups occurs when opinions expressed by participants are confused by their behavior, that is, what they would do in reality. 

When we need to know what people do or how they use a particular product or service focus groups fail and can be misleading and costly: 

To cite another example, in the book "How Customers Think" Gerarl Zaltman mentions a study where 60% ​​of the people who tried a new kitchen in the context of a product presentation, said they likely or very likely would buy the product the following three months. After eight months, only 12% had bought it. 

When we need to know what people actually do, rather than say, we must observe how they use a particular product or service. In the field of user experience there are two techniques that allow us to find this:

• User testing
• Contextual survey

Both techniques analize people's behavior, not their opinions, and therein lie their value.

When you need to evaluate the ease of use (usability) of an interface, the technique used is user testing. This consists essentially of asking a number of people (interviewed individually) to solve particular tasks with the interface. The researcher observes if the task can be solved successfully, and the difficulties the person may have had during the process. 

In this context, the limitations of focus groups are evident: ask a person if he/she thinks that in the near future he/she will have some problem solving a given task is, at the very least, vague, considering the need any of us has to try and experience ourselves to find out. 

The answer to this question in the context of a focus group would be: the person is not forseeing obstacles or problems for solving the task, and that he/she would "likely" or "very likely" perform successfully.

Why User-Centered Design is More Efficient than Waterfall Development Methodologies. (Part 2/2).

Second and last part of this article that addresses one of the main challenges facing User Experience professionals: how to convince our customers to work under a process of user-centered design instead of a waterfall methodology. Based on the same case proposed in the first part of this article here I describe where lies the greater efficiency of the UCD and why.

The user-centered design approach proposes an iterative process for interface development. Each iteration consists of three stages: analysis, elaboration and testing. A project may consist of n number of iterations depending on its complexity. In the center of this process are business representatives and users from whom we obtain and prioritize objectives for each iteration. 

  

Unlike the waterfall development process where a single instance of analysis (at the beginning of the project) will feed the whole process (with the risks involved as we saw in the first part of this article) the UCD contains as many instances of analysis as iterations. At the beginning of each one of them, during the analysis phase, it is define the interface elements to be addressed and they are analyzed in detail.

In the analysis stage of successive iterations, it is possible to review what was found under the light of results obtained in the testing stage. Thus, it creates a virtuous circle of feedback where each assumption is developed, tested and refined.

The User-Centered Design in Action 

Returning to our imaginary project for a mobile application that we have to develop in five weeks (see project assumptions in the first part of this article) we will define each iteration with a duration of two weeks, using one for the design phase and two iterations for the programming phase. The project would take the following form: 

Unlike the waterfall approach, UCD includes measuring performance of the application during each iteration, tackling deviations and therefore reducing project risk. Test instances would be planned at the end of week two (end of design iteration) and then at the end of week three (end of first iteration of programming). However, given that between the first and second test would have only a week and the first test would already be testing some functional elements developed during the first week of programming, we could plan the second test at the end of the second iteration, that is to say in week five.





According to this plan U$S 6000 (U$S 4000 for the two weeks of design and U$S 2000 for the first week of programming) and only two weeks will be required to get a first measurement of the interface performance which is half what was required by the waterfall methodology in terms of budget and 60% less in terms of time.

Three weeks later would be possible to conduct a new round of tests with users before launching the product to the market. This would be the same instance for the waterfall methodology to conduct its own test but in this case it would be the first one.

The quantity of errors and the level of deviation that could be discovered in the second round of test (in the case of UCD) would respond to a maximum of three weeks, while in the case of the waterfall methodology would be five weeks, because no test was performed before.

It could be argued that the project plan we are using is not taking into account the time and cost required for testing and subsequent adjustments. But likewise, none of these things were contemplated in the case of the waterfall methodology, since it is required time and cost to perform the preliminary analysis and documentation that is normally generated in such cases.

The Risk in the Process of User-Centered Design 

Let's see what happens with risk. The two variables we choose to measure risk are, as in the case of the cascade methodology:

• Requirements Specification: the requirements definition for the UCD is performed during the first stage of the iteration and is focused in the items that will be developed during that particular iteration. Each iteration has its stage of analysis and since the iterations are successive, the information that feeds each iteration is every time more precise and accurate as it has gone through a validation process during the previous testing stage. 
• Development time: the time needed to do a measurement of performance and, therefore, to identify potential problems and correct them could be done in the second week of the project, leaving three weeks ahead to make adjustments before launching the application. 

Given these variables, we could draw the risk behavior during the project as follows: 

   


The image depicts how the risk is reduced in instances of user testing, where the assumptions considered in the analysis stage and development process are tested and, if necessary, adjusted.

This prevents that the risk curve grow upward in a straight line from project inception to completion. Instead, it does so in a spasmodic way in each iteration, falling dramatically during test instances.

Waterfall Methodology Vs. User-Centered Design in Brief

• Cost: user-centered design process is on average 35% more efficient than the waterfall methodology due to a better requirements definition and better control on deviations. 
• Time: UCD allows project development without or reduced deviations. In the case of the waterfall methodology time deviation can reach 35% on average. 
• Risk: user testing is an effective risk reducer. Implementing tests during iterations prevents that the risk exceeds the investment required for each iteration (usually two weeks). In our example, the risk was halved in relation with the risk manifested using a waterfall methodology. 
• Measuring performance: UCD requires half the budget that the waterfall methodology to perform a first measurement of performance, which is critical to prevent that the project risk grows as a linear progression. 

Surely this comparative analysis is not complete but the goal of this article is just trying to make a simple analysis looking at the main project variables (scope, time, budget and risk) providing basic arguments that show the advantages of working with a user-centered design process.

Why User-Centered Design is more efficient than waterfall development methodologies. (Part 1/2).

One of the main challenges user experience professionals face is how to convince our customers to work under a process of user-centered design instead of the traditional waterfall methodology. In this article I propose a simple comparative exercise to analyze the economic efficiency of one process and the other.

 

Assumptions 

Suppose we receive a request to develop a mobile application in five weeks. According to the preliminary analysis we have done the project will require two weeks of design that will feed four more weeks of development. The second week of design will overlap with the first development week so the project will last five weeks as requested by our imaginary customer.

The cost of each hour of a designer and a programmer is U$S50 (fifty american dollars) each one of them, so the total project cost could be estimated as follows:

• Design Tasks: 80 (hours) x 50 (dollars) = U$S 4000 .- (four thousand dollars) 
• Programming Tasks: 160 (hours) x 50 (dollars) = U$S 8000 .- (eight thousand dollars) 
• PROJECT TOTAL: U$S12.000 (twelve thousand dollars) 

Risk Estimation 

The risk can be estimated in many ways. For the purposes of this exercise was calculated from two variables:

• Risk = accurate requirements definition x development time 

Considering that inaccurate requirements and longer development time result in higher risk.

Waterfall Development Process 

A waterfall development process consists of a series of consecutive stages of work (in this case design and development) until the completion of the project which ends with the delivery of the application according to the requirements defined at the beginning of the project. If we have to draw it in a simple way It will consist of three stages: 

This methodology does not contemplate the possibility of measuring the performance of the application until the end of the project. It is in part because just at that time there will be a deliverable that can be measured and in part because waterfall methodology considers no necessary to measure the performance of a product before the launch of it. In any case, the results may then be estimated by measuring the product performance in the real market once it was launched.

With this in mind we can say that a cascade process for this project would require an investment of U$S12.000 dollars and five weeks of development to know how the application performs. 

The Risk in a Waterfall Development Process

When we add the risk component, previous estimation in terms of time and costs changes substantially. Let's see what happens with the two variables in our analysis that compound risk:   

• Requirements specification: the requirements definitions made ​​before starting a project and not revised later as development progresses contain a number of assumptions that make them inaccurate and sometimes directly wrong. In this regard, Jason Fried and David Heinemeier Hansson quite rightly raised this issue in their book Rework. They pointed out that the moment in which a development team knows less about how to solve a given problem is just before start to solving it. However in a waterfall process is that precise moment when all requirements are defined and after that they will guide the entire development process leveraging risk of deviations because of defective product requirements definition. 
• Development time: The elapsed time to measure the performance of the application and, therefore, to identify potential problems and made adjustments would be during the fifth week of the project, that is in the end, having already consumed all budgeted hours of design and development. 

Considering these two factors, the risk of deviation in a waterfall development process is high. In fact, a recent study by IAG Consulting says that companies defined as immature in requirements definition fail half of the times to reach goals set for an application and require 35% more time and budget to achieve them.

Returning to our example, if the application is under the expected performance (which has 50% possibilities of be the case) the project will require 35% more development time and budget to make the necessary adjustments in order to be successful. This would carry the total investment to US$16.200 dollars and nearly seven weeks rather than the five originally estimated.

This whole process could be drawn like this: 

Now we see the difference between the initial estimates and what really happen as a result of increased risk during the development process as a consequence of decisions taken based on poorly defined requirements.

In the second part of this article we describe how the User-Centered Design avoids these deviations, reduces risk, time and development costs.

Five things you should consider when testing with children.

In one of the last projects I worked on I had the opportunity to conduct usability testing with children between 6 and 12 years old. In this article I present five things you should consider when working with children.  

1. Neutralize preconditions. 

The conditions or biases that children bring to the testing sessions tend to come from two main sources: from their own ability to fantasize and from their parents’ influence. The former is a normal behavior for certain ages, especially for children between 6 and 12. With regard to parents, we must have in mind that they are usually the ones who tell the children what they will be doing during the test and while doing this they might build up expectations or distort the concept of a usability test. 

In order to prevent these I often ask users at the beginning of the test, what they had been told about what they will be doing during the session. Then I tell them my story and try to neutralize the distortions and focus the user on what really matters.      

2. Avoid the word "test".

When explaining to children what they will be doing and what is expected of them during the session you should avoid using the word "test" because it has a very specific meaning for school-aged children. They might relate this with an instance in which they are being evaluated.

To avoid this, we must communicate explicitly that the goal is to help us discover those things we can improve, that their opinion is very important to us and there is no right or wrong answer. We are testing the interface not the users.   

3. Start the routine tests with questions that help to build rapport.

While it is also a good practice when testing with adults, in the case of children, generating empathy is critical. Kids can take more time until they build trust with you, which is needed so that the technique of "thinking aloud" yields its full potential.

To accomplish this you can ask general questions like: what grade they are in, what classes they like and dislike in school, what they do in their spare time or what sports they like the most. Questions should change and should be adjusted according to the child’s age and answers. The goal is to forget for a few minutes that we're doing a usability test and just have a nice chat with them. 

4. Adapt the furniture to the physical conditions of children.

Something that seems a minor detail and is often disregarded is having chairs and tables suitable for children. This has the purpose of making them feel comfortable while using the mouse, keyboard and viewing the entire screen.

This is usually resolved with a good adjustable chairs with armrests.

5. Snacks for breaking the ice.

It is strange to imagine a group of happy children running through the halls of an office or playing at an oval table in a meeting room. Offices are clearly not meant for kids .They are very formal, monochromatic and, in some cases, cold. If tests are performed in a usability lab with mirrors and video cameras, the feeling of being watched can generate even greater self-consciousness.

     

In order to create a friendlier environment for children you can decorate the room with toys, posters and offer snacks. This last item has a special power to get a smile out of children and to break the ice.

How to overcome resistance to the implementation of User-Centered Design.

Incorporating usability techniques and processes of User-Centered Design (UCD) in companies that are not used to working with them can become a daunting task. Over and over again we hear arguments that justify the rejection and invalidate the possibility of change, even if this is minimal. This article describes the most common arguments we hear, and proposes concrete actions to refute the negatives.

Common barriers and excuses to implementing UCD

Over the past ten years, I have had the opportunity to work for companies of different markets and I find that the difficulties and barriers to implementing UCD are quite similar, regardless of the type of company or sector in which they operate.

However, the problems are different depending on the degree of maturity of each company in relation to usability and user-centered design. Taking the maturity model developed by Keikendo (link in Spanish), an IT and UX training company, it is possible to address barriers and common excuses that the design and development teams typically use, and present each one of them with arguments and concrete actions that neutralize them:

Stage of maturity	Common barriers and excuses	Arguments and courses of action
1. Unintentional User experience is not designed intentionally.	Ignorance: Usability and UX discipline is unknown.	Training.
	Rejection: Experience design is considered unnecessary.	Do nothing. They will discover the UX value on their own.
	Incompatibility: The methodology does not allow user testing.	Do usability testing with the finished product to expose the problems.
2. Self-reference Interface is designed as if users were members of the design and development team.	Cost constraints.	With 10% of the total budget of a project you can achieve an 83% improvement.
	Time constraints.	A round of user testing can be completed in one week.
	Lack of specialized resources.	Outsourcing, hire new resources or train existing ones.
3. Expert Based on the experience of one person. There is no method.	No formalized methodology.	Design and implement a feasible methodology, not an ideal one.
	Perception of uncertainty on results.	Quantitative and qualitative assessments during the test.
4. Centralized There is person in charge of experience design. There is a method.	Usability and user experience is required for certain projects, not for all of them.	Use metrics from projects based on UCD and compare them with projects that used other methodologies.
5. Distributed All teams are aware of usability and UCD. There is a method.	Resistance from senior management.	ROI is the keyword: Take metrics and show how the UCD boosts ROI.

Table: The five maturity levels, the barriers and the actions to take.

Specific arguments and courses of action to fight resistance:

Training : Some of the actions you can take when your client doesn’t know anything about usability and user-centered design are providing introductory courses, invite them to professional meetings or even explain the main concepts at informal meetings.

Choose your battles: The arguments heard rejecting UCD range from “boring” to “not necessary”. Whatever the case, it is not worth spending too much time convincing naysayers. The impact of UCD on business, the final quality achieved for a given product, and improvements in customer satisfaction are explicit benefits. Being against UCD is based mainly on dogma than reason.

User testing: In addition to being one of the main techniques of UCD, user testing is a powerful realization tool. It is important to involve design and development team members, and even invite managers and stakeholders to the usability sessions.  Watching and listening to users has a magical effect on those who continue to oppose to this methodology.

Comparing costs: In order to dissolve the excuse about costs, just demonstrate what the cost of not using a user-centered design methodology would be. The UCD is more efficient than other methods and reduces costs in development, maintenance, training, and support.

Prioritizing with time constraints: UCD allows for prioritization initiatives.  When time is short it is very important to decide which tasks should be carried out within the time available to obtain the best possible results. A round of user testing with just five users allows identifying most of the usability problems of any interface and can be done in one week. At the end of just one round, valuable information is gathered to support future design and development decisions.

Relying on experts: If the project is important for the company don’t hesitate to hire a consultant o a UX agency. In addition to solving the problem, the company can learn from them during the process.

Remove barriers related to the methodology: The process of UCD is not dogmatic.  In fact, it is considered one of the so-called agile methodologies, defined as a process rather than a structured methodology. This allows greater flexibility and adaptability to the requirements of each specific project.

Reducing uncertainty: The best way to generate certainty and reduce resistance to the adoption of user-centered design is to show quantitative and qualitative results from using this method. This involves measuring key variables of each project. The three most common variables are: effectiveness, efficiency and user satisfaction.

Break the resistance of stakeholders: From a business perspective it is more convincing to use metrics that feed into the traditional equation of a successful Web site: I = V x C x R, where:

• I: Income
  V: Number of unique visitors
  C: Conversion rate
  R: Return rate

What is contextual inquery?

In the user experience field, user research is taking more and more relevance. Contextual inquiry adds useful information about the way people interact with products. To know the real context of use allows development teams to create more friendly, adaptive and innovative interfaces.

 

Contextual inquiry is one of the techniques used in user-centered design with the purpose of knowing the context of use for a given product (software, device, Web site, app, etc.) 

What is the context of use?

The context of use is the real and specific situation in which final users (people) use a product.

Why it is important to know the context of use?

The context of use define the way in which a product or interface is used. The context of use is not the same for a mobile phone application than for desktop software. In the first case, it is possible that the user is moving and performing other tasks while using the phone, tasks that might require interaction with objects, people, and situations that exceed interactions produced within the phone interface itself. In the second case, the user might be sitting at his desk most of the time with the screen front him, a keyboard and a mouse. Clearly, one type of interaction is very different from the other.

How is contextual inquiry done?

The methodology of a contextual inquiry has a lot of anthropology. In fact, it could be considered derivative of participant observation, a methodology used in anthropology where the observer (consultant) goes into the daily practices of a given group of people (users) with the objective of getting to know their every day practices, in the context in which they are pursued, and with what purpose and motivations.  

Adapted to user-centered design methodology, the participant observation or contextual inquiry consists of observing users, one at a time, in a real and daily situation in which they use a given interface. Specific questions could then be asked in order to better understand what the user has done and why.

Participant observation sessions have three different stages:

• Introduction: the user is told what is going to be done and with what purpose. It is very important to generate empathy and create an atmosphere of confidence with the person to avoid bias during the observation process.  
• Observation: consists of taking notes of the users’ actions and the context in which they are developed. During this moment it is not convenient to interrupt the flux of actions with questions but rather to concentrate in practices that take place.
• Questions: this is the moment for asking questions about what was observed. The user should interrupt (if possible) his/her tasks to respond to any doubts that the consultants could have.    

Planning a contextual inquiry

The steps that should be followed to perform a contextual inquiry are very similar to other methodologies of user research. Nevertheless, it has its particularities. We recommend the following steps:

1. Research of user profiles.

2. Research of critical tasks for each profile.

3.Research of the product (software, application, Web site, device, etc.)

4.Definition of the script for observations.

5.Definition of the schedule (facilities, time and dates)

6.Recruitment of users.

7.Development of observations.

8.Analysis of the collected information.

9.Elaboration of reports.

10.Presentation of findings.

The challenge of contextual inquiry

The process of observing users interacting with a given interface and with their context could provide with insurmountable amounts of information that are difficult to process. The challenge is centered in indentifying the relevant information regarding the research objectives. This which could be seen as a very simple task requires of considerable experience from the consultant team in charge of the process, especially to arrive to solid-based conclusions from the observations conducted.  

Usability Test.

IS A POWERFUL DIAGNOSTIC TOOL TO IDENTIFY USABILITY PROBLEMS, BEFORE A WEBSITE IS PUBLISHED.

The usability test is an analysis of key aspects of an interface (website, software, mobile application) through experience and direct interaction with its users. The purpose of usability testing is to reveal usability problems and suggest recommendations for their solution, optimizing the interface, improving the user experience and consequently the chances of success of the interface. 

If the experience of users with an interface is frustrating, the impact will affect the brand, the company and the product or service in question. No matter how many analysis were made ​​during the process of building an interface, experience shows that there are problems that only appear when the interface is tested with real users. 

Why? Because an interface is developed by designers, programmers, marketeers, etc. but not by its users. You need to know what is the profile of users who interact with the interface, what are their goals, context and situation of use. An interface is always accessed with certain objectives in mind, which can be classified as follows:

• Information: when a person want to know the market price of a particular product before buying it; or read the news of the day; or know the exact amount of square kilometers China has.
• Playful: as a way to enjoy the free time to socialize, entertain and play.
• Transactional: when it is necessary to interact with an interface through a series of complex operations to obtain a certain result.

In addition to these objectives there are contexts and situations of particular use. For example it is not the same a six years old child navigating from his home, than a teenager going home and using his/her smartphone, or an adult who is connected from his/her office. The most common contexts of use are:

• Home
• Office
• Mobile

In the past two years we have seen a boom in the mobile field. Mobile connections emerged thanks to technology development that has personal connectivity to mobile phones as the main engine, and definitely is the context that will prevail in the future. 

From the combination of users objectives and contexts of use on one side, and demographic audience analysis on the other, accurate users' profiles can be built. 

With a good description of users' profiles, you can make the recruitment of individuals who will perform the tests, and then select a set of critical tasks to be performed on the site that is being tested. 

Some examples of these tasks can be: suscribe to a newsletter, buy a product, arrange a travel itinerary, or check movie listings. 

Difficulties, expressions of discomfort, as well as positive insights are collected from users while they perform tasks. The usability analyst takes notes and then evaluates each problem in order to categorize it according to type of error. 

Test results constitutes the raw material for recommendation reports with a number of changes to improve the overall experience with the interface.

Usability test provide short and long term results. The immediate result is a list of general recommendations to improve the site. The long-term benefit is a better understanding of how to design more usable products from the information obtained from  users. In addition, a usability test provides the following benefits for developers:

• Reduced production costs: the costs and time to develop an interface can be reduced by avoiding overdesign and reducing the number of subsequent changes required in the product.
• Reduced maintenance costs and support: the systems that are easy to use require less training, less support for the user and less maintenance.
• Reduced costs of use: better usability increases productivity and quality of actions and decisions; users can make a more efficient use of their time and operate the system as a whole.
• Improved product quality: the user-centered design process allows the production of better products in a market that demands easiness of use.

In short, usability testing is a powerful diagnostic tool for finding usability problems in interface design. Correcting these problems will lead to better user experience that will impact directly on the brand, product, service, and company.