Recognizing the obvious…!

"No one has ever asked me that question before," is what the customer support rep told me.  "And I don't know myself." So I'm calling with a few problems about my mobile navigation app.  After dealing with the more important questions, I asked "can you tell me what the different road colors mean?" I've enjoyed this app for many weeks now, but it began to bother me that I didn't know why some roads were blue, others pink, others yellow.  I'm pretty sure that since roads I know to be side streets are in white, that white roads mean side streets.  So on my call with customer service, I asked what they really meant.  Was this important?  Well no, not really - in navigation all you do is follow the arrows and/or vocal prompts. But let's look at this from a software quality standpoint.  This navigation app has one, count 'em, ONE window in its user interface, and the rest of the UI contains only settings.  Somebody agonized over the niceties of having that UI track location, present traffic info, route planning, points of interest, all against the very simple background of rendering streets as a map.  In fact, you can choose various themes in which different types of road can be rendered in your colors of choice.  Take all the other stuff away, you have a map with maybe a dozen colors.  So what do they mean? It's amazing to me - but hardly unusual - when information is crammed into a user interface with no reference or explanation.  The yellow roads on my nav app could be promising alternate routes, or they could lead to Oz - I can't find out.  Customer support doesn't know why. Many times engineers are afraid or intimidated to ask the obvious questions.  Often, the question itself exposes a whole raft of assumptions that may be brilliant or may be idiotic.  The right question wrongly put can cause a lot of collateral damage - especially to the questioner.  But what happens if it is unasked?