It sounds like you're trying to get him to describe the solution rather than the problem. Non-programmers have a very difficult time thinking about software that way. To them, it's an unchangeable product rather than a flexible collection of components.
What you need at this point is a thorough problem description. He has no idea what the opening screen should look like as long as it solves his problem and doesn't introduce new ones.
For example, my wife told me she was looking for new budget software because with our current software she never knows how much money is really available. This surprised me because our current software is always synced with the bank and breaks things into nice categories, notifying us when we get too close to the budgeted amount. I asked why that wasn't enough, and she said it's too much work to keep up with entering receipts that haven't cleared yet, which often are for significant amounts, and there's no way to forecast based on transactions planned in the future. By the time transactions clear the bank it's too late to be useful in planning.
Notice she's describing the problem, not the solution. Part of the solution she didn't know she needed was a smartphone app with an ultra simple interface to quickly view the available budget by category and enter receipt amounts at the point of sale, and which automatically syncs the transactions to a more full featured application for use at home. As soon as I presented that to her, she said it fit her requirements perfectly, but she said she would have never thought of it on her own.
In other words, you need to gather requirements from the customer's point of view of the problem that needs solving, and leave the design details to the software professional. On the occasions when customers do care about the details, they usually have no problem letting you know. It's your job to present the design incrementally enough to allow them to provide feedback without causing yourself too much potential rework.