Make a fusion of agile development and user experience (UX)
The author of the original idea of this article is John Inns, a consultant in the field of flexible methodologies for IT development. The source can be found here . We finished it a bit, simplified a lot, but now you can at least read the article :)
So, there is such a thing as user interaction experience (the same UX, User Experience). In general, the UX is the user's impression of your product (for example, a site). This includes the appearance, convenience of the location of buttons, links and other elements.
')
Why take into account interaction experience is important? Elementary: the user is comfortable on the site - you get a profit. The user got lost, was upset and closed the tab in the browser - accordingly, you get nothing. Just like two and two.
And the sad thing - if you fix it with the UX - during development, you will lose money (marketing budget) all the time. It is better to immediately do "nyashno, sexy, mimi ;-)".
Initially, agile didn’t take UX into account at all. And no wonder - after all, the Agile pioneers worked on their own IT projects (special software) or wrote corporate software. Take into account user habits? What other, sorry, users?
Currently, most of the software being developed is repelled by the interests of the end user. Nevertheless, we have two main problems that need to be overcome: the inability to measure the degree of convenience of a software product (the same interaction experience, UX) and the inability to receive constant feedback from users.
The purpose of the UX matrix is to solve these problems by linking the Project Backlog and UX. First we fill in the following label - the data will be needed to build the matrix in the future:
For example, we design an e-book store where you can download them, after making a payment.
We invent the first person, let it be, for example, “Student Vasya” (a small description of a person helps a lot, for example, “studies to a marketer, first year, loves new gadgets, has his accounts in social networks”).
We invent stories for the person.
Like traditional Scrum methods, UX specialists (analysts and web designers) break stories into specific tasks. The results will be subsequently fixed on a kanban board, as well as the development tasks and implemented in the Backlog using the integration UX-matrix.
Important: the person is assigned a specific weight. The representative of the main target audience will have more influence (priority), non-target - respectively, less. Stories are evaluated by the Product Owner in terms of the influence of each on the goals of the business. Given all this, the tasks in the Backlog will be streamlined.
When the stories of this person are finished - we evaluate them according to the table and proceed to the next person who pursues his own goals, stories, different from Vasin. For the accuracy of the information, each person is confirmed using research on living people (receives statistical confirmation).
The result of our work should be this matrix:
“History is done on its own” - what percentage of test users could complete the story without help.
The meaning of this seemingly complex approach in particular lies in the fact that the task of the performers acquires a completely new meaning. Compare:
Before: “Draw the social recommendation buttons below the product image”
Now: “Add a tool that helps the user to share a favorite product with friends.”
At first glance, the same thing. However, in the first case, the task is a simple rant, “do it,” without giving any arguments.
In the second, the task contains not an authoritarian indication, but a goal, forcing the UX specialists to search for a solution based on the real needs of the customers. The usability analyst, if there is one in the team, will be engaged in preliminary research aimed at enhancing user-friendliness of the software for users, the functional designer will design the interface part, and the visual designer will produce the final product.
Next, the project will go into development, programmers by all the rules of Agile will appreciate the implementation (by the way, Planning Poker is recommended as an evaluation tool) and, eventually, will be seen in the users' face.
It is important that the project at the beginning is based on user experience, and, consequently, it is more viable, because its design now reflects not the individual’s ideas about convenience, but is based on the experience of users themselves.
So what do we get at the output? Design that is convenient to use, and not just a beautiful wrapper. Each user's need is analyzed before being embodied in the layout - therefore, now our site meets the definition of a “business tool”. So you no longer have to worry about “leaking the marketing budget” through holes because of ill-conceived design. And this is good.
Shl. Those who love Agile just as we do, get a bonus as a gift - the same matrix in the excel file: docs.google.com/spreadsheets/d/16ZbCnVMeGer09EGkIIVZmqsKfU_8R-DEJg0WJ9GSfzE/edit?usp=sharing
Allows you to sort, organize, group, enter their values - in general, own, use and dispose of for the benefit of flexible processes.
So, there is such a thing as user interaction experience (the same UX, User Experience). In general, the UX is the user's impression of your product (for example, a site). This includes the appearance, convenience of the location of buttons, links and other elements.
')
Why take into account interaction experience is important? Elementary: the user is comfortable on the site - you get a profit. The user got lost, was upset and closed the tab in the browser - accordingly, you get nothing. Just like two and two.
And the sad thing - if you fix it with the UX - during development, you will lose money (marketing budget) all the time. It is better to immediately do "nyashno, sexy, mimi ;-)".
Initially, agile didn’t take UX into account at all. And no wonder - after all, the Agile pioneers worked on their own IT projects (special software) or wrote corporate software. Take into account user habits? What other, sorry, users?
Currently, most of the software being developed is repelled by the interests of the end user. Nevertheless, we have two main problems that need to be overcome: the inability to measure the degree of convenience of a software product (the same interaction experience, UX) and the inability to receive constant feedback from users.
The purpose of the UX matrix is to solve these problems by linking the Project Backlog and UX. First we fill in the following label - the data will be needed to build the matrix in the future:
| Column name | Possible values | Description |
|---|---|---|
| A person | Person Name | Defines the person to which this or that user story is applicable. |
| UX Difficulty | from 1 to 5 | Estimates designer costs for implementation. |
| History verified | Well no | Is this story a fact or an invention? Is it based on research and statistics? |
| Design finished | Well no | Does the design meet the requirements of developers (technical feasibility) |
| Task execution rate | from 0 to 100% | The percentage of users who completed the story without help. |
| Staffing | Resource | Who is responsible for the design |
For example, we design an e-book store where you can download them, after making a payment.
We invent the first person, let it be, for example, “Student Vasya” (a small description of a person helps a lot, for example, “studies to a marketer, first year, loves new gadgets, has his accounts in social networks”).
We invent stories for the person.
- Student Vasya wants to buy a book, he only knows the name of the author and the fact that there are few pages in the book.
- Student Vasya wants to be in the know when the N's book of the X author goes on sale.
- Student Vasya would like to buy several books at once and pay with his e-wallet.
- Student Vasya wants to see which of his friends read the book.
- Student Vasya wants to add comments to the read book, but does not want to log in to the site.
Like traditional Scrum methods, UX specialists (analysts and web designers) break stories into specific tasks. The results will be subsequently fixed on a kanban board, as well as the development tasks and implemented in the Backlog using the integration UX-matrix.
Important: the person is assigned a specific weight. The representative of the main target audience will have more influence (priority), non-target - respectively, less. Stories are evaluated by the Product Owner in terms of the influence of each on the goals of the business. Given all this, the tasks in the Backlog will be streamlined.
When the stories of this person are finished - we evaluate them according to the table and proceed to the next person who pursues his own goals, stories, different from Vasin. For the accuracy of the information, each person is confirmed using research on living people (receives statistical confirmation).
The result of our work should be this matrix:
“History is done on its own” - what percentage of test users could complete the story without help.
The meaning of this seemingly complex approach in particular lies in the fact that the task of the performers acquires a completely new meaning. Compare:
Before: “Draw the social recommendation buttons below the product image”
Now: “Add a tool that helps the user to share a favorite product with friends.”
At first glance, the same thing. However, in the first case, the task is a simple rant, “do it,” without giving any arguments.
In the second, the task contains not an authoritarian indication, but a goal, forcing the UX specialists to search for a solution based on the real needs of the customers. The usability analyst, if there is one in the team, will be engaged in preliminary research aimed at enhancing user-friendliness of the software for users, the functional designer will design the interface part, and the visual designer will produce the final product.
Next, the project will go into development, programmers by all the rules of Agile will appreciate the implementation (by the way, Planning Poker is recommended as an evaluation tool) and, eventually, will be seen in the users' face.
It is important that the project at the beginning is based on user experience, and, consequently, it is more viable, because its design now reflects not the individual’s ideas about convenience, but is based on the experience of users themselves.
So what do we get at the output? Design that is convenient to use, and not just a beautiful wrapper. Each user's need is analyzed before being embodied in the layout - therefore, now our site meets the definition of a “business tool”. So you no longer have to worry about “leaking the marketing budget” through holes because of ill-conceived design. And this is good.
Shl. Those who love Agile just as we do, get a bonus as a gift - the same matrix in the excel file: docs.google.com/spreadsheets/d/16ZbCnVMeGer09EGkIIVZmqsKfU_8R-DEJg0WJ9GSfzE/edit?usp=sharing
Allows you to sort, organize, group, enter their values - in general, own, use and dispose of for the benefit of flexible processes.
Source: https://habr.com/ru/post/144760/
All Articles