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.
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.