Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

2 Answers 2

In case of doubt, ask for clarification. Maybe the UX do not know that these "corner cases" are possible.

As for the example that you write, I do not think it so complicated as you paint it. Just from common sense, you have two options:

  • If there are no items for the dropbox, disable option B. Add a tip (when hovering, or with an icon), stating that option B is disabled because of that.

  • If there is something that forbids it (for example, finding out the list of items is expensive and you only want to retrieve them once "option B" is selected, so you don't know before of that if the list is empty), when "option B" is selected change the dropbown to a label that explains that to the user.

Of course, it will depend of how much freedom do you have to do your work. If you have no freedom at all, just do your work as stated and report back possible issues. If no answers come, just do exatly what was asked (of course, at the same time document everything to CYA).

share|improve this answer

You are experiencing a gap in the requirements (what to do when X goes wrong). This is not uncommon, because it is very hard to think of all possibilities up front.

What to do about it is quite simple: you ask the person responsible for the requirements/user stories/etc, to give you guidance on what the desired result should be from user perspective. Then you implement that.

If waiting for the response on your query would dangerously delay the project, then you should implement whatever is easiest to do for now and open an issue to create a proper implementation when the formal answer is known.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.