what to do when UX asks for an ugly, convoluted event driven design and you don't know how to implement it in a clean manner?

Question

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?

Answer 1

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

Answer 2

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.

Answer 3

One of the things I do these days is that I explicitly request the UX designer sketches their designs in front of all of us on the fly. Actually that seems like common sense to me and the first UX Designer I worked with did that, even sketching out her designs over company meetings and we'd talk about it and ask questions like, "What should happen if the user does this?" and because she used very rapid mediums like pencil/pen on paper or marker on whiteboard, it was easy for her to draw out what should happen very quickly on the fly.

And that was such a smooth experience. I took it for granted and thought all UX design collaborations would work like this.

But I worked with two subsequent ones afterwords and one in particular made the most beautiful mockups in Photoshop that practically looked like a final product, except he'd spend a whole week working on it and then the company would pull him to further design our web page and we'd be stuck with basic questions like yours and also like, "Wait, how's the UI supposed to look if it's resized?" And he was too busy to answer them and we were in crunch and we'd just miserably connect all those dots (which is something you might have to do if the designer is not available) only for him to come out of the bunker and become upset that we filled in all these gaps.

As a result I've come to grow a strong distaste for such elaborate and pretty-looking mockups in the beginning, because they take too long for the designer to make and don't answer all those questions we might have. I actually prefer a designer just drawing rectangles and stuff on a whiteboard or notepad or even a paper napkin while we collaborate and work things out. That's very fast and he/she can draw his/her ideas on the fly to show us what should happen in every single case. That's the right way to do it now in my experience if you can find such a designer willing to rapidly sketch and then save the beauty mock-up for later.

Are programmers always expected to fill in the dots, even when the proper behavior hasn't been explicitly stated?

Unfortunately in my experience it usually is the case, but it wasn't with that first designer I mentioned. With her it was so clear what was supposed to happen with every use case, not because she anticipated them all (we did often make her pause sometimes to think about some use case we mentioned), but because she was able to so rapidly sketch things out and talk to us that she could illustrate her solutions to our questions on the fly. That was a proper collaboration, not like, "Here, I spent a week drawing this beautiful picture -- now go code it."