7 Crucial Tips for Designing and Maintaining a Large Site

Projects vary in scope and size, and the challenges they entail vary likewise. As a lone web designer, the biggest job I am responsible for is FlashDen. Along with thousands of active members all chatting, uploading and buying, the site processes large amounts of money and large amounts of traffic.

Designing, redesigning, maintaining and working with developer team has given me some useful insights and tips for making life easier. And since today we’ve launched my latest redesign of the site, it seems like a good time to write up my top 7 tips!

1. Design and Code for Maintainability

The first and biggest tip I can give, is to design the site so that it’s easy to maintain. Often times when designing a site you might sacrifice things for aesthetics. For example you might use images where text or styles would suffice. Or you might deliberately choose a menu structure that has no room to grow. When the site is large, this becomes a really bad idea.

When I built the very first version of FlashDen almost two years ago, I used images for buttons. They looked really nice, but I wound up with a library of 100 different button images, not to mention rollovers. Then in the next couple of months every time a developer needed a new button they had to ask me to create an image. Needless to say I learnt that lesson pretty quick and we switched to a single button class that maybe doesn’t look as good, but is much better for peace of mind.

Another aspect of maintainability is thinking about how the site is going to grow and change. For example, as new pages get added on, where do they go? Early on I wanted to have a horizontal navigation, but this is really limited After some experimenting, we wound up using a vertical nav, allowing for submenu items, and then on top of that, added a tab structure into pages to allow for related pages to be grouped together. I’m not saying it’s the best navigation in the world, but it certainly means we’re not redesigning every time a new section is added to the site!

So in designing for a large site, look for ways to make life simpler later, because you’ll be glad you did!

2. Figure out your User Groups and Tasks

One of the biggest differences between a large site and a small one, is the number of different user types who might be using the site. For example on FlashDen, there are buyers, authors, visitors, admins, and members. Each group has a different set of aims and tasks they have to carry out. Sometimes these tasks overlap, but sometime they are quite different.

The best example of a place where user tasks are at odds with each other is on a homepage. Nowhere else on a site does every user group converge, and nowhere else is it so vital to make sure everyone gets what they want. And of course you have to be careful that in serving one user group you aren’t ignoring another.

In this latest redesign of FlashDen, the biggest area that I worked on was the homepage. The first thing I did was list out to myself all the things that each user group needs to do:

  1. Buyers – People who are on FlashDen to purchase files
    Start browsing items, start searching, access their personal homepage, deposit money, learn how the site works (for newer buyers)
  2. Authors – People who are selling goods on FlashDen
    Chat with other members, get featured on the homepage to push their items, find out about site news, quickly get to their portfolio & earnings
  3. New Visitors – Potential Buyers/Authors/Members, who have just arrived
    Learn what the site is/does very quickly, get started, find out types of files and prices
  4. Members – People who aren’t really buyers or authors, but just participate in the community
    Chat with other members, see site news, browse files
  5. Admins / Reviewers – Our staff who manage file approvals, moderate forums, and generally participate
    Get quickly to file approvals, see the latest forum threads, hear site news

When you know what different user groups want to do, then you can design a page that solves all their needs. Needless to say this is a task that gets exponentially harder the more groups and tasks there are. On other pages in the site, you will often get a subset of user groups to worry about, but on the homepage they all converge. Not coincidentally, the homepage is the most important bit of design work you have to do on a site.

Before you can solve the different needs though, you need to prioritize the user groups, and in order to do that, you’ll need to understand what the site is trying to achieve.

3. Understand the Site Goals

Although every user group naturally feels they are the most important, it is up to you to prioritize them according to what the site itself is trying to achieve. For example on FlashDen after sitting down with the team we drew a few conclusions as follows:

  • The top priority for the site is to serve buyers. When buyers are served well they keep buying bringing income and simultaneously serving the authors.
  • It’s vital to get new visitors to quickly learn about the site and hopefully become members. FlashDen is still in a relatively new market, and new competitors are still appearing, so that makes it more important to capture visitors and convert them to buyers or authors or members.
  • Authors are important because at its heart FlashDen is really about her authors, but out of all the user groups they are the most committed to the site.
  • Members are not as important as Authors and Buyers, but do contribute to the community surrounding the site.
  • Admins / Reviewers are the least important as they are a paid group.

So following from this, it’s possible to conclude that the homepage needs to server users in this order: Visitors > Buyers > Authors > Members > Admins.

Understanding what your site is trying to achieve is the final thread that sews your user tasks together and tells you what you should be trying to put on the page. Ideally on every key page you should identify the user groups, tasks and priorities. For a vital page like the homepage I do this formally on paper, and for lesser pages I will often just do it in my head while designing.

4. Design, Refine, Refine, Refine …

It’s only after you’ve figured out user groups, tasks, site goals, priorities and so on, that it’s time to design! It is really vital that you do this first, because on a practical level, it dramatically lowers the odds that you are going to have go back and redo your design. Whenever I have just started designing a big site, without really analysing first, I have inevitably had to rework lots of screens or even whole interfaces.

Lots of designers like to use wireframes at this point – that is to simply lay out a bunch of lines and boxes indicating roughly where things should go. Personally I prefer to work in Photoshop from the start because I’m quick enough and it lets me really see what’s going to happen. I also think that there is more to information design than where something appears on a page. Simply altering colours and background colours can make a page element further down the page suddenly seem more important.

Once you do have a rough idea of how the information needs to work together, you should come up with a working design that is generally OK, and then refine, refine, refine. I often will wind up with 5 or 6 versions of the same look, where I’ve tried varying different things like type sizes, images, layout alterations, backgrounds, and so on, to see how it affects the information you’re presenting.

No matter how good you think the first layout is, I can guarantee that after spending more time and coming up with more versions you’ll have discovered that your original wasn’t quite as good as you first thought. Sometimes you wind up throwing out the whole design and starting again, but if you do have a good base, then refining should get you to a great finish.

5. Get Others’ Opinions, but Make the Final Calls

In any large job you are going to have a lot of other opinions involved. In most cases these will be the opinions of your client. Prior to starting FlashDen, I used to work with all sorts of companies building websites. Among them I did have the misfortune to design for several large insurance companies and a few governmental organisations. I say misfortune because when you get to that size of client you are dealing with a lot of stakeholders, and in many situations it isn’t clear where the real power to make decisions lies. This can result in endless meetings, endless changes and a high degree of difficulty for carrying through your vision.

Whatever the client, it’s really important to get their opinions. Aside from anything else in most cases they know a lot more about the business than you do. Hopefully they also know more about the users than you do, and with this knowledge will be able to give constructive advice.

It’s also important to get the opinion of the development team you are working with. At FlashDen we’re fortunate to have two devs who have a lot of skill in user interface design and usability. And their input, along with the rest of the team, made a lot of difference to the end product.

But in the end, it’s up to you as the expert designer to come up with the final call. If you have a tough client this can be tricky, because a client often believes they should make the final calls. If that is the case, you need to (a) find ways to explain, educate and show the client that your choices are for their benefit; and (b) sometimes bite the bullet and accept the client’s directives as a further constraint in your project, and find ways to make it work.

6. Organise for the Future

When you are coding up a design for a big site, it’s really important to again think about the future. How you manage your files and folders will impact you greatly later. For example recently we have decided to build a sister site to FlashDen that focuses on audio only called AudioJungle. To make things simpler the site is going to run the same HTML, with just stylesheets to make it look like a different site. A development like that throws up all sorts of new challenges to my file and folder structures, my stylesheets and my HTML. Here are some things to keep in mind:

  1. Organise yourself into a good folder structure
    Scripts, stylesheets, interface images, content images, and so on, all need to be kept separately. With a small site you might be able to just dump things together, but the bigger you get the more important it is to be able to find what you need.

  2. Use a coherent and intelligent naming system for your files
    There’s nothing worse than looking at a pile of images with names like "gd_l3.jpg". How you do it is largely a personal matter, but I find naming using common prefixes and descriptive file names helps a lot. So for example I might start every image going in the header with the word ‘header_’, every background with ‘bg_’ and then a menu background from the header would be called ‘header_bg_menu.jpg’. Prefixes have the advantage that when your files are sorted by name, they all appear together.

  3. Use Subversion
    This was forced on me by our developers, but thank goodness it was! Subversion tracks files and file changes and stops you from overwriting other designers/deveopers working on the same project. Also importantly it helps you roll back to old versions of things. It takes some getting used to, but even minus all the reasons developers use it, it’s worthwhile for HTML/CSS designers. Don’t know about Subversion? Check out Subversion for Designers

  4. Be thoughtful about how you write your HTML and CSS
    It’s really easy to make a mess with your HTML and CSS files, and it’s really hard to clean them back up. After four redesigns, I’m still using many of the same CSS files and it is a mission cleaning up classes that aren’t used any more or finding obscure definitions wrapped in lots of layers. Use lots of comments, possibly even multiple stylesheets, and make sure you name your styles well!

  5. Get Browser Compatibility working EARLY
    This is an area I went really wrong with FlashDen and we’ve been paying for it ever since. My initial layout worked in IE7 and I ignored IE6 until after we’d finished building the whole site. Ever since we’ve been adding IE conditionals, and hacks and workarounds. It’s much easier to make something compatible when there are only a few elements on the page than when you’ve built a massive site, so don’t follow my foolishness!

7. Make it Easy to Develop With Your Stylesheet

The bigger the site, the less likely a designer will get to see or modify every single page. If you’re a single designer on a big site – like me – then you also might not want to be called in for every thing. So it pays to make a stylesheet that can almost by default makes things look nice. For example:

  1. Make sure you style default elements like <input>, <strong>, and so on.
    That way the page will automatically present well. If you rely on people doing things like <strong class="my_bold"> then inevitably you’ll wind up with variance on pages.
  2. Create reusable elements that developers can use.
    For example on FlashDen we have a table class called "general_table", that makes a good fall-back style for data. When I have a chance to style a page I can do more specific types of tables and data highlighting, but at the very least a developer putting together a page has a good all-round table style to use.
  3. Make sure your page layout has a structure that looks nice even when it’s just got text in it.
    Inevitably there will be pages which you haven’t had a chance to add images to, and which may look a little boring. By using things like heading styles, sidebars, and so on, you can make sure that they still look pleasant and have some visual style. For example on FlashDen we wrap most text blocks in:

    <fieldset>
    <legend>Heading</legend>
    Content
    </fieldset>

    And this by default wraps the text up with a nice little border around it and a heading. It’s easy for a developer to work with and does a good job of separating text up and making it look more readable. We also have a sidebar component which is just another package for extra text content, but that again makes the page look more visual.

Naturally it’s optimal if every page does go through a designer, but it’s also much less stressful knowing that even if they don’t, it’ll still look professional and uniform.

What’s your opinion?

So those are my tips, if you have some of your own from working on bigger sites, leave a comment!

Note: Want to add some source code? Type <pre><code> before it and </code></pre> after it. Find out more
  • http://www.ben-griffiths.com Ben Griffiths

    Some great tips there – however I always get bogged down in the refine stage. I can never stop, and sometimes it’ll take much longer to complete. When refining, its definately good to know when to stop too ;)

  • http://www.simplyarun.com Arun

    Great pointers here. This will definitely be of help, now that I’m working on a large scale site.

  • http://www.tpnwebdesign.com TPN WEB DESIGN INC.

    FLASHDEN ROCKS…AND COLLIS YOUR A GENIUS

  • http://alexeckermann.com Alex Eckermann

    Another great Collis article :) Im a big fan of your work but the best is the FreelanceSwitch Podcast.

    Keep up the great work.

  • http://www.weborithm.com Hyder

    I’ve actually sold one file on FlashDen :-P

    I hardly do flash anymore, more into XHTML/CSS now and WordPress themes.

    From building dozens of sites myself I always cringe when I have to redo a few things on my older ones that weren’t designed from the inside so well. Some even used tables!! OMG, I’m so glad those days are over.

    @Ben – Yes, it is good to know when to stop. Design is an incomplete word.

  • http://webdesign.elipsoid.com elipsoid

    Great tip with the button styling! Thanks!
    I was surprised the logo on FlashDen doesn’t take you to the homepage. Otherwise nice and clean design.

  • http://qbrushes.com Qbrushes

    same here, use to play around with flash here and there but now its just photoshop/ some xhtml/css and wordpress.

  • http://inspirationup.com Joefrey Mahusay

    Yeah! Ive always visited Flashden since before. I like that site.

  • iamconnected

    I am still looking for a simple and helful and great text editor for coding on Mac.
    What do you suggest me ?

    • http://benjamincharity.com Benjamin

      I’m a hardcore fan of Espresso by MacRabbit. Coda is another good one. You can use them simply, but they also have built in FTP functions etc. Espresso even has code folding and project management.

  • http://www.ben-griffiths.com Ben Griffiths

    @iamconnected, try textmate: http://macromates.com/

  • http://www.andreipotorac.com Andrei Potorac

    Thanks for all the work you guys did. FlashDen is the best there is! :D

  • http://designerzweb.wordpress.com Hanush

    cool css button on fileden.

  • http://designerzweb.wordpress.com Hanush
  • http://www.ewoutwinkelman.com Ewout

    Seriously, this is a must read! Thanks for sharing your knowledge and tips with other developers!

  • http://www.3treestudios.com Nick

    This is a great list. You have great reminders and a great workflow.

  • http://www.wildapricot.com/blogs/newsblog/default.aspx rjleaman

    This post is a useful basis for a workflow / checklist for any size of site, I think – and a reminder that ‘design’ is a verb as well as (more than?) a noun… It’s always fascinating to be given a glimpse behind the scenes of a newly launched site. Thanks!

  • http://www.aesthetic-design.co.uk/aestheticList james

    this is perfect for a project that i’m working on – nettuts is potentially going to be the best tutorial site on the internet! i dont know of any other that firstly goes into such detail about useful things such as this instead of being just copy+paste code.

    great work!

  • http://www.timkadlec.com Tim Kadlec

    Nice list. I agree that getting browser compatibility taken care of early is a huge one. Trying to wade through pages of code and styles to find out what is causing your design to look different in IE6 is a pain. But if you are constantly checking it throughout the process, then you can pinpoint a section of code as being what caused the problem, and your troubleshooting becomes much easier.

  • Jen

    this is very relevant my current project (5,000 pages! yikes!) we haven’t had a major redesign in close to 5 years so i’ll be glad to get rid of all these tables!

  • http://www.swaymedia.com Ali

    Honestly, this is the type of tutorial Im always looking for but never seem to find on other sites.

    Request: You see how this was a tutorial about ‘Designing & Maintaing’ a big sites (HTML, CSS & Designing tips). Can you give us tips on ‘Creating and Developming’ big sites. (coding techniques, PHP file structures on general sites like Flashden.net, types of oop, mod re-write…) and standard development techniques big sites use. Like how did you create Flashden.net development wise, e.i is it better to keep as much code in a few files or little code in alot of files.

    sorry for the long comment, great work though Collis!

  • http://davidcarreira.com D. Carreira

    I LOVE THIS TUTORIALS!! Thanks! The web would be better if every web designer follow these tutorials :D

    David Carreira

  • http://www.triple-tri.com JPH

    Great advice — good things to keep in mind. Thanks for another great tutorial/article.

  • http://www.themusictank.com Francois Faubert

    It’s amazing how similar things are between different jobs. I would have suggested mostly the same steps but with putting even more emphasis on using reusable elements.

    I haven’t taken the time to populate my stylesheet with these on a new project with impossible deadlines where I work and programmers are accumulating bad design decisions and bloating the html just because they can’t easily have 2 columns or because so-and-so label isn’t the good color.

    Don’t make your programmers think! (Just like they don’t force you to understand the object inheritance and table relationships)

  • http://1955design.com/journal David Zemens

    Organization is the key, isn’t it?

    Thank you for once again reminding us of that fact. It’s far too easy to get moving on the project and forget about organizing things; we have all learned the hard way what a mistake that is!

  • Ariful Khan

    great article

  • stfalx

    Very nice tips indeed. Respect Collins! You’re 100% true. Not everybody applies the tips you’ve just listed. Although they’re still many more. Like perfect css generalization, that’s important too in future development. Some people forget to define focus styles and resizing (ugly stuff on safari) and lot’s more. Well good luck with everything Collins, you’ve got my respect.

  • http://www.ndezigns.com Nate

    Nice right up Collis, Thanks!

  • http://csd.varlew.net Panadero

    I can’t emphasize how much I agree with tip number five. I’ve been on a three-man team working with a couple very large clients for a couple years now, and all of them have had occasional ambiguities with regards to who was in charge when it came to additions and modifications. There have also been dozens of occasions where we’d just looked at each other and couldn’t fathom exactly why certain changes were requested, but most of the time we’ve just had to accept them given that they’re the client. I have a really hard time dealing with some of the requests I consider stupid, but as the author correctly pointed out, while there are times you have to put your foot down and refuse, most of the time your client takes precedence.

  • The Dude

    As for text editors for the Mac? Coda from panic.com. Use it in conjunction with CSS Edit and you are off to the races (+ it is only getting better). Last time I looked at TextMate it was a mess… but then again I still use Homesite.

  • http://www.phodana.de Phodana

    cool Tips and advice…

  • L2

    The picture that acompanies point 4 gets in IE7 out side of the box.

    Nice tutorial, although I don’t see the tip “don’t re-invent the wheel” (should I call it like that?). I personnaly learned how to structure my files from looking at how most open source CMS make there file structure.

    And love to see that flashdan uses Ruby, as far as I know it’s one of the nicest languages out there but so underrated.

  • http://nurseryschoolratings.com/ Marc

    these are excellent guidelines, i have seen large scale sites get soo out of control….

    keeping things simple and organized from the start is a MUST

    the slightest of changes or updates when having to applied to thousands of pages becomes a massive undertaking

  • Daniel

    very useful! thanks a lot for sharing these nice ressources !

  • http://eandjdesign.com Eric

    Great tutorial!

    I see you’re using Textmate for the screenshots – what is that SVN plugin that will allow you to commit from the drawer??? I would love to start using that plugin!

  • http://eden.cc Collis Ta’eed
    Author

    Thanks all for the feedback!

    Eric, I’m not sure, I’ll ask Ryan our developer as he set me up with everything. All i know is i press ctrl-shift-a in the drawer and get that little menu appear. When I was working on PC I used to use TortoiseSVN which was pretty neat and got me used to having a GUI. Anyhow i’ll see if I can find out!

  • http://www.goldenthunder.com Nico

    dugg! Great advice! Thanks Collis!

  • http://dotneil.com Neil

    Great post, Collis. I only wish you posted it when I first took an interest in making sites.

    I’m a fan of getting a grid set up in FireWorks (usually 8 x 120px) and then applying wireframes and objects to a page (and that’s after writing down the required functionality in a text document). I even add the grid to a #wrapper placeholder style (which would be the #container for NetTuts) and write the functional xhtml/css with a grid/wireframe as a base. Colour and styling are pretty much the last thing I add; I like to know I have everything functioning correctly first, otherwise I go crazy worrying about the possibility of chasing form over function. Admittedly I haven’t yet launched a site which completely adheres to this design approach – but there’s one in the works. And I was considering writing a similar post to this one if the site is well received – but now I don’t need to!

    Also, I was wondering why you would use a ‘general_table’ style – couldn’t you just style the table tag in the same way and drop the class?!

  • http://eden.cc Collis Ta’eed
    Author

    Hey Neil! I wondered if someone might ask about the general_table comment. The reason I didn’t style the default table is that now and again I need to use a table for something other than listing data – e.g. on our top sellers page we have a special table of thumbnails and sales numbers. So rather than have other table definitions undoing all the default class, it’s easier to just have a class of table.

  • http://www.psdnerd.com Harry

    Some Great tips and dugg it for you :)

  • Rodrigo

    Great article!
    I work for one of the biggest website in the US and I have to emphasize the “Be thoughtful about how you write your HTML and CSS” topic.
    It’s very important to have multiple CSS files and good markup. We are re-designing the whole website and we have more than 400 developers working on it, one of the biggest problems is the lack of consistency through out the website and we can identify 2 major points: bad HTML and bad CSS.
    Since not every developer cares about web standards we had to make sure to create guidelines and discipline POSH when writing HTML.
    Multiple css files have played one of the most important role for us, since our site gives the user a chance to change the look and feel on personal pages, we structured our CSS files like:
    “base.css” (common layout position),
    “typography.css”
    “skin.css” (color and images)
    That gives us the ability to add a new “skin.css” every time we add new website skins and take us less than 3 days to QA and implement it comparing to 2 weeks when we had just one file for all our styles.

  • Jim Darwin

    Thanks for the tutorial. I am just a newbie, and trying to figure out how to do the best site, and best first niche.

  • http://www.digitalskraps.com David Sparks

    @ 6.5

    Couldn’t agree more here.

    Once my xhtml is done and i start working on the CSS, I work from the top down and check in FF, IE7 & 6 non stop as I go.

    I find thats the best way to keep things from breaking.

    top down browser to browser.

    dont start working on your footer if you still havent finalized your navigation thats up in the header. you never know what you’ll have to change that wills screw something up

  • http://www.spannaintheworks.com Anna Bramble

    Awesome post. I think this is my first time commenting here or at PSDTUTS. I have been a lurker for quite some time but I just had to say good job on this tut, Collis. Really great advice! This gets me excited about the great things that I’m sure are around the corner for NETTUTS.

    I agree with Ali up there that it would be great to see some more detail on how you developed/coded the site. :)

    I love the button class tip – how does it work exactly? Do you have it as display: block; with a horizontally repeating background image? If so, and it can be at any length, how does it have edges/borders on the sides?

    I should really know this stuff, being a web developer. :P I think I have a lot to learn from this site, seeing I have never used a frameset tag or a legend tag.

  • http://jamielesouef.com Jamie Souef

    Some great tips here, but i agree with Ben Griffiths, sometimes the refinement can become the thing that bogs a big project down.. i’m still trying to figure out when to stop :P

  • http://www.aminurrahman.com Aminur RAHMAN

    very good structure of advice. cheers

  • http://www.drupalmuseum.com Eric Orr

    Great post. Thanks!

  • http://markprovan.co.uk Mark Provan

    Thanks, just what I was looking for.

  • http://www.spectechstudios.com Joel Then

    NETTUTS should do an in-depth Ruby on Rails tutorial….

  • http://imgtags.com/ .11

    I am curious, I wanna know how many members flashden had before it was posted on nettuts and psdtuts D:

  • http://yeahnah.org Ryan Allen

    @Ali: The honest answer is nobody really has a single reliable way of developing software, so what people do is often what works with a given group of people. Though there is some agreement what constitutes ‘best practices’ in software development, and one of these is writing an automated suite of tests for your application. And by that, I mean a program that tests things in your application automatically, so you don’t have to. Pick up “Test Driven Development – By Example” by Kent Beck, it’s a classic. As for how to put your applications together, I’d recommend learning a bunch of different frameworks (i.e. CakePHP, Ruby on Rails, Django) to get an understanding of how other people put their applications together, and by the time you’ve worked with a few frameworks you’ll have developed (and borrowed) some ideas of your own. I had the same issue with PHP that I wasn’t quite sure where to put things, as nothing was enforced, to working with Ruby on Rails (which is very specific about where you put things). I’m biased, but I’ll say try out Ruby on Rails. FlashDen is a Rails app.

    @Eric: The subversion plugin comes with TextMate by default. Hit Control-Escape and you’ll find the commands under subversion. Though I’d highly recommend getting comfortable with it in Terminal if you’re using it a lot, because then you can use it with any program!