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.