How/When to design an interface?

Question

I'm trying to get in the habit of designing the interfaces to my websites at the very beginning before I do any actual coding. I've read "Getting Real" by 37 signals and they recommend doing the interface first, before any actual code is produced.

What exactly is meant by that? Does that mean use pure HTML and CSS to design the site and add php, js logic to page afterwards, or is it okay to sprinkle in the php, js from the beginning?

What if your using a framework, should I set up empty controllers that simply call the views, or should the early stages be solely html, css?

Also, what do you guys think about design first vs later?

EDIT I'm talking about AFTER I have sketched everything with pen and paper.. I'm taslking solely about the html mockups. And I'm not too sure about using extra tools that I would need to learn to do this

Answer 1

Get a pad of paper. Each page represents one page of your site.

Sketch the interface. What controls go on each page? What controls are the same on each page? What forms are there and on which pages? What happens when user clicks on item x? Item y?

This will help you solidify your plan of both the content and behaviour of your site.

If you just start blindly coding you will end up with burnt spaghetti.

Answer 2

Let me ask you this. Do you paint a car before or after you have made the working parts? Maybe you have chosen which paint but ultimately it cannot go on until the car is finished. Maybe you don't agree with this analogy but I think coding will bring out issues that cannot be understood before a site is designed. Code first, design second.

Answer 3

I think that the majority of the benefit of designing the interface first has been achieved after you are done your paper sketches. Basically, you are just ensuring that you have a design in your head and that your coding process is somewhat end-user driven. You are also trying not to waste time on needless documentation.

Getting the HTML in place (or the skeletons of the Views in an MVC app) makes some sense and this is the main thrust of what 37signals says. I would certainly not do anything beyond this that is just going to be thrown away.

I think if you have a proper design, it is immaterial if you next move on to writing the back-end code after the HTML or if you do the CSS and JavaScript. The CSS and the code should not even need to be aware of each other.

Do whatever gets you excited and motivated. Do whatever gets you thinking more deeply about how the app will actually work so you can catch any flaws in your original thinking. I like to code before CSS but that is just me. You might find it important to get the CSS further along before the app takes shape in your head.

Joel Spolsky likes Balsamiq as a mocking tool. I think that 37signals uses Draft (an iPhone app). I use a Sharpie. The key is not getting too detailed though.

Opinions vary, but I believe that JavaScript should come last. I believe most sites should be designed so that they work 100% without JavaScript and then have JavaScript added for polish.

Learn more about Unobtrusive JavaScript

So (for me):

• Quick and dirty sketches of views
• Get some HTML in place
• Maybe some basic CSS for layout (or more if I need to impress somebody early)
• Write the core logic
• Add support for web services and AJAx calls
• Pretty it all up with snazzy CSS
• Write some JavaScript to add the sizzle

Answer 4

The user interface is what the users of the website will see. Before coding you probably start with some very basic sketches of the site that are not code, to identify page navigation, general placement of content and interaction with the site.

But the earlier you can show and discuss a working UI, the easier it is for the users/client to get an idea of the final product. So quickly move to the HTML, CSS, JavaScript and things like images, to identify:

• The data presented on the page (HTML)
• The representation of the data (CSS)
• The interaction with the data (JavaScript)

Doing so helps to gradually develop an actual working UI that you can discuss with the client. This keeps them involved from early in the project. It forces them to think about the site, and make decisions about content, look and interaction.

Getting such feedback early in the project reduces the risk of building a product that needs to be changed later on. And making changes early in the project is easier/cheaper, then later in the project.

While the UI is being developed you can already start looking into data structures, software components and integrations with other systems to drive the site. But that's not what users/clients are interested in, they want to see and use the product.