Although I don't agree with the tone of the answer, I do kind of agree with the message. I think you're trying to play basket ball with foot ball rules. He obviously is not interested in going a "traditional" route of explaining every intricacy of the application, go through all the hypothetical scenarios, and mentally building the solution in his head and envisioning it before you code. The thought that you could change that is, in my opinion, wrongheaded and doomed to cost way more in the long run, contrary to what people are saying here. I think the teachable moment here is indeed for you, not him. This is a good example of why "traditional" methods perform very poorly, and why an "iterative", and more so "lean", approach is a better tool for this job. DO take this mock up and DO create a, more or less, wireframe app around it. Do this quickly and do not think too much about it. You will find that by giving him a more concrete example of the application and flow you will learn much more and much faster. Once he sees it for his own eyes and does not have to think abstractly about the application, I think you'll find that he will describe it more and more. Perhaps even create that fast screen, and after that, do think about it and create a different screen with things tweaked in the direction you'd like to take things as you see them now. He'll tell you where you are right and where you are wrong. If everyone had the ability to visualize a complex system like you are building (why you building one rather than buying one would be my first question, anyways) then no one would need your skills. His skills are obviously more interpersonal or sales related. I'm not sure what mix you have, but I think the FIRST thing you need to realize is that you CANNOT change someone fundamentally. You need to look at things differently and seriously challenge yourself to find a way to take his strengths and utilize them, rather than fix his weaknesses. (Hmmm... I think there's a book about that... right? :-\ )