Agile framework is rapidly becoming the backbone for the companies delivering new features in quick bursts. However, during the development cycles or sprints, most of the time is still consumed in the design process - gathering user requirements, researching and finally documenting everything. This gets even worse when your team spends months in documentation of the everything, but just before the beginning of the actual development phase, the requirements change or the research conducted several months back gets obsolete. The result? - Your team has to start from the square one. This is where most of the companies, produce lots of waste that costs both time and resources.
Lean UX, based on the foundation of Agile development, is a user-centric approach that focuses on reducing the waste produced during the design cycle, and enhancing the UX through multiple iterations without spending much time on documentation.
Too much to digest? Lets dive a little deeper!
What is Lean UX?
As stated above, Lean UX is based on three main phases - build, measure, learn.
Just like the first time cooked dish is never perfect, Lean UX assumes that the first design of a product will always be wrong. This is the reason you should not spend much time in documenting your research, instead you should release a minimum working product developed using minimum resources and then start collecting the feedback from your users. Analyze the feedback and then make necessary changes to the product and repeat the process again. Just remember one thing! -
Your wireframes or research documents will not solve the problems of your users, but your product will.
Collaboration - the backbone of Lean UX
For a moment, just recall this image of a dress that went viral few years back just because different people viewed it in different shades. This is very small example, proving the point that different people bring different perspectives along with them. This is the reason companies like Google, Microsoft, Apple, etc. hire people with different cultural backgrounds.
Lean UX highly recommends the collaboration of the entire team while solving a problem. Let’s take another example, who do you think knows your customer better you or the person spending 8 hours a day to solve user queries? Obviously your customer care executive but this doesn’t mean your views have less value. Each member in the team should be given an opportunity to present their ideas on the problem being solved. The best portions of every idea should be collected and further worked upon. This will help your customer care executive to bring up the issues your customers are facing during the initial design process. Also, it will help your marketing team to get prepared for the new features coming up in your next release. Moreover, developers can start working on the architecture of the new updates and during this time your design team can finally work on the prototypes.
Collaborative approach not only bring different views to the problem but also initiates the parallel processing of the tasks within the different departments of your team. This parallel processing of tasks improves efficiency and reduces delivery time. And in case you have large team, try to divide the team in smaller sub teams with a member from each department in each of the smaller teams.
While forming collaborative teams never hire a self-centered ninja. This is because, people who are egotistic often avoid feedbacks and this hampers the motive of collaboration in Lean UX.
Design Cycle with Lean UX
As mentioned earlier, Lean UX starts with finding solution to the problem and then measuring the feedbacks and enhancing the previous solutions based on these feedbacks.
Problem Statement & Assumptions
As I mentioned in 4 Common Mistakes UX Designers Should Avoid During Product Design Process, whenever your team encounters a problem statement, focus on “Why” and not “How”. This will guide you to form assumptions.
An assumption is formed out of the given problem and is assumed to be true. Each individual of your team (collaborative) comes up with their own solution to the given problem out which assumptions are created. These assumptions can be based on the answers to - the type of users who will use the product or situations where your product will be used or uncertainties that might hamper the use of the product and so on.
Diverse teams will be able to come up with multiple answers to the above cases. This suggests the need of prioritizing the assumptions based on - the level of knowledge of the problem you have and the level of consequences that might occur in case the assumption goes wrong. Assumptions with high risk associated with them or the ones, your team has little knowledge about have high priority.
Also, it’s quite obvious that, the assumptions can prove to be wrong at some time in future but they can be changed whenever it happens.
Hypothesis
After brainstorming on problem statements and amalgamating different ideas from your team members, you create hypotheses. The hypotheses are used to test your assumptions.
As stated by Interaction Design Foundation, you state a belief, its importance and the personas it is important to. Then you talk about your expectations and a final result that will prove your belief.
For example, “We believe adding one click signup using Facebook will be a useful feature for busy users who have Facebook account as it will save their time. This will increase our user signup rate by 20%.”
In the above example, belief is adding one click signup using Facebook will be useful; personas are busy users who have Facebook account; importance is will save user’s time; expectation is will increase our sign up rate; and result that will prove belief is increase signup rate by 20%.
One of the positive aspect of writing hypothesis is you can conclude that you are heading in the wrong way if at any time you are unable to find any way to prove your hypothesis.
MVP (Minimum Viable Product)
After your team completes the hypotheses for the assumptions, you start with the Minimum Viable Product or MVP.
According to Wikipedia,
MVP is a product with just enough features to satisfy the early customers and to provide feedback for future updates.
This definition brings us back to where we started - build, measure, learn. You build a MVP using all the ideas your team brainstormed and the hypotheses created, then ask your users for their valuable feedbacks and finally, use those feedbacks to update your assumptions and eventually the product.
MVP doesn’t just comprise of few features but instead, it comprises of some features that are usable, solve the problems of the user and have some UX attached to them.
MVP can also be a Low fidelity (Lo-Fi) prototype for example, paper prototype or digital prototype which your users can interact with and view different screens as a result of there actions.
Conclusion
Lean UX can be very powerful for the teams with little resources and can also be beneficial for the teams which want to maximize their output and reduce wastes. It goes hand in hand with Agile development framework, thus making it very smooth to adapt in the current system. More about feedback and testing.