Say you are going to build a fairly large website.

Would all the pages be designed before they are built, or would all the pages be built and functional before they are graphically designed?

I am a programmer and a graphic designer. When build a new website I usually have a rough outline of all the pages I am going to need and how they are going to work. I then usually start to build the pages, as I build the pages I tend to design the graphical interface at the same time.

I am starting to think this is bad because each page ends up looking good, but not uniform. Or even if they appear uniform they really aren't. For example, on page A and page B the heading looks the same but on page A it has a 50px margin while on page B it has a 50px padding. The styling for the heading on page A is defined in one CSS file and the styling for the heading on page B is defined in another. Over time it can become a giant mess.

I need a new approach.

There are many ways I have learned to keep this kind of thing from happening in code (DRY). I don't really know how to apply them in this area though. Or maybe I just don't currently have the discipline.

One idea is, after the project outline is complete, create graphical designs of how all the pages will look before I build any. Then I should be able to design the styles before building the pages so I won't be introducing duplicate style definitions as I build.

The problem is, before I design a page with HTML/CSS, I design it in Photoshop. However, they don't always workout exactly the way I designed them in Photoshop. Sometimes I have to make adjustments to get it to look right on the page. Sometimes the adjustments needed differ from page to page. I don't see how I can plan this ahead of time.

What's the normal workflow for something like this?


What you are looking for is the idea of Wireframing.

I use WireframeSketcher with great success on all the graphical components of all the projects we work on.

Whether it is a website, a desktop applicaton or a mobile application, the wireframing step is critical.

Next step is Mock Ups where someone actually does the graphics and other things in Photoshop or some other tool, to show what the graphics, colors and fonts will look like.

Then you do your development from the mockups.

| improve this answer | |
  • Are you using the standalone app or the eclipse plugin? – yannis May 24 '11 at 22:41
  • @ Yannis Rizos I have used both, it works exactly the same either way. – user7519 May 25 '11 at 0:44
  • So if I am following you correctly, after you decide what pages are needed, you do wireframes of all the pages. Once they are agreed upon you make the Photoshop mock ups and finally once they are finalized you build the pages functionally and graphically from the mock ups. – JD Isaacks May 25 '11 at 13:15

The typical approach is to design wireframes beforehand (ie. rough outlines of all the pages) and then a developer and a designer work in parallel:


As for your specific problem I would recommend doing a sort of "design bible" between wireframes and developing anything. A term for what I'm getting at is "design language":


Basically, design a few generic example pages to establish overarching themes and visual rules (eg. panels are always outlined with rounded blue borders) but don't get bogged down in the specific functionality and don't bother trying to build any specific pages. Then you can refer to these established rules when making design decisions later.

| improve this answer | |

I'd go with the idea of having a mini version of the site,e.g. just 5-10 pages, and seeing what overlap there is. What kind of simplification could be done to keep the site lean? Why couldn't you apply DRY to the HTML/CSS of the site?

Trying to do all the pages first in either form could be overwhelming to my mind. I'd do a bit of each rather than trying to do all of either before moving on to something else. This is a bit of an Agile idea of having a small working prototype that other things get added over time as there may be changes to what was originally envisioned.

| improve this answer | |


Sometimes alternating between design to talk about the idea, quick-and-dirty mockups so that the working elements can be tried out by test users to create functionality feedback, and then design again to create even more feedback as to appeal and usability. Rinse and repeat.

| improve this answer | |
  1. Divide your project into big meta blocks.
  2. Define the overall interfaces.
  3. Build small prototype versions for all these boxes which don't have all the functionality/scale/concurrency requirements.
  4. Build UI on top. For UI, Wireframes in any way work - I have built wireframes with Visio/PPT/mspaint(gulp!) and they have all solved the initial start up problem.
  5. Once you get something up and running - and repeatedly interact/improve.

That is the best way IMO.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.