Home Closet Users, functions and “dancing bears”

Users, functions and “dancing bears”

by admin

For some reason it hurts when a project you’ve been working on for over a year suddenly starts adding a bunch of unnecessary features, just because one needs it that way hypothetical customer. And the product was originally planned as public service. It’s painful to see how the slender building is literally falling apart, being sprawled out by garish superstructures of momentary functions.
I understand: the market, the competition, the deadlines, the customers. But there is nothing worse than putting the manual in the hands of users and blindly following their whims. The pursuit of functionality is a false race, the winner of it will not get any prize, except, perhaps, slavery to the customer. The beauty of a product is not in the abundance of functions, but in their right fit, balance, convenience.
The only way out in this situation is to branched the product: do a separate user branch and, if that is the development policy, add the required functions to it. And keep the public branch clean and clear. But this approach will not bring any joy to users or developers because both branches are gradually turning into functional monsters, "dancing bears".
The customer motivations are clear – he wants to get a single product and use it (although the required functionality can be achieved by integration with other products): I want it all at once for the same money. But the result is more like a motley grandmother’s quilt, woven from hundreds of rags, but warm and beautiful – but like a floor cloth made of the same rags, which everyone wipes their feet and stitches new rags instead of the bursting ones. It will still be possible to use, but it is difficult and inconvenient. And in the wrong quality.
The source of the problem – well, there are at least two : lack of high-level ideological design (what is called interaction design – not to be confused with system architecture ) and the desire to please the hypothetical customer in given moment. In the absence of these two things, you can only mitigate the monstrosity of the product by cramming features as neatly as possible (yes, yes – usability – testing, redesigning).
Moral : there is none. Or rather, it is obvious – the plain truth, so to speak. Along with system architecture (and even before it) there should be (must be!) a stage of figuring out what exactly we are doing and what tasks can be solved with our product. But the most important thing is to communicate this to our customers. So there is no need to hammer nails with microscopes. And not to mix public services with services for a particular customer.

You may also like