design or develop first?

[Kailash Badu]

I am primarily a developer and write backend serve-side code more often than I do CSS/HTML.
Well, I might not need to know the frontend before being able to write classes and generic functions but I do need a basic interface and page structure in place before I can write the code that is responsible for generating web pages. It generally tends to be a minimal interface, however, which can then be replaced with a full-fledged design once the backend is over. Keeping view logic separate from business logic eases the task of editing/replacing design enormously.

In some projects front-end and backend go hand-in hand. I keep updating the interface as I add more functionality in the backend.

[slayerment]

I think the development should come first and the design should come last. The design is something that should be tweaked and tested for conversions and therefore will always be changed and improved, but the backend will change much less.

[Dijup]

I think the development should come first and the design should come last. The design is something that should be tweaked and tested for conversions and therefore will always be changed and improved, but the backend will change much less.

I think it is better to have the design of the project [either UI or logical design] Ui come first because ever project is made for the user so UI should be there so that we can target our plan according to that.

[Dijup]

Personally here is my method.

1. Draw and design the sites appearance.
2. make a site map along with a database map...
3. start developing the basics of the site
4. start developing the "dynamics" of the site and integrate them as you would for a database driven website.

for the planning stage for the db I like to use mysql workbench.. pretty much plans it all out for you or allows you to do so.

here is the link http://dev.mysql.com/workbench/

Sound like a good plan?

Sound Good!

[Edman]

The thing that I noticed back when I was working with clients was that clients don't really know what they want.

This is why I make designs first. Then code HTML files so that we can see what the design/functionality will look like in a regular screen (this is before doing any backend coding). Every client's initial design has changed dramatically, and with design changes there have also been numerous functionality changes. If we started with coding or started coding only after the initial design, a lot of coding time would have been wasted, and then ending could would probably be of poor quality due to all the changes it would have to undergo.

[invision2]

I always plan the entire site out on paper, using a site map and just scribbling.
Then design an idea for the layout(because I'm not great at it, I like to get it out the way!)
Then develop it as I feel more adept at this part and enjoy it most

Then revise all 3 areas 'til the client and I are chuffed

[Zanicar]

I have noticed that no one made a distiction between interface design and interaction design, I mention this because I am of the opinion that interaction design is a sub-set of the interface design.

For most people the interface design involves the full front end, namely images, backgrounds, mouse-overs, etc. Interaction design leaves most of these out by stripping the interface down to interaction elements. These are simply the text, links, buttons, etc. needed by the user to do what needs to be done.

Coming from a systems engineering background I prefer to do the interaction design first (use-case analysis). So I start with the XHTML as my interface and create a mockup in Photoshop. Then I develop the back end and test to ensure the interface is easy to use even without the aid of any graphics, images or effects. Lastly I integrate the mockup into the interface with CSS.

The major advantage of this approach is that all my sites and applications work on mobile devices by default, I do not need to change anything for it to work... I only have to optimize my graphics for smaller screen sizes.

[Dijup]

I have noticed that no one made a distiction between interface design and interaction design, I mention this because I am of the opinion that interaction design is a sub-set of the interface design.

For most people the interface design involves the full front end, namely images, backgrounds, mouse-overs, etc. Interaction design leaves most of these out by stripping the interface down to interaction elements. These are simply the text, links, buttons, etc. needed by the user to do what needs to be done.

Coming from a systems engineering background I prefer to do the interaction design first (use-case analysis). So I start with the XHTML as my interface and create a mockup in Photoshop. Then I develop the back end and test to ensure the interface is easy to use even without the aid of any graphics, images or effects. Lastly I integrate the mockup into the interface with CSS.

The major advantage of this approach is that all my sites and applications work on mobile devices by default, I do not need to change anything for it to work... I only have to optimize my graphics for smaller screen sizes.

I think you missed out the topic.

design or develop first?

[Vilice]

first design in mind .Then according to your design,develop your site .After the development completed .Start to design your site according to your mind design .

[Zanicar]

I think you missed out the topic.

design or develop first?

Design interaction first, then develop, then integrate with any graphics design (done before or after... consider CSS Zen Garden as an example)

[Dijup]

Method.
1. Draw and design the sites appearance.
2. make a site map along with a database map...
3. start developing the basics of the site
4. start developing the "dynamics" of the site and integrate them as you would for a database driven website.

this is the some what solution what i think for this question

[Fre420]

1. develop a website strategy: get to know the company, the targetgroups, the goals, plan the metrics to measure the goals, develop persona's, ...
2. wireframing the basic information architecture (paper)
3. storyboarding: filling in the wireframe with persuasive copy & interactions (paper & prototype software (axure, visio) )
4. prototypes: from a paper wireframe to a simple HTML mockup, adding design details (from black & white design, to grayscale, to color ...). Basic interactions with javascript tests (or just in html). --> end result fully working HTML template (90% of design laid out, most of the html & classes won't change, every positioning property of the CSS is +- done, crossbrowser tested)
5. development & final design: finalize the design with details & finished images, finalize the CSS & HTML. start developing the back-end & database.
6. during the comming months/year : optimization, improve the website based on your metrics & goals, & user behavior on your site. (you never get it 100% right from the first time)

during wireframing --> development & final design : testing & testing & testing
with the persona's (try to get them accomplish their task) or small user tests.

[Rblakney]

I usually design first.

[dgroves]

I tend to be torn between the two ways, I love design but I am c**p at coming up with ideas. I always have awesomely complicated ideas for the back-end, but hey I soon lose all motivation without the design. If I do design first then I am sick of my design, and want a redesign by the time I have finished! So what am I to do?

[sojankf]

First do the backend including database design, coding and debugging after that do the graphics works. It is the proper way for a developer. I go this way because basically I am a programmer.

[mkoenig]

I personally stick to these 18 golden rules and work like this in everything that I do (skipping any steps that aren't relevant to a project). To some this would seem anal but I am just very very particular and like to ensure that there are minimal things to go wrong on launch.

You will notice that I leave all designing, CSS and visual testing until last. This is due to the fact that durig development I am often asked to add extra features or more UI elements to the app, and so dont want to waste time messing around in Photoshop everytime the client adds in an extra drop down. I prefer to do it last when all the functionality is in and working and I can just lay my styles around everything else (I seperate all logic from styles anyway so its actually easier.)

1. Database Design and Architecture - On paper
2. App Design i.e. flow, actions, plans for functionality - On paper
3. Setup Dev and production environments
4. Create Database - On Dev
5. Write all core logic and functionality - On Dev
6. Write all testing units to test every piece of logic and functionality - On Dev
7. Test and Debug in all browsers -On Dev
8. Upload to production servers but make inaccessible to public
9. Test and Debug in all browsers on Production Servers
10. Create Designs and Concepts in Photoshop
11. Create, slice up and optimise all graphics
12. Write CSS, Make sure all XHTML and CSS is standards compliant and accessible - On Dev
13. Test again on Dev but this time for visuals (all browsers 800x600 - 1280x1024 resolutions)
14. Migrate to live servers (again not accessible to the public)
15. Test visuals on live servers
16. Migrate fully to live servers (allow access to 5 people for User Active Testing
17. Fix all bugs found and make amends given
18. Launch to the public.

Wow... thats pretty intensive.

I think you should get the backend working before worrying about what the site ultimately will look like. If you get the design going then start working on the backend and run into problems you either can't overcome or can't afford someone to overcome for you you've wasted a lot of good time.

[wwb_99]

Really, really depends on what the application is doing first. Personally, I prefer to design and build the logical domain then bolt a user interface on top of it. Building the back-end around a specific UI is generally an exercise in folly in non-trivial applications.

[Edman]

Really, really depends on what the application is doing first. Personally, I prefer to design and build the logical domain then bolt a user interface on top of it. Building the back-end around a specific UI is generally an exercise in folly in non-trivial applications.

I agree, but if we're talking about web stuff, you'd be hard pressed to find a non-trivial application.

[NetNerd85]

I personally stick to these 18 golden rules and work like this in everything that I do (skipping any steps that aren't relevant to a project). To some this would seem anal but I am just very very particular and like to ensure that there are minimal things to go wrong on launch.

You will notice that I leave all designing, CSS and visual testing until last. This is due to the fact that durig development I am often asked to add extra features or more UI elements to the app, and so dont want to waste time messing around in Photoshop everytime the client adds in an extra drop down. I prefer to do it last when all the functionality is in and working and I can just lay my styles around everything else (I seperate all logic from styles anyway so its actually easier.)

1. Database Design and Architecture - On paper
2. App Design i.e. flow, actions, plans for functionality - On paper
3. Setup Dev and production environments
4. Create Database - On Dev
5. Write all core logic and functionality - On Dev
6. Write all testing units to test every piece of logic and functionality - On Dev
7. Test and Debug in all browsers -On Dev
8. Upload to production servers but make inaccessible to public
9. Test and Debug in all browsers on Production Servers
10. Create Designs and Concepts in Photoshop
11. Create, slice up and optimise all graphics
12. Write CSS, Make sure all XHTML and CSS is standards compliant and accessible - On Dev
13. Test again on Dev but this time for visuals (all browsers 800x600 - 1280x1024 resolutions)
14. Migrate to live servers (again not accessible to the public)
15. Test visuals on live servers
16. Migrate fully to live servers (allow access to 5 people for User Active Testing
17. Fix all bugs found and make amends given
18. Launch to the public.

This is brilliant and have to agree with the pure logic of this process. If you don't nail down the HTML wireframes (website without CSS or graphics) and the functionality then you will get feature creep. As someone who works in a web development company I see them make this mistake all the time (I have experience with another company as a Team Leader so I've seen it all before). In my spare time I develop things for myself - so I am the client and users. It is very easy to keep adding to a project if you don't have the discipline or the balls to stand up to a client (most people don't which is frustrating). I constantly have to re-do things for clients because of communication break downs and poor project management, it's called a PHASED process people

Great process neron-fx it's basically what I do too, I'm going to print it out now and pin up on my wall. I need it in my face as I have three new projects on the go got to stay focused.

People should, no, must read Getting Real

[tentim]

I faced the same dilemma recently,and was
going nowhere with the project untill I got a
brainwave-DO THE BACKEND FIRST,THEN THINK
OF/FIND A DESIGN TO FIT.And i'm happy with that.
I think its because i'm better at coding.Though i
already have the whole concept(interface) in mind.
So,i think you should start with what you do better/
find easier/happier with,having a sketch of the whole
concept in mind or paper.
Generally,i think codes are more flexible-it is easier to
adapt codes to whatever design than do the opposite.
So it might be better to do the backend first.

[r937]

I agree, but if we're talking about web stuff, you'd be hard pressed to find a non-trivial application.

so you're saying it's easy to find trivial web applications, but difficult for find non-trivial ones?

i disagree!!!

[dgroves]

Although I am primarily a designer, I think it is important to the back-end first. How can you design a layout for something before you have something to put into the layout? Something may go wrong and then you end-up having to make major changes to compensate for these changes.

[mexabet]

Since I started out as a designer, I naturally tend to design first and develop later. But lately I've been having difficulties- having to go back and change a lot of time-consuming design layout. So now, I'm gravitating towards developing first.

[geosite]

This is brilliant and have to agree with the pure logic of this process. If you don't nail down the HTML wireframes (website without CSS or graphics) ...

Is that the definition of a wireframe - a website sans CSS and graphics? I never really noticed that term until I was checking out some jobs just a couple days ago. The context suggested it refers to sort of a website blueprint.

[r937]

yes, exactly like a website blueprint, except without the blue and without the print