views:

123

answers:

3

How do most modern "pro" web designers go about starting/designing/coding a site?

I realize that techniques will range and differ drastically, I'm just looking for some solid, relied-on tactics or approaches.

For example, "I know most draw out a rough design with the client, then go into photoshop and create it, then slice it up, then code it by hand..." etc. Obviously an answer doesn't have to be this generic.

I know coders aren't always the designers, but I'd like to hear typical approaches from both spectrums.

I'm learning web design and coding right now, and my main problem is knowing the parts, but not the sum of everything -- not knowing how one is "supposed" to go about creating a full fledged, multi-paged site.

Thanks!

+1  A: 

I like to design my web sites / applications bottom-up. That is, I start by analyzing the problem domain and translating it into a data model (e.g. an SQL database). Then I build a data access layer and business logic on top of that, then some presentation logic (typically some generic code that can call business logic functions and pump plain data through some sort of template), and finally the templates and stylesheets that define the look and feel.

For the actual graphics design; either I do it myself, in which case I tend to write HTML and CSS directly, or someone else does it for me, delivering static HTML which I turn into templates.

tdammers
I like this approach too. I think it's important to plan out *all* your data models in the beginning (before coding) and how they will interact with each other, then maybe run through some mental use cases and see if they can handle what you had in mind. Once you start building layer onto layer onto your DB models, they start to get ugly, and they're incredibly hard to change after you have code in place, or worse yet, actual production data.
Mark
+2  A: 

This is a very wide question, not having a simple and clear answer. However, you are on the right track. It all starts and ends with the users... what are their goals and how are they expected to reach their goal? Should they complete tasks or find information?

  • Every design process start by a strategy. Ask yourself what is the purpose of the site and what are the user needs. Without a clear strategy, projects are more likely to fail.
  • Second, you define the scope of the site. Which content requrements and functional specification do the site have.
  • Moving on to the structure of the site. We are now concerned with Information Architecture (Labeling, Navigation, Organization and Search) and Interaction Design. On the market there are various techniques and tools to find out how user relate labels to information, like to navigate and so on. The initial user tests can be performed in this early stage to verify that the project is on the right track.
  • When all the above have been done, its time to start draw the site on a piece of paper. Where will certain elements be, and how will users interact with the site. You can also use a drawing tool like Balsamiq Mockup to build the skeleton.
  • Last, you implement the surface; colors, images and the real coding begins. Visualization takes place, and hopefully more user tests.

Remember though, design isn't a straight forward process. You have to iterate through every design step, moving back and forward between these layers, until you have a good result.

Finally, do some tests of the site targeting the intended audience. User tests make all the difference.

Reference and more to read: Jesse James Garrett: The Elements of User Experience.

BennySkogberg
A: 

There's a world of difference between a website and a web-application. A lot of website clients don't really know what they want to say, they just want to have some form of presence on the web. Finding out what content to put on there is usually the hard part.

So for the website I start with the aesthetics. I make a mockup in photoshop, and only when that has been approved I start coding it in plain html and css. This makes the second mockup, which is then laid before the client again. Then I start writing any logic behind (if needed, since often, static is enough).

For web-apps it's often the other way around. Usually I'm not really in charge of the looks there, so we start with the logic domain and unit testing. After the backend is properly tested we start bolting the front-end on it. On these apps, aesthetics usually take a back seat to functionality, so mocking is less important (on my projects at least). It's usually all panels and buttons and comboboxes anyway, except for the masthead.

Then again, I'm not a pro designer.

Joeri Hendrickx