There are many times that we have a very good idea of digital product (mobile app or computer) and we do not know where to start, we want to get a new Uber or Facebook, but we do not have the money and time to invest in platforms like them, and even if we had these resources we would love to have a product on the market as soon as possible for those times we should get out of the box and use our resources in the best way, always thinking that they are limited, for these cases the product model development called Lean UX would drop us from Wonderland.
Lean UX focuses on generating user experiences in design, requiring teamwork to be highly integrated. The main objective is to focus on getting feedback as soon as possible so that it can be used to make quick decisions under agile concepts (See Manifesto for Agile Software Development ). The nature of Agile development is to work in fast and iterative cycles (that take based on the result of the previous cycle) and Lean UX imitates these cycles to ensure that the generated data create new conclusions for each iteration.
Working with this type of methodologies could bring us the following advantages:
- Speed : Make improved versions quickly and discard the deliverables that do not generate any value.
- Heterogeneous vision : All those involved decide on the modifications that will improve the product.
- Multiple improvements : The more validations, a more functional product will be obtained.
- Less consumption of resources . Each hour of development has a cost, since Lean is the fastest way to make a development, it is also the most economical.
- The best viable version , Lean ux is not based on probability but on certainty, which is achieved by validated experimentation.
- Adaptation to change , nowadays a product that does not evolve dies because the market eats it, making iterative processes avoid the oxidation of the idea and the product.
Knowing all this a simple way to do the process of product development would be by following the following 14 steps.
1. Insights or main idea:
It is about generating a hypothesis based on personal experiences.
One day we are in the shower and while we are bathing we have an idea that could revolutionize the way the world works, (yes, we all have that idea that could change the way to solve a problem), the important thing is not leave it there, point it out, talk it, fall in love to be able to generate a project of it.
2. Benchmark Research
It is about better understanding the environment with which our digital product will compete, the first thing we must understand is that a successful product is ALWAYS the solution to a problem, therefore the product may evolve, but always focusing on solving the problem. main problem, therefore the series of questions to be solved would be:
- What is the problem to solve?
- What other products in the market solve the problem found?
- Is there any solution similar or better to that proposed as insight?
- What problems does the competition have?
- Other In this section we will do as complete a research as possible, therefore, any question that can help you better understand the market is valid.
Reasons why the Benchmark study helps us:
- It helps us to know products to overcome them.
- Enrich our design.
- It helps us take advantage of usability studies that someone else could have done
- It helps us identify what our competition is not doing or is doing wrong.
The objective of this exercise is to know the market and if this does not discourage you to continue with the project it will give you more tools to make it successful, it is also important to keep all the research in one place so that we can access it in a simple way In the future, a very good tool is https://mural.co/ , but there are others in the market.
3. Understanding the user (Research)
The most important thing about the UX is that it is centered on the user, which means that they are the last word to make any decision, so it is recommended to validate with them for this can be done:
- Depth interviews
The objective will be to know if:
- Is the product viable?
- Is there a need?
- Is there an opportunity for improvement?
- Will the solution solve the need?
4. Proto Person
The proto-people are recreations of the team to identify the optimal users to use the product, they originate in brainstorming workshops where the participants of the company try to summarize the hypothesis of the organization (based on their experience in the domain and your intuition) about who is going to use your product or service and what motivates them to do it.Proto-people provide the organization with a starting point to start evaluating their products and to create some early design hypotheses. They are also useful for initiating and reinforcing corporate awareness of the client’s point of view to ensure that it is included in strategic planning. This is especially true when the creators of these proto-characters are able to affect the strategic direction of the company.
At least 3 proto-people must be designed and each must have at least the following characteristics:
- First name
- Objectives of the user to comply with the platform
5. Cases of use
Write a story for each proto-person of how they would use the same platform that will help us evaluate functionalities to add to our product at the decision-making points.
The use cases will be based on assumptions and will incorporate scenarios of possible use for our platforms although they should not include the existence of our product.
Regarding the use cases, it will be important to highlight and separate the optimal moments of use of the application with the functions that could improve the user’s experience in the situation described.
6. Define elements of the MVP (Minimum viable product)
The MVP (for its acronym in English minimum viable product) is an agile concept that refers to the minimum product version to meet your need, you could say that it is a product based on the heart of the idea, without more less, in order to find the fundamental points of the MVP, the elements can be divided into 3 categories.
- Must to have: The heart of our project, here are all the characteristics that generate the transcendental value of the application and that without them the problems posed can not be solved,
- Should have: These are essential characteristics that provide value but without them the problems raised continue to be solved
- Nice to have: These are characteristics that are not directly related to the problem to be solved and that may get in the way or not be used frequently.
Being the first category (must have) that will define the minimum viable product, the elements that are not in it must have a low weight at the time of designing the platform and will be dispensable, it is important to keep in mind that each characteristic or This feature will require development time and when it is developed it will need maintenance time, and for Lean the most important thing is to take advantage of the time only for the transcendental tasks to be able to have functional products as soon as possible.
7. Information architecture
The information architecture refers to the skeleton of the application therefore it contains the modules of the same, first the designer must put forward the modules and screens that will be needed to complete the must to have.
Having this architecture sketch can be validated with the user with card sorting:
There are two types of card sorting techniques:
open, if during the process we give blank cards to the participants and it is allowed to name the contents and sort them into categories,
closed, they are given predefined cards and they must only order them.
The basic dynamics of a card sorting is as follows:
We deliver a number of cards that do not exceed 30 or 40.
We leave the participant or participants, order them in categories (if closed) or place a name (if it is open).
We compare the results of the card sorting among the participants, identifying the points of coincidence or discrepancy, to extrapolate conclusions.
The results can be very variable: that they coincide with our criteria, that the users do not understand the labeling, that they understand it but do not agree with the group or find it confusing, or that they disagree in everything. From our criterion as UX designers we must extrapolate conclusions that apply to our design.
8. Flow map
The map of flows will order the information architecture in linear processes, this will be drawn on paper in a basic way how the application will interact in the cases of use, this should take out the screens with which our application should count.
A wireframes is the visual representation of the elements of an application or web page, it would be something like the backbone of a project and it serves to:
- Establish the hierarchy of information
- As a communication bridge between customers, users, designers and programmers
- Define basic interactions (not final)
- Define the structure and basic scope of the project without knowing the fine details of it
Wireframes are schemes that will make sense of the application we are developing in a structural way. They are drawings with simple structures that show each of the screens of the application with the elements laid out as a sketch without taking into account fonts, colors, content, etc.
A good wireframe is done quickly and will contain notes, the important thing is that you can “give an idea” of how the application is going to be viewed.
One recommendation is to make the wireframes by hand, personally I like to start sketching on a blackboard and take pictures.
Wireframe on paper
In this phase it will be important to understand the project perfectly, focus on the essentials so that we can sketch the MVP (minimum viable project) nothing else, this technique will help to start taking everything from the head to the paper.
To make a wireframe it is necessary to understand the project and think about ways to communicate the functionality, the following are some tips for the time of making a wireframe:
- Divide the flow in screens
- Each screen must have sections that express the different functionalities of the application, for this each block must be defined,
- Start with blocks and sections (give them names and notes)
- Inside the sections, draw the elements of the interface based on design patterns
- Uses shallow basic geometric figures
- Do not be afraid to fly your imagination, and if you can, it is better to make several variants of the screens so that at the end of the process you have material to make decisions
- The wireframe must be legible and for that you can use all the tools at hand, such as notes, design patterns, magazine clippings, etc.
For more information on how to sketch a user experience you can see it in the following videos:
- How to make a wireframe on paper or blackboard?
10, Digitalization of low and high level wireframe
The UX process that we are doing goes from the general to the particular, so first we will do a low level digitalization and then we will detail it little by little.
Low level digitization (wireframe)
The objective of this process is to quickly convert what we did by hand to the computer so that we can focus on the details, therefore for the moment we will only focus on the information blocks and the basic interaction of the application.
I use UX design programs such as sketch or Adobe XD , if you want to learn how to use them follow the following links:
- Sketch course
- Adobe XD course
The first thing we will have to do is import the photos of the boards with the correct user experience for our application.
You will have to work in the same file separately each screen and for each one of them the sections will be defined in the following way:
- Define sections of the screen in blocks (header, content, footer, interaction zones, etc.)
- Define the elements that will go in each subsection (use only basic forms such as rectangles and circles, in addition to notes to understand the future interface)
With the basic definition of all the screens we can begin to detail our platform at intermediate level.
Digitization intermediate level of detail (wireframe)
An interface is like a joke, if it is not understood, it does not work. Large studios invested large amounts of design to generate their experiences and it would be better for the moment to borrow the results of these investigations so that our prototype is better understood, all this is encompassed in a term called design patterns.
If you want to know more please go to the next course
- Course design patterns
Our high-level wireframe can show us the intention of the application, but in order to generate experiences and feelings it is necessary to go a step further and generate interactions, in this step we will detail what a mockup is and what it is for.
Mockups are the complete visual flows used for the presentation of the general visual design of the product. It has visual elements richer than wireframes, including graphics, design, color and other more detailed visual presentation. Up to a point, it is the final design of the product.
Based on a high-level wireframe, the actions to be carried out would be:
- Detail the user interface as much as possible
- Generate interactions (buttons, scrolls, gestures, screen changes, etc.) at the highest level possible
All this can be done with Adobe XD and with Sketch plugins.
At the end of a mockup there would already be enough material to be shown to any person and the product is understood (especially the customer and the end user), which will validate the prototype in the next section
12. Usability test
The worst possible scenario for the development of a project is that it ends up being expensive, long, tedious and that in the end it is not what the user needed, to lower the possibility of this fateful scenario the LEAN UX methodology recommends testing with the end users .
A simple process for this is:
- Make a Mockup of the product
- Write a script of how the test is going to be done, in this one they recommend to pose simple tasks (for example how you would solve a certain problem of your daily life using my platform).
- The test should be short, it is preferable to review a functionality at depth than 10 above
- It is important to reiterate to the user that his performance is not being qualified and that any error found can serve to improve, it would be better if the personnel doing the test is not involved in the design of the product so that the test is not flawed.
- When doing the test you have to be careful with how to ask the questions so as not to influence the user.
- Testing 6 people from each of the evaluated targets (with 6 similar people, 80% of the errors that can be committed by the same profile are covered)
- Each test must be recorded and executed by two staff members (one to guide the test that interacts with the user and another that takes notes) and with each user separately.
- The user should be asked to comment aloud on everything they are doing and thinking
- The user should feel comfortable when doing the test, therefore the test should be coupled to make it as natural as possible, for this you could take additional material such as mouse, keyboard, hidden microphones, pens, sheets, etc.
- To close the test it is recommended to reward the user for their time and annoyance, if this is done, the user will feel comfortable to return to take another test.
13. Session of analysis and decision making
With all the information generated in the test with the users, decisions must be made, for this, all the personnel involved in the project must sit down at the table:
- UX designers
- Validation team
- If it is possible to invite an expert, you could have good feedback.
The objective of this session will be to make decisions on the next development steps based on the process that was developed for the product, based on the results of the usability tests, keeping in mind that the one that best knows your needs is the user and with modesty, the following points should be reviewed.
- User satisfaction
- Unnecessary elements of the application
- Fundamental points of the application
- Discomfort of the user
- User notes
- Development time of the elements
At the end of this session, which should not last more than 6 hours with intermediate meal time, you should have a consensus of the following:
- Does the product meet the needs of the user?
- Do we know enough about the product to develop it?
- Is the minimum product to be developed that does not lose the essence of the project? MVP (Minimum viable product), MLP (Minimum lovable product)
- Would users use the product?
- Is the product monetarizable?
With the conclusions there are the following possibilities
- Make the decision not to follow the project because the results say it’s a bad idea, great, you broke without investing in the development and you have time to do other projects.
- Decide that the product raised above has some flaws, which should correct the mockup, the interview and retest the usability.
- Make minimal changes in the mockup based on the data of the users and continue with the development process of the same
14. Outcome document
Already having a validated product it is important to write the project in greater detail, this document is called “scope document” and is the bible of all developments, it is written by the UX designer and corrected by the development team to validate it The client, taking this into account should plan short sprints, each of these sprints should complete a full functionality and with this perform an iterative process of:
Iterative (Design → prototype → test → validate → program)
- we work in the flow
- we made wireframes on paper
- we made some screens that went up and we worked in low fidelity and then high
- then we define typography and colors
- With that model already finished we put to work in detail on the screens to leave everything ready and completely closed (this is what probably takes more work, because it is where we apply everything defined and we put the FINAL design to absolutely ALL the screens, what is not only necessary but will save a lot of development time and misunderstandings)
- we learned how to make user tests
- We learned how to make life easier for programmers and clearly communicate everything to the entire team.