When starting a new piece of software, do you find it more helpful do plan the interface and use cases first, or outline the objects that will need to be built?
I can see an argument for the former in that you have to know where you’re going before you can get there. But when I say ‘interface use cases’, I mean VERY SPECIFIC application flow. Basically, the whole software on paper.
The second, planning the programmatic ‘big picture’, could enable you to get your head around potential development bottlenecks. It also helps understand application flow and could somewhat change user interaction.
In your experiences, what is the best use of time up front?
I see false alternatives in this question.
Some systems don’t even have a UI! Therefore, you can’t reasonably expect a single, universally applicable answer to this question.
In many systems there are actually distinct object models for Business Logic layer and UI layer, and indeed there may well be more than one UI. For example a Customer UI delivered in a Browser and Thick Client App for the Customer Support team.
Also Use Cases and UIs are not the same thing. The first questions can be: “Tell me about what you need to happen when you create a new Wibble.” No need to talk about UIs at all at first. You can model the scenario just in terms of “I want the system to …”.
Pragmatically when you draw screens you are probably building up a mental model of Business Objects. In a simple business case you may not need to document that model immediately. In more complex scenarios, especially when dealing with legacy back-end systems, you pretty soon find the need to capture some of that model : “So this screen is about Wibbles? And about their Zetules? Does each Wibble have its own Zetule? Oh, Several! And can we change them, pass them to other Wibbles? Oh only Blue Zetules are transferable?”
As has been said before it’s going to be interative and creative. The first cut screen model will change. You will discover more and more gnarly bits.
My explicit answer is: the best use of time up front is to locate dragons. Dragons hide in the unknown. Big dragons are a risk, and hide in gnarly places. Gnarlyness is specific to projects, sometimes its UI sometimes it’s not. When dealing with legacy systems in particular it’s not usually the UI that bites you. Spend the time where the risk is.