Object planning or user-flow planning - which should come first?

Question

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?

Answer 1

I would certainly suggest laying out the user-flow first, in this case, because it is so specific. With a more common UI, it would be easier to plan/guess the objects. However, since you have a detailed spec for application flow, deal with that first, as planning objects too early will certainly miss the target for a good deal of the spec.

Answer 2

User-flow first : you're building software FOR the user. Once you know what you need to do (the whole picture) then you can think about how you want to do it.

Answer 3

These can happen in parallel, and need not be finished before coding begins.

With iterative development, you will not necessarily design up-front either the whole software on paper or the whole class model.

User interactions impact the class model. However, you may have enough information to begin designing some architectural layers before user interaction design is complete. For example, the data model may be known in whole or part before you've begun designing specific interactions.

Schedule concerns may make working in parallel more desirable, especially if you have multiple staff contributing from the beginning.

Answer 4

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.