Too close to the fire

When developing software you are making thousands of little decision about how it should work every day. We explicitly specify every little detail of how it looks and feels, these are all soft skills that do not necessarily come naturally to all developers. Along came UI designers and standardisation of how interfaces should work. Google uses and pushes material design principles and you can find it on most of their websites, a credit to them for their efforts to standardise how we interact with computers.

The difficulty I find is within these decisions I make, I start filling in the gaps that the user stories & mock-ups did not specify. To look at it in a measured way, user stories and mock-ups take the whole product and decompose it into a manageable size so as to increase detail. Developers take these structures and decompose them into the actual functionality - it's a process of removing blur from the greater image.

The process of decomposing is where I find it the hardest to relate back to the user, it takes a lot of thought to break up the specification and work out how it all hangs together; what depends on each other. When you have all these concepts in your head, you get to a crossroad and you make the best decision in front of you based on the decomposition and what you think the user will do. It's the decomposition that throws you foul, that has nothing to do with what the user wants but transitioning your thought process from decomposition back to the users is not that easy.
Once you know too much about how a piece of software is decomposed, it becomes harder to correctly predict the user's detailed requirements.

So how do we reduce the rejection of completed code?

Structures and Planning

The software industry identified this and moved towards agile and lean development - iterate small and often while trimming the fat. Demo to the user and accept feedback graciously; be critical of issues early to avoid them growing. Waterfall style development was rejected for inflexibility years ago and this is across many industries; my friend who is an draughtswoman described the reduction in details for plans as they iterate on them during the build.

Regular iteration is great for getting the best result, but talk to developers and it is a chore to have meetings at such a regular interval. Too much planning, not enough development was the description in the team when we did scrum at OpenBet in London. 
Improving outcomes without more process (user stories, demos, iterations) in front of development, but where do we find cost benefit? These are things that require a fair of pragmatism to implement and I don't believe rigid structures of methodologies can adapt adequately, no matter how agile they are. This is why every manager has their own flavour - just like in life pragmatism wins vs fixed ideology.

Separating the Technical

For me, it is a matter of understanding that my view on how things should work is distorted once I start working on the code. In a consulting capacity I have talked with developers as the technical representative for the client, there is nothing more frustrating than being told how the software should work when you (client) are paying for it. 

So stepping back and seeing that although your decisions probably have a good bearing on what should happen, that does not make it so. Listen to the client, iterate often. Identify and avoid the confidence of knowing the software too well. Dive into the requirements, understand the business but do not think you can completely understand how the product will be used.