I have been tasked with creating a desktop client application that fetches data from web apis and presents it to the user.
During the last month or so, I've spent most of my time and energy bringing to life the functionality that UX described with two pictures.
Looking at the pictures, it seems like a simple design. There are only 4 controls:
One drop down list that fires a selection event. Another drop down list that is populated based on selected data from the first drop down list and also fires a selection event. Two radio controls that enable or disable the second drop down list. A third drop down list that, depending on which radio button was last selected, is populated with data based on either the first drop down list or the second drop down list.
Doesn't seem hard.
But then when I actually start implementing this design I find that I don't know, for example, what to do with if the user selects radio button B (which is supposed to enable the second drop down list) but the drop down list has no elements; in that case, do I force the first radio button A to be reselected? Do I display an error message? Do I prompt the user for action?
It's these little 'corner' cases that don't necessarily jump at the people who request these designs that make me wonder if I'm in the wrong line of business or if I'm stuck working with people who don't have a clear picture of what they want or don't really know what they want but expect me to fill in the dots without actually doing the UX design myself.
UX is about enhancing the user's experience, not the programmer's experience, I get it, but is this the kind of input that programmers are typically expected to receive from UX? Are programmers always expected to fill in the dots, even when the proper behavior hasn't been explicitly stated?