Interaction Design: The Process of Lean UX

When we talk about interaction design, we have to still talk about web and graphics design as its origins go way deep into these two areas until when it grew into the realm that it is today. It’s way more than just another way of working with text and pictures.

It has gone to the production of virtually all the elements that you can find on a screen when you swipe, click, tap and every other form of interactions or experience.

Interaction Design is known as the structure and behavior of interactive systems. Its goal is to create a meaningful relationship between the products and services that the people use irrespective of the devices they use.

The world of interaction designers is constantly evolving as well. It has evolved from where it was in the past where it intersected and overlapped with experience design to creating interactions between the people and the environment.

Interaction design is different from user experience as it only concerns itself with specific interactions between the user and the screen they are accessing it on.

Lean UX, on the other hand, is focused on the experience under the design with less interest on deliverables as compared to traditional UX. It’s more of a team work endeavour and it focuses on obtaining feedback from members of the team so that a quick decision can be reached.

“Lean UX is more focused on quick product iterations and team work, rather than traditional deliverables.”
— Kara Tan

Lean UX came about because traditional UX techniques often fail when development is conducted in shorter bursts which often leave the designers with less time to deliver the UX in the same design.

Lean UX requires Assumptions

With traditional UX, the project is built on requirements capture and deliverables with an objective ranging from how to ensure the deliverables are as detailed as per required to respond to the requirements laid down at the start of the project.

Lean UX, on the other hand only seeks to produce changes that can improve the product immediately. It’s not concerned with deliverables. What we do when using Lean UX is to ditch the requirements and use a ‘problems statement’.

An assumption is a statement of something we think is true and they are designed to create a common understanding around an idea so other members of the team can get started.

Even though it is agreed, that assumption may not be correct and could be changed during the project as the team gets more understanding as the project progresses.

Assumptions are generated on a workshop basis. You get the team together, state the problem to be solved and allow them to brainstorm by providing an answer to the question. Some of the questions that might be generated during this stage include – who our users are (or use personas), what the product is to be used for when it’s to be used, the situation it is to be used in, most important functionality and the biggest risk to product delivery.

With a team, there might be more answers to these questions than meets the eyes, in such case, the team will have to prioritize the assumptions following their generation or by the risk they represent (what are the consequences of these being wrong and how severe will the consequence be when it occurs?) The level of understanding of the issue is also appropriate to be looked into.

Hypothesis In Lean UX

When we create hypothesis in Lean UX, we are trying to test our assumptions and the process is quite simple and straightforward. First, we state the belief and why it is important and to who. We then follow that up with what we expect to achieve.

Once this has been settled, we follow it up with what evidence we need to collect to prove that our evidence is wrong. Along the way, we might feel that there is no way to prove our hypothesis or that we may be heading in a wrong direction because we haven’t taken time to define our outcomes.

A major advantage of working with this process is that it is quite mathematical and logical. There is no way you will hear statements like “I don’t think this will be a good idea” or any form of political fighting during the process.

Every idea will be tested based on merits and evidence to determine whether or not the idea should be dropped for something else. When a hypothesis is understood and the expectations from it are very clear, the team tends to be happy to wait to see if it’s true rather than debating from a subjective viewpoint.

Jeff Gothelf once assembled a team that conducted an experiment with the aim of merging Agile/Lean and UX. What they found out was shocking. Their experiment led to an increase in the productivity and efficiency of the UX teams and this was directly influenced by Lean UX.

During this same period, they also found out that Lean UX is the best way to go for designers as it allowed them to open up UXD process for non-UX individuals as well.

Lean UX believes in getting the job done even when the documentation does not have a perfect design. The reason why you need to be sure before you go ahead with Lean UX.

Lean UX teams are set up as cross-functional teams where everyone can share their ideas and critique to other members of the team. At the end of the exercise, they will have a large repository of ideas and this kind of early team involvement is good for creating a sense of ownership on team members.

The team will be able to create features and put the app on the market to ensure that users are exposed to it and can get feedback as soon as possible.

So what are your thoughts on Lean UX? Are you already working in cross-functional teams or are you making the transition right now? Let us know!