To clarify, the UX professionals at my company are making the big decisions about what the general layout of the application should be, and they are providing wireframes which we follow as best we can whenever they make sense.
But when we go to implement a wireframe or feature request, it’s extremely common to run into unexpected corner cases or details they simply forgot to specify. Then, one of the following happens:
1) If there’s an obvious, simple solution that seems okay, we go with that. Sometimes UX asks for a more complicated solution later, but often they don’t.
2) We explain the dilemma to UX so they can make the decision for us. Usually they answer the question, but often that answer isn’t very detailed so we end up doing some of #1 or repeating #2.
3) The UX request is perfectly clear, but it’s such a bad idea we do something else anyway. Usually they don’t even notice, which we take as validation. Occasionally, they do ask for it to be “fixed” and then we begrudgingly do it anyway. Sometimes they change their mind after seeing it implemented.
Ideally, it seems like the UX professionals should be making all the UX decisions, i.e. we’d be doing #2 every single time. But we don’t. In my opinion and/or experience, our UX people are good at overall designs but quite bad at thinking through the niggling little behavioral details that those designs imply, and most of our team seems to share that view. My team lead has even stopped me from doing #2 on a few occasions.
Is this a normal consequence of programmers and business/UX people having different skills and mindsets? Are we already handling this the right way? Should we be more obedient? Should we push them to give us more complete, well-thought out designs to begin with?
4
Yes it is normal that once you start implementing a program following a written specification, you will discover lots of unclear, ambiguous and missing details in the spec. That will occur even sometimes when you have written the spec by yourself, but it will definitely occur when the spec was written by non-programmers, system analysts, or in your case UX people.
In fact, that is not a new insight into programming – it is just one of the main reasons why the “waterfall model” does not work (even though some non-programmers, system analysts, or UX people might have a different opinion).
1
Nice question 🙂
I fight through this question almost daily… Sometimes it may also happen that the wireframe is frankly not implementable in the time given!
For me, the only answer is friendly talk between UX specialist and programmers, before the wireframe is done and approved (after which, it can hardly be modified without raising an issue).
UX and programmers have different mindset (they sell “the Dream”, while programmers have to deliver that…), which can produce a good work only if they are both contributing in the wireframe design and implementation, so, don’t be afraid to ask for support during implementation, and offer support and review during wireframe design.