So You’re Going To Start A Huge New Web Project

Avatar of Chris Coyier
Chris Coyier on

I was asked this past week to consult for a company embarking on a huge new website redesign. I thought I’d write up some thoughts that I would share with anyone in that position.

You cannot neglect mobile.

Look at any graph of mobile usage and it will tell the tale for you. Millions of mobile devices enter the world every day. Ignore this to your own demise.

You’ll need to decide if you are going to build a mobile-specific site or not.

Mobile is a whole different world. There is literally less room on their smaller screens. They often have lower bandwidth. They often have user input that desktops doesn’t have (think: swipe, pinch, or shake) and vice versa (think: mouse cursor, right-click, or modifier keys).

Can you handle all of that in a single site? Maybe you can. Responsive design can help with this and is an awesome solution for a lot of sites. But don’t force it at the determent to both desktop and mobile experiences. You might have to split into two – which ensure speedier and easier-to-dev sites. But now there are two sites to keep in sync which comes with its own struggles.

Your CMS needs to be in good shape.

You should be able to ask your CMS for anything you want and get it. I need a full size image of that product – here you go. Now I need thumbnails of related products – here you go. I want the title, subtitle, and intro paragraph of that article – here you go. I want a bunch of content inside of this template – here you go – now the same in a different template – here you go. I want to request some content via Ajax and get just the content back, no markup – here you go. At the outset of a project is a perfect opportunity to build/choose/customize a CMS that works for you.

Need a guide? Try the book Content Strategy for Mobile by Karen McGrane.

Karen says in her talks there are companies that will go out of business because they are so bogged down by their CMS and can’t accomodate mobile and the future of content delivery. I’m sure she is not wrong.

You need a plan for your CSS.

You have options for just about every other technology you choose for a project, but you always need to use CSS. CSS is simultaneously very easy and incredibly difficult (day to learn, lifetime to master). On a large project, you really need to develop a design system. That means re-usable parts and design patterns that help you build quickly and keep you consistant.

Need a guide? Try SMACSS. As a tiny part of this, I’d say avoid ID’s.

Code clean.

Everyone is happier when the code we interact with is clean and consistant. Even if it doesn’t match your own style perfectly, consistency is the most important thing. Establish a style guide. Here’s some to peruse.

You should be preprocessing your CSS.

Design systems are a lot easier to build (and CSS is generally a lot easier to write) when using a preprocessor like Sass. You can set variables for colors to keep those consistant. You get CSS3 mixins for free with Compass or Bourbon. You can break up patterns into individual files to keep sane and organized. You can compress your CSS as you author so essentially performance is part of your workflow (small concatenated files = fast).

You’ll need to think about JavaScript architecture.

You’re almost certainly going to use jQuery, that’s pretty much a given these days. Almost certainly you’ll be needing to do some DOM manipulation stuff and Ajax and that’s what jQuery slays at. But jQuery doesn’t help you architect a site. As in, what pages need what JavaScript? What belongs in a global JS file and what belongs in page-specific JS files? How do you manage those dependancies? How are you going to write that JavaScript so it isn’t a noodle-y mess of global variables and functions and organize it into logical chunks.

Maybe Backbone.js can help. Maybe Require.js (or the like) can help. If you’re using Ruby on Rails maybe the asset pipeline can help. Maybe just the ability of CodeKit to append/prepend and concatenate JavaScript can help.

Need a guide? Rebecca Murphey writes about this kind of thing.

You’ll need to think about version control.

Team development requires version control. Git is a solid choice. I’m no version control master, but the popularity of it and resources to be found about it speak for themselves. Branching and merging is fairly easy.

Have a pristine master branch that nobody works from. Then a staging branch. Then individual “feature” branches. You can “merge up” from staging anytime into a feature branch to keep in sync. Then “merge down” features into stage when they are ready. Staging is what you test and where all features come together. Then when ready, that goes to master.

Beyond the obvious advantages of keeping code in sync and tracking changes, it gives the whole team the ability to see what everyone else is working on by looking at commits. This helps team accountability.

You’ll need to think about staging and deployment.

That staging branch I mentioned above? That would be good to have auto-deploy (deploy = move files to a live server) to a testing server. Ideally this testing server is as identical to your live server as you can make it. Do your testing there. Then when it’s good, move staging to “production” (you’re live server that your user’s actually use).

Deployment itself is an entire big topic. Likely you are caching assets, so you’ll need to break that cache on assets that change and not break it on assets that don’t.

The web app Beanstalk does git repository hosting and deployment. Capistrano is a project for building your own deployment.

You’ll need to think about robust hosting.

Can you upgrade your servers on the fly? How do they handle heavy load? Are you load balancing? How is the customer support at your hosting provider? Will they respond 24-7? What are the costs? Are they substantial enough to bring hosting in-house?

Do they monitor your server performance or is that up to you? Your host probably has tools for monitoring server performance. New Relic is an app that can help with that.

Most big websites have someone (or a team) just for handling servers. It’s a unique skillset, different from development.

You should let UX steer the ship.

Every decision you make should be about making things better for the people who use the site. Try to never make a decision based on technical difficulty. That might mean you specifically have UX people. Even better, everyone on your team understands and cares about UX and makes it a priority. This isn’t just a design thing, it’s everything.

Think about performance from the start.

Performance is often this thing web teams do “later on.” You have a good opportunity here to make smart decisions about performance from the beginning. Load as few assets as you can. Compress them as much as you can. Cache as much as you can both on server and client. Make sure your server guy is on top of things like response time.

Need a guide? Steve Souders’ books and blog are fantastic.

Make sure your team is excited.

Building a big website is huge and all-encompassing endeavor. It’s hard to do at all and much harder to do well. You need a team with a fairly wide array of proficiencies and likely someone steering the ship who’s proficiency is ship-steering. It takes time and patience. It takes money. Beyond all that, you all need to be excited about it. You won’t make good decisions if you aren’t excited about what you are building. Struggles are harder to overcome if you aren’t excited to get past them.

From Twitter

I asked on Twitter: “What kind of advice would you give someone about to start a huge new web project?” I got back some good stuff.