Where do you start your design - code, UI, workflow or whatever?

Question

I was discussing this at work, and was wondering where people start their designs? We tend to start with designing code to solve the problem presented to us, but that is probably all of us are (or were) programmers.

I was wondering where other people and organisations start their design. Do they start with solving the problem as a coding problem, sit down and design what UI to use, or map out the data or workflow?

Thanks

Answer 1

I always start with workflow/process. I have found when you start with modeling business process/workflow generally you tend to get more information that makes the UI more usable, and the code/requirements tend to be more suited to the users needs.

People generally make the mistake of starting to design code/UI before they truly understand the workflow. With that being said, if you understand the big picture, then you can start design on any of the 3 workflow, code, ui (and thats in my preferred order).

Answer 2

I think the answers you get to this question (as it stands) will mostly reflect the types of applications designed/created by the people writing the answers. Just for example, if you're designing a program that will get data from one database (or some source anyway), massage it as needed, and then put the result into another, chances are that you're going to start by thinking about database schemas, data flow, and data encoding/formatting (probably in about that order).

On the other hand, if you were writing a typical desktop program of the type that opens a file, allows the user to edit its content, and then saves it (whether it's a photograph, word processing document, speadsheet, or whatever) chances are that database schemas won't jump to the front of your thinking. Somebody who's looked at (for example) the specs for the Microsoft Office file formats would probably have room to argue that in some cases, the design would be better if more up-front thought had been put into the format, but it usually won't be anyway.

To get a more meaningful answer, I think you need to step back a bit from simply "what is your approach to solving the problem?" to something more like: "What is the relationship between the type of problem and your approach to solving it?" Otherwise, most of what you get is usually going to be little more than an indirect statement about what kinds of problems that person has worked on.

Answer 3

Why not start with the acceptance tests?

One of things I've been pushing for in recent projects is to ensure that the test team gets involved a lot eariler in the project. If you can't agree an acceptance criteria with the customer the question must be asked, are some of the project requirements really needed?

To this end I'm now very interested in testing frameworks that attempt to capture requirements in a testable manner, eg:

• easyb
• concordian
• ..

Perhaps an up-front automated acceptance test/requirements management framework would allow more than one solution to be tried out.