Use Case and Usage scenarios for GUI design
Use cases (use cases) and usage scenarios (usage scenarios) as the basis for designing a graphical user interface (GUI)
Since understanding User Needs (User Centered Design Philosophy) allows us to develop more convenient, popular and effective software products (and therefore leads to universal happiness and satisfaction =), it is necessary to find tools to efficiently extract and process information about user requirements.
In the light of the foregoing, I propose to discuss methods such as Use cases and Use scenarios (Use case and Usage scenarios). The above methodologies proved to be excellent (Karl E. Wiegers, 2004), I was convinced from their own experience of their effectiveness and extraordinary benefits.
')
A warning!
In order to achieve the validity of the options and use cases, it is necessary to conduct regular clarifying sessions with representatives of product users. Use cases are the best tool for extracting and processing qualifying information about requirements, but using them as the only tool to retrieve user requirements is fraught with risk. It is important to understand that the methodologies discussed are a means of modeling, which, in turn, must be based on real facts.
Today, I see two complementary (but not alternative) ways to formalize use cases:
a) using UML semantics, and
b) in text form.
The first method allows you to briefly describe the system or particular use case at the conceptual level. The second method allows you to produce a low-level description, and, most importantly, more understandable unprepared representatives of users, and the customer of the product. Both methods have advantages and disadvantages and have the ability to synergistically complement each other.
My comments from the point of view of the designer
1. The very fact of the description of the algorithm of user interaction with the system expands the consciousness, the effect of “getting into the user's skin” occurs, I saw a whole lot of possibilities to improve the interface.
2. The level of “integrity” of documentation has increased, a pleasant sense of order appeared when you know why such a feature should definitely be in this place and what emphasis should be given to it.
3. Be prepared for the fact that during the formalization of a text description there will be difficulties with markup, tables, wording and terminology, it took me about a day to overcome them.
My impressions from the point of view of the project manager
1. The forgotten screens (wireframes) that need to be described have surfaced (and this made it possible to plan the project implementation more optimally and avoid unnecessary iterations).
2. The use of these methodologies requires time and resource costs, but in the end pays off handsomely:
- the quality of the product increases several times;
- the level of customer satisfaction also increases markedly;
- the project becomes more predictable and manageable (much less “loss” of functionality and interface elements happens);
- there is an additional argument that may be required during the presentations of wireframes, UI design and the product as a whole.
In more detail about my point of view and practical experience of application of the described techniques I will tell in the following publications.
There was an interesting discussion in User Experience Russia, you can continue.
Also I will be glad to see your comments.
Since understanding User Needs (User Centered Design Philosophy) allows us to develop more convenient, popular and effective software products (and therefore leads to universal happiness and satisfaction =), it is necessary to find tools to efficiently extract and process information about user requirements.
In the light of the foregoing, I propose to discuss methods such as Use cases and Use scenarios (Use case and Usage scenarios). The above methodologies proved to be excellent (Karl E. Wiegers, 2004), I was convinced from their own experience of their effectiveness and extraordinary benefits.
')
A warning!
In order to achieve the validity of the options and use cases, it is necessary to conduct regular clarifying sessions with representatives of product users. Use cases are the best tool for extracting and processing qualifying information about requirements, but using them as the only tool to retrieve user requirements is fraught with risk. It is important to understand that the methodologies discussed are a means of modeling, which, in turn, must be based on real facts.
Today, I see two complementary (but not alternative) ways to formalize use cases:
a) using UML semantics, and
b) in text form.
The first method allows you to briefly describe the system or particular use case at the conceptual level. The second method allows you to produce a low-level description, and, most importantly, more understandable unprepared representatives of users, and the customer of the product. Both methods have advantages and disadvantages and have the ability to synergistically complement each other.
My comments from the point of view of the designer
1. The very fact of the description of the algorithm of user interaction with the system expands the consciousness, the effect of “getting into the user's skin” occurs, I saw a whole lot of possibilities to improve the interface.
2. The level of “integrity” of documentation has increased, a pleasant sense of order appeared when you know why such a feature should definitely be in this place and what emphasis should be given to it.
3. Be prepared for the fact that during the formalization of a text description there will be difficulties with markup, tables, wording and terminology, it took me about a day to overcome them.
My impressions from the point of view of the project manager
1. The forgotten screens (wireframes) that need to be described have surfaced (and this made it possible to plan the project implementation more optimally and avoid unnecessary iterations).
2. The use of these methodologies requires time and resource costs, but in the end pays off handsomely:
- the quality of the product increases several times;
- the level of customer satisfaction also increases markedly;
- the project becomes more predictable and manageable (much less “loss” of functionality and interface elements happens);
- there is an additional argument that may be required during the presentations of wireframes, UI design and the product as a whole.
In more detail about my point of view and practical experience of application of the described techniques I will tell in the following publications.
There was an interesting discussion in User Experience Russia, you can continue.
Also I will be glad to see your comments.
Source: https://habr.com/ru/post/63673/
All Articles