Whether or not questions like these are effective, the point of them is to engage with someone in a way that illustrates how they tackle complex, loosely defined issues: the majority of engineering problems in a nutshell. In most modern tech companies, good communication and not being afraid to ask questions are absolutely essential. Someone who will take an incomplete list of requirements and draw up an entirely incomplete product without questions or discussion is as much a liability as someone who takes the requirements and does nothing, paralyzed by indecision and not knowing what to do. And oftentimes, candidates aren't perfect but you're going to hire them anyway. Going through this process can illustrate how you would expect to interact with the candidate and where the initial rough spots will be as the candidate begins working with the team.
From another point of view, candidates are usually more than prepared to talk about anything on their resume. In some cases, this is equivalent to listening to someone give a prepared speech. Asking them free-form questions like the above can be a good way to understand how the candidate reacts in situations where they aren't fully prepared. For some positions this is irrelevant, but for others it's incredibly important to have some measure of poise and thoughtfulness when engaging with someone who doesn't necessarily agree with everything you say and is questioning your thought process.
In short, these kinds of questions aren't primarily testing your design and programming abilities, but your ability to communicate and reason with another person in a technical context.