Users, features and “dancing bears”
For some reason, it is very painful and annoying when a project that you have been working on for more than a year suddenly begins to grow into a bunch of unnecessary functions - just because one hypothetical customer needs it. But initially the product was planned as a public service. It hurts to see how a slim building literally falls apart, bursting with lurid superstructures of momentary functions.
I understand: the market, competition, terms, customers. But there is nothing worse than giving the leadership to the users and blindly following their whims. The race for functionality is a false race that won no prize, except, perhaps, slavery to the customer. The beauty of the product is not in the abundance of functions, but in their proper fit, balance, convenience.
The only way out in this situation is to branch the product: make a separate user branch, and, if such is the development policy, add the required functions to it. A public branch to keep clean and understandable. Only now such an approach won’t bring joy - neither to users nor developers, since both branches are gradually turning into functional monsters, “dancing bears”.
The customer's motivations are clear - he wants to get a single product and use it (although the required functionality can be achieved through integration with other products): I want everything at once and for the same money. Only the result is more like a motley grandmother’s blanket, woven from hundreds of patches, but warm and beautiful — but to a rag made from the same patches, about which everyone wipes their feet and sew new patches in place of the broken ones. It will still be possible to use it - only difficult and inconvenient. And not in that capacity.
The source of the problem - well, there are at least two of them: the lack of a high-level ideological design (of what is called interaction design - not to be confused with the system architecture ) and the desire to please the hypothetical customer at the moment. In the absence of these two things, one can only mitigate the monstrousness of the product by stuffing the functions as carefully as possible (yes, usability — testing, redesign).
Moral: but not her. More precisely, it is obvious - a truism, so to speak. Along with the system architecture (and even before it), there must be (must be!) A clarification stage, and what we specifically do, and what tasks can be solved with the help of our product. But the most important thing is to bring it to customers. That there was no need to hammer in nails with microscopes. Well, do not mix public services with services for a specific client.
I understand: the market, competition, terms, customers. But there is nothing worse than giving the leadership to the users and blindly following their whims. The race for functionality is a false race that won no prize, except, perhaps, slavery to the customer. The beauty of the product is not in the abundance of functions, but in their proper fit, balance, convenience.
The only way out in this situation is to branch the product: make a separate user branch, and, if such is the development policy, add the required functions to it. A public branch to keep clean and understandable. Only now such an approach won’t bring joy - neither to users nor developers, since both branches are gradually turning into functional monsters, “dancing bears”.
The customer's motivations are clear - he wants to get a single product and use it (although the required functionality can be achieved through integration with other products): I want everything at once and for the same money. Only the result is more like a motley grandmother’s blanket, woven from hundreds of patches, but warm and beautiful — but to a rag made from the same patches, about which everyone wipes their feet and sew new patches in place of the broken ones. It will still be possible to use it - only difficult and inconvenient. And not in that capacity.
The source of the problem - well, there are at least two of them: the lack of a high-level ideological design (of what is called interaction design - not to be confused with the system architecture ) and the desire to please the hypothetical customer at the moment. In the absence of these two things, one can only mitigate the monstrousness of the product by stuffing the functions as carefully as possible (yes, usability — testing, redesign).
Moral: but not her. More precisely, it is obvious - a truism, so to speak. Along with the system architecture (and even before it), there must be (must be!) A clarification stage, and what we specifically do, and what tasks can be solved with the help of our product. But the most important thing is to bring it to customers. That there was no need to hammer in nails with microscopes. Well, do not mix public services with services for a specific client.
')
Source: https://habr.com/ru/post/13592/
All Articles