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

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

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).

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.

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.

Personally, if the application has a UI, that's where I start as this normally drives out the processes and workflows.

Paper prototyping where it makes sense and reiterating the design as I work.

If this is going to be a command line application, I think very carefully about the command line options, defaults and normal usage patterns before I start work.

My general workflow tends to go along these lines:

1. Capture requirements (define inputs and anticipated outputs).
2. Design something that could work (main program structure / data flow ideas to explain how to get from the inputs to the outputs in the requirements).
3. Prototype any algorithms and check with real data (generally in excel and/or python to prove that we can get from input to output).
4. Implement a solution (code up the result in C++/.net).
5. Test to death / fix any bugs which are brought to light (validate against the earlier models and any other tests which seem important).
6. Optomise any major bottlenecks or usability issues.

I generally build embedded software solutions and/or GUIs to connect to those systems and manipulate them / display output data.

I start with workflow and functional requirements. I get that working independent of UI (usually with command line tools and scripts), almost always with three test frameworks (full functional/unit test, quick "up and running" status check, and performance stress test). Last step is the user interface.

I start with design from requirements. If the requirements call for a UI then I'd tend to design that as a sub-task, and design the computational engine (or whatever you call it) as another sub-task; this is sort of MVC with clear separation between M and V, with C providing the link between them. So designing C becomes another sub-task.

But I rarely have the luxury of designing anything from scratch these days, I'm much more likely to be adding new modules and new functionality to existing systems. In such cases most of the UI design has already been done, so has a lot of the M design.

And I hear that Test Driven Design is a popular movement these days, so Tests might be another starting point for you to consider.

I always start with requirements, then design the database, then design the app. An app designed before the database is a recipe for problems. I think it is interesting that no one else even seemed to think that designing the database was important enough to mention. No wonder there are so many poorly deisgned commerical applications out there.

I start with raw data. Not even with data structures, but with integers, floats, arrays of strings, arrays of integers and so on. There's no uml diagrams or user requirements, no class hierarchy or inheritance, no class or function interfaces, no workflows or processes.. Just a single algorithm that produces a single set of data.

I've little experience in programming and design, but what I do have is mostly interfacing with databases, so that's where I start. When I'm given a problem, I sit down for an hour and draw out the database schema, create it, then add my SPs and views.

Next, write the queries and the forms, the actual HTML, and the JS and CSS that makes it look all so pretty (or not, which is generally the case with my "designs").

So, in the MVC model, I guess that's M first, then V? I haven't much experience with MVC.

Is this a relatively natural way?