How to detect Cognitive Friction on a mobile application?

Question

I'm researching Cognitive Friction on my thesis and it's the resistance encountered by a human intellect when it engages with a complex system of rules that change as the problem changes as Alan Cooper stated first. I'm also open for a better term if it's exist, but my main point is detecting this bad part of UX.

Even I'm mostly interested in detecting the subject in an academical manner, I'd also love to learn all practically applicable ways besides you think useful to be tried out. I found out there're only 2 works not directly studying but academically using this topic:

The Fiction of No Friction: a User Skills Approach to Cognitive Lock-In

Irritating CAT Tool Features that Matter to Translators

Note: There's been no scale developed for this topic yet. Since I have to study the topic on an existing mobile application which does not belong to me, I'm framed with the idea of creating scenarios for users and apply it in a laboratory to observe them where eyetracking possible. I'm either doubtful about eye tracking because it would not provide any direct detail about user's exact state of determination or failure in this situation.

So to be able to measure the users more accurate, I have evaluated a model below in the order I planned to present. Besides commenting what to avoid, I'll appreciate if any other ways you suggest to detect it on products and measure the effecs of the cognition related to user experience;

1. I'm planning to make users rate the overall User Experience of 3 randomly chosen mobile applications with a pre-defined UX scale

2. Then make them use and rate the same scenarios for each application to score more accurately.

3. And last, making further survey with the lower-graded-scenarios to detect for any cognitive friction.

Answer 1

It might be helpful to select a UI or feature that use anti-patterns (patterns/interactions that have unexpected results) along with UI/features using typically successful patterns. Have the users perform a task, such as to click on something, or to try to find something in a website/application, and then rate that task as soon as they're finished.

For instance, ask a user to get back to the home page of a website/application. A typically successful pattern would have a "Home" link, or allow user to click on the logo to get back to home. An example of an antipattern would have a logo that was not linked to the home page, or possibly linked elsewhere. Show 3-5 UIs with a mix of good and bad patterns for each task. Record the rating of each task. Ask open-ended "why did you rate it that way?" "What did you expect to happen when you did xyz?"

Is that the sort of experiment/test you were looking for?

Answer 2

I think I would consider cognitive friction as anything which gets in the way of a user completing their goal.

In terms of the goal and application that's for you to decide, but beyond that, there are many different areas you could look at.

For example, workflow / process could be a sensible start point. How many steps must the user complete to achieve their goal? is it optimal given the constraints in play. Is there a reason to reduce or increase the steps?

Perhaps beyond that, you could look at ontology / terminology, does the user understand how to complete their goal given the content which is presented? Consider language vs the users understand (e.g. Server error 500, vs "something went wrong") or cultural issues (delete vs trash etc).

Obviously you then have the design aspects, such as the gestalt principles and how they are used an an app and whether that helps. This would extend into lots of the laws of UX.

The real answer about what cognitive friction IS and how to measure it, is basically the premise of a lot of UX and or design in general.

Answer 3

Cognitive friction happens when the application doesn't follow the correct mental model. In general, it's hard to fail in obvious/de facto solutions (e.g. back button sends you previous page/state all the time, hamburger button opens the main menu). For these problems, doing research is unnecessary but the ones that swim in grey waters can be applicable to run research.

IMO, these three apps should provide the same experiences with different patterns that prevent the user from doing her/his job and slow down the process. Because actions result in wrong consequences and fail the user's expectation, you can reach tangible results by measuring time to respond to each action, giving up and quit time.

Answer 4

The semantic issue you're encountering is bullshit (as a technical term), or euphemism.

Euphemism is the most gentle means to describe ”cognitive friction" as used to describe any mobile application user experiences. In any truthful discussion, it's going to be called what it is, it's bullshit.

The presumptions that lead to the use of this term (and lay at the failings of most modern software) are that programmers and poor designers can create on behalf of atrocious leadership, and are entitled to success. That they are heading in the right direction and that only [insert blockage] and success stand between their endeavours and success.

Compounding this delusion is a common canard, that at the point of success (or well on the way there) users will no longer resist (the friction part) the nature of the required interactions and the underlying endeavours of the software; that the users will become programmed to use it in accordance with the software’s programmers.

There are a few exceptional examples of users having become well programmed and putting up with atrocious experiences against their best interests (Windows, Facebook and WeChat the three most extreme). Their financial success has lead some to believe that software is, therefore, an industry.

Combine this with the types that self select for this type of “industriousness” and their general hubris, arrogance, delusion and other forms of naivety deem them and their ideas worthy of creation. This, in turn, leads to many lustful, envious and opportunistic/exploitive greed driven swine to rationalising belief it's possible and inevitable for them, and their endeavours, to be successful, too.

Once this is understood, it’s possible to consider their efforts and endeavours on their merits, inclusive of analysing effort and reward. Filtered for truth and virtue, results default to fitting users and usage, wherein form equals function and success is inevitable. Any failure of the filtering leads to efforts to make crap.

Within this context, and from this perspective, it’s possible to see that “cognitive friction” is a euphemism designed to obscure the truth, that the user is suffering a form of “cognitive dissonance” brought on by their experience of interfacing with something purporting to do and be one thing, but doing and being something else. This is scary to those creating the software because it might force them to acknowledge that what they’re making is crap.

If you replace “cognitive friction” with “cognitive dissonance”, you’ll see what’s going on. Then you’ll soon realise your endeavours will only lead to the truth, the realisation that those discussing things like this are bullshitting themselves about what they’re doing and what their users are experiencing.

Having achieved this enlightenment, you'll know that you need not detect "cognitive friction" in users, merely understanding the endeavour will reveal its inherent degrees and ranges of dissonance.