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.