> otherwise they'll waste all your time rearranging the layout instead of concentrating on more important issues they're not aware of.
I think if you're having trouble managing the workload of UI changes it's a project management/process problem, your client should know how much it interrupts feature development, so that they can weigh up the cost.
While I understand where you're coming from as I've been there, the article was about exactly this line of thinking. You don't care about the minor UI change but the customer does, and they're the ones using the software. Who's issues are really more important?
I am sure you can come up with an example of a pressing development issue that would trump the UI change, but is that really 100% of your time? I'm sure tonnes of UI changes seem trivial to developers, but would be the difference between hours a day of a task being frustrating versus a task being easy for the end user. We don't use the end product like they do, so we can't really know which one's are trivial and which aren't.
Even if the customer is the user, these "move the button to the left by two pixels" type of requests are very common and really aren't important. I've seen users do this because it makes them feel like they have input and I've seen these types of requests turn into serious bikeshedding. They never actually make any difference to how they use the product, but these tasks end up taking a lot of time (that as GP said, the customer typically doesn't want to pay for because its a small change).
Actual workflow changes, where customers ask for UI changes that make some task easier or faster, are valuable and, at least in my experience, these are very different from the requests you get when a customer realises that UI changes are (by themselves) quick and easy. You can ask for ways that you can improve or speed up their work without them needing to know you can move a that label two pixels to the right in a matter of seconds (which in reality will take hours of back and forward as its never quite right).
> I'm sure tonnes of UI changes seem trivial to developers, but would be the difference between hours a day of a task being frustrating versus a task being easy for the end user.
The types of UI changes GP talked about (moving a button a few pixels) is not the kind of thing that causes an end user task to be more or less frustrating.
> We don't use the end product like they do, so we can't really know which one's are trivial and which aren't.
But talk to enough of them and you'll see that bikeshedding about pixel positioning is almost never something you want the customer to be doing.
The assumption that the client is the user doesn't hold true in many projects. In fact, letting the client mess up the layout may ruin a UI that was carefully validated with the the user.
I think if you're having trouble managing the workload of UI changes it's a project management/process problem, your client should know how much it interrupts feature development, so that they can weigh up the cost.
While I understand where you're coming from as I've been there, the article was about exactly this line of thinking. You don't care about the minor UI change but the customer does, and they're the ones using the software. Who's issues are really more important?
I am sure you can come up with an example of a pressing development issue that would trump the UI change, but is that really 100% of your time? I'm sure tonnes of UI changes seem trivial to developers, but would be the difference between hours a day of a task being frustrating versus a task being easy for the end user. We don't use the end product like they do, so we can't really know which one's are trivial and which aren't.