views:

298

answers:

7

What comes first? After the design has been outlined and approved, should a designer create pages in HTML and then hand them to a developer to add code? Or should a developer build simple pages that work and hand them over to the designer?

I've always done the latter, but recently worked with a designer who built an entire site in HTML and handed it to me to make it work. I found it saves a lot of time for 3 reasons:

  1. The developer doesn't have to create all the form fields and rudimentary layout.
  2. The designer doesn't have to rework all the "ugly" pages into something attractive, instead starting with a clean site which is faster.
  3. The code isn't accidentally broken by the designer. I've found designers are more likely to break the code doing their work than developers breaking the design adding the backend functionality.

In short, if the designer does his work first, there's very little rework. I just make what already looks great actually work.

So which is best practice? See other plusses and minuses?

EDIT: Assume both designers and developers are already in agreement on the proposed design.

+1  A: 

Best practice is to try it both ways, see which way works best for your organization, then do it that way.

Occasionally try it the other way to see if anything has changed.

That way you get a solution tailored to your situation without worrying about ephemeral transitory things like "best practice".

As you can probably tell, I'm not a big fan of rules being handed down from on-high. Don't get me wrong, if something proves to be an advantage, I'll use it (agile, for instance, since it focuses you on immediate deliverables). But it has to be proven in the environment you work in, otherwise it's just something that worked for someone else.

paxdiablo
+6  A: 

Wireframe mockups and visual aides are a great way to elicit requirements from end users. Giving the user something to look at and see helps to drive the design to where it needs to go instead of developers just doing the guesswork.

Also, UI design does affect your code. I think the biggest myth that we buy into as programmers is that we can just build a business layer and then spread the UI on like peanut butter. It never happens this way, so I am a big fan of having designers work with users early on and often. Having a visual design to work against is like TDD for the UI, and it helps to drive the process downwards.

Josh
I agree Josh, but my question is regarding after the design is already complete and everyone is one the same page. Now it just needs built. So my question stands. Who goes first?
Cory House
I say the designer goes first. If not, you will inevitably go down the wrong path and have to rework something once you get the "finished" design. We TRY to do this as often as possible at my place of business, but it has taken a long time to convince the business of the value.
Josh
A: 

I would definitely go with designer first. If the coder does the pages first, he's forcing a design on the designer -- particular for a multi-page form.

James Curran
Sorry, i'm assuming both sides are on the same page and agree with the proposed design. In that case, who goes first?
Cory House
+1  A: 

I think it depends highly on how your views and code behind are set up. Some people will put a lot of logic into their views and others will have little to none. It will eventually just come down to your specific case.

In most cases, I agree, it will be easier to create the HTML first and include the back end programming later. It is essentially making a specifications document for you.

Joe Philllips
+1  A: 

Once you've got your storyboards all worked out and approved, it's probably more natural to do more detailed "sketching" at the HTML level first. But I guess I'd also try to decouple the design and code as much as possible, so that the developer and designer can work somewhat in parallel. Two ways of decoupling are XHTML/CSS and "unobtrusive Javascript".

The developer and designer can work out the skeletal XHTML page structures they'll need from the set of storyboards. The designer then can use static mock pages to develop the CSS style sheets and explore the artwork. Meanwhile the developer can focus on generating the XHTML structures without style information. The big advantage (and goal) of CSS was to separate page structure from page appearance.

Another avenue to explore are "unobtrusive Javascript" frameworks like jQuery, whose goal is to separate the page's behavior from its structure, again making it easier for the developer and designer to work in parallel. By parallelizing these activities, it would be possible to incrementally deliver versions of the final product, both in form and in substance.

Jim Ferrans
A: 

Depends on the type of place you work at and the skill set of your teams!!

I worked for a Design Agency for many years where designers ruled as they brought in the biggest revenue stream and the web work was an add on to the services.

We worked very closely with the designers to make sure the designs met requirements and we not to off spec. The designs were a lot of the time used as sign off (don't get me started!!) and not much could changed once agreed by the client. The designers were also not that good at HTML,JScript,CSS etc so this was left to the developers to implement.

So in this case design was always done first which worked well, even if it was for the wrong reasons.

Cragly
A: 

Well, assuming that the designer produces high-quality HTML and CSS (which is far from obvious, btw), the question boils down to: do you have 100% control of your HTML or not?

If you use a CMS, or a framework that likes to produce lots of its own HTML (like ASP.NET), then you have no choice. Trying to make the output match the designer's HTML is a pointless headache. You'll be better off with your original method.

However, if you produce all of the HTML by yourself (using PHP or, say, a lightweight framework like Django), it's better for the designer to produce the HTML first, for the reasons you mentioned.

Small nitpick: I disagree with reason #2. CSS-based design is all about taking "ugly" (that is, bare and functional) pages and making them attractive, without even touching the HTML. If the developer writes decent, semantic markup, it should be pretty easy for the designer to add his design on top (well... with some HTML hacks added, like for round corners and the like), since this is what he should be doing in the first place.

Eli Krupitsky