There was a problem in production. A feature could be misused so that one user could change the data for the other, and the two users were taking daily turns in correcting things manually to their liking until they came to a point where they decided both to complain that the software is broken because their data only sticks for a day.
Surely, that is not what the users are intended to be doing. They just did not understand that this particular piece of data is shared - how could they, when the application tries actively not to share most of the data and doesn't make a clear distinction on this type of data is different.
I've mentioned this when I joined four years ago. I've mentioned it and negotiated for it to change, regularly. But it took four years before it caused any trouble that would reach our ears.
As the trouble emerges, our product owner is quick to admit that things shouldn't be as they are. But that since they are, a quick fix of making the editing of that data to be only available in special settings could be done. The team looks at the quick fix, and confirms it is indeed quick.
At this point, however, someone decides it is good to include the UX designer into the discussion. She immediately sees that the quick fix isn't really improving usability, and comes up with a slightly more complicated design that would take things forward.
The quick fix of half a day turned into a week of work. The fix that was needed immediately was postponed from tomorrow to happen in a week.
The emergent decision starts to bug me, and I question the bundling, asking for delivering first the quick fix and only later the more complicated design and it's like I'm looking into a mirror: I'm faced with harsh, emotional arguments about the reason why it must be bundled. Because there is so much more other more important work to do, that without bundling it will not be done. The current me looks at the situation, and assesses that if that was the case, then it just shouldn't be done.
Situation escalates with the emotions, and I feel even more like facing a mirror of a younger version of myself. The spirited, committed fight for quality as you believe it should be: users are the key! The need to feel gatekeeper to protect them from bad, even if blocking some of the good. The despair that a better future where things will later be fixed will never come. And I respect seeing the mirror, as it points out how I've changed.
It's not that I would have given up on my bright-eyed strive for indefinitely better, but I've grown to accept that delivering something today, small batches, is the best thing we can do. The other batches will come. There needs to be a balance of improving UX, improving maintainability, and adding new features. When each is done is small batches, we can do all of them without completely stopping any. And we can also completely stop any, for having more items of another kind.
The mirror also reminded me, that when I joined as the only tester of this team, the bugs I could find generated so much work that the whole team was needed on fixing them. Many of the bugs had already been in production, and seemingly the users never cared (or rather, had not cared by that time). It took more patience than what I believed was in me to balance some of the fixing with the features product management would wish to see.
It must be just as painful to have ideas of how to fix things for user interface but not have the ability to take through those ideas yourself or in full steam as it is to report any issues (including UX) as you test but can't fix yourself.
Plans and feedback don't change the product for the better. The fixes and changes do. So yes, there is such a thing as too much feedback. Too much too soon, when you've piled up some backlog.
In four years, the simple functionality bugs have vanished. The UX bugs are under construction. And some of them, including this one really, requires changes in logic way beyond the user interface to really go for the experience we look for. In small batches of forward-driven value, flowing continuously, we'll get there. And learn some more while on route.
Surely, that is not what the users are intended to be doing. They just did not understand that this particular piece of data is shared - how could they, when the application tries actively not to share most of the data and doesn't make a clear distinction on this type of data is different.
I've mentioned this when I joined four years ago. I've mentioned it and negotiated for it to change, regularly. But it took four years before it caused any trouble that would reach our ears.
As the trouble emerges, our product owner is quick to admit that things shouldn't be as they are. But that since they are, a quick fix of making the editing of that data to be only available in special settings could be done. The team looks at the quick fix, and confirms it is indeed quick.
At this point, however, someone decides it is good to include the UX designer into the discussion. She immediately sees that the quick fix isn't really improving usability, and comes up with a slightly more complicated design that would take things forward.
The quick fix of half a day turned into a week of work. The fix that was needed immediately was postponed from tomorrow to happen in a week.
The emergent decision starts to bug me, and I question the bundling, asking for delivering first the quick fix and only later the more complicated design and it's like I'm looking into a mirror: I'm faced with harsh, emotional arguments about the reason why it must be bundled. Because there is so much more other more important work to do, that without bundling it will not be done. The current me looks at the situation, and assesses that if that was the case, then it just shouldn't be done.
Situation escalates with the emotions, and I feel even more like facing a mirror of a younger version of myself. The spirited, committed fight for quality as you believe it should be: users are the key! The need to feel gatekeeper to protect them from bad, even if blocking some of the good. The despair that a better future where things will later be fixed will never come. And I respect seeing the mirror, as it points out how I've changed.
It's not that I would have given up on my bright-eyed strive for indefinitely better, but I've grown to accept that delivering something today, small batches, is the best thing we can do. The other batches will come. There needs to be a balance of improving UX, improving maintainability, and adding new features. When each is done is small batches, we can do all of them without completely stopping any. And we can also completely stop any, for having more items of another kind.
The mirror also reminded me, that when I joined as the only tester of this team, the bugs I could find generated so much work that the whole team was needed on fixing them. Many of the bugs had already been in production, and seemingly the users never cared (or rather, had not cared by that time). It took more patience than what I believed was in me to balance some of the fixing with the features product management would wish to see.
It must be just as painful to have ideas of how to fix things for user interface but not have the ability to take through those ideas yourself or in full steam as it is to report any issues (including UX) as you test but can't fix yourself.
Plans and feedback don't change the product for the better. The fixes and changes do. So yes, there is such a thing as too much feedback. Too much too soon, when you've piled up some backlog.
In four years, the simple functionality bugs have vanished. The UX bugs are under construction. And some of them, including this one really, requires changes in logic way beyond the user interface to really go for the experience we look for. In small batches of forward-driven value, flowing continuously, we'll get there. And learn some more while on route.
