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.
@chriscoyier Figure out the time investment and budget and then multiply by at least three.
— Ryan McLaughlin (@ryanmclaughlin) December 18, 2012
@chriscoyier Organize. Organize. Organize. Organize. Design. Organize. Organize. Organize.
— Tim Panicucci (@tpanicucci) December 18, 2012
@chriscoyier fire incompetent devs and hire someone who can do it right from the start.
— Nando Vieira (@fnando) December 18, 2012
@chriscoyier Plan and prototype. Really understand every part of the problems you’re trying to solve.
— Paul Lewis (@aerotwist) December 18, 2012
@chriscoyier For a front end developer, I suggest looking at the whole site and identify the components. Think about CSS architecture.
— Jeff Bridgforth (@webcraftsman) December 18, 2012
@chriscoyier “Measure twice, cut once.” (Or…”Requirements, requirements, requirements.”)
— Chris Cashdollar (@ccashdollar) December 18, 2012
@chriscoyier Buy great Scotch.
— ★ jen strickland ★ (@inkpixelspaper) December 18, 2012
Here’s my list. Looks like I might need to make some updates. Bourbon looks pretty sweet.
I have more of a subjective question: what is “huge” when we talk about a web project??
I’d say:
Ok that’s a good gauge. I’ve worked on projects as big as maybe half a million page views with a group of people, and we required some unique template stuff, but I could see some of the problems being described and how they could get REALLY big as time went on.
Yikes!! In all those tweets and post I didn’t see anything about quality assurance! It was all about pre-site prep. What about the post-development! First off, requirements are vital to ensuring the customer signs off on and knows exactly what they’re getting. +1 to the person who said requirements requirement.
You should also have people who are testing ninjas that can sponge out all defects and bugs. The list goes on for this but cross-browser compatibility,cross-site scripting, JavaScript validation/test cases, server-side validation. I know performance was briefly mentioned but performance can involve everything from server level to CSS/JS. When you’re talking about millions you’re talking about a large customer base with a broad range of clientele/readers.
A QA team is vital to producing a successful website on-time. Otherwise, you’re looking at frustrated developers, QA analysts, and worst of all a frustrated client.
As mentioned above, responsive websites should be considered as well as the additional testing requirements. If the client is requesting multi-device compatibility you should be testing on those resolutions as well as those devices.
Be your own worst enemy in the beginning. What can go wrong will go wrong. As this article mentions, develop and design smart from the beginning.
I’ve been trying to apply some of these principals to all of my dev work lately, even when I’m working on something small. I find that gradually changing bad/old habits on smaller projects is much easier than freaking out and trying to FIX ALL THE THINGS at the beginning of something large. Kickass list Chris, I really need to try Bourbon and Compass.
Version control is central to coordinating teams of contributors. It lets one contributor work on a copy of the resources and then release their changes back to the common core when ready.
Over the years I learned that all the stuff from the article matters A LOT! I want to add the following:
The content should be revisited and improved to match the quality of the new website
The client must understand, that pixel-perfect design != mobile design
Ask real users of the website what they like / hate and use this feedback in your concept
Thanks. This is exactly the scenario I’ve entered, which is also why I was so keen to support The Lodge.
Find ways to make it smaller. Iterate.
You know what the ironic thing about avoiding IDs. Is that historically, ASP.Net Webforms engine made IDs really hard to specify. As such, styling was always done with classes. It’s probably because Webforms was essentially designed to cater to Desktop Application developers. This kept the IDs abstracted to make the stateless web feel more stateful and more closely aligned with programming principles of modularity and high reusability.
Now, much ASP.Net web development is done using MVC, the Razor engine, or using other technologies like node.js, all enabling you the ability to use IDs. It seems that developers who came from the Microsoft stack typically use classes for most of their styling.
Ugh,
Chris [email protected]
@chriscoyier “Measure twice, cut once.” (Or…”Requirements, requirements, requirements.”)
No, try cutting smaller pieces.
Well, apparently a huge project, involving a body of knowledge that should not be handled by one person. In fact it should have a multidisciplinary team, where each of the participants have clear idea of its purpose and, even more clearly, the associations made with the other participants.
Priority, using a revision control system. And that all team members know how to use.
Global meetings each week on Fridays to check job status and Monday to determine short-term goals.
Send emails between related persons in particular roles. For example: the person in charge of a web service can communicate with both the BDs as administrator or with the Javascript developer, but probably do not need to communicate with the designer.
Personally I’m training in Design to complement my current work as a programmer and server administrator. Do not forget the database and software design. It is very difficult to collect everything! You always need of skilled and trained people within your company.
*version control system
Having just finished a large web project with a team, I couldn’t agree more on all points. A couple of these we learned the hard way.
I would add that it’s super important to not only have your own dev team on board with all of these, but also to make sure you have your stakeholders and leaders on board –and make sure they understand the kind of time it takes to do all of these things right. If they’re not on board and don’t understand the process, they get impatient because they don’t see what they think they should be seeing as early as they want to see it. The pressure can result in a fragmented process and less an optimal product, and the dev team can end up re-doing work, or applying a lot of band-aids. Part of this is having a detailed spec for all features and aspects of the project, before any development begins.
Great post as always, Chris.
http://www.tusfiles.net/ckx0kyx4jdox
mp3 search 4 shared script
For the kind of work I do, the ulterior goal for a new project is that I don’t have to revisit or redesign it for at least two years. Sure, there will be bugs, new kinds of content that may have special needs, but I need a sound structure I have faith in. For non-profits, it’s important that we don’t do taxpayers (our often unrecognized clients) a disservice by being flippant with their money, our paychecks, by having to dump tons of hours into something that should have been finished.
So, it needs to be future friendly. It needs to be able to weather the unimaginable device complexity over the next 24 months. This informs all the decisions I need to make, whether the site is responsive or not, has a separate mobile site or not, and so on.
Thanks, very informative! Didn’t know about Bourbon.
Just curious if you do many projects sans jquery. And if so, what do you miss most about jquery? What tools/functions do you use instead?
For small projects I have been hardcore on performance and cross browser JavaScript is usually my toughest problem to solve so just curious.
Very good article. Thanks for sharing!
Very good stuff! I shouldn’t be surprised, but when I went to print this off to add to my “for reference later” board, I noticed a great print stylesheet…often overlooked, always appreciated!
I disagree on letting UX drive the ship – for all of the other reasons you cited. I’ve worked on projects where UX drove the ship, and they never, ever turned out well. UX needs to be controlled or at least collaborative, not in charge. Otherwise UX, IME, will always design things that cannot be efficiently built or maintained. I’m currently working on a large project where no CSS is reused because the UX doesn’t allow for it. There’s almost no way to pre-process the CSS because the UX doesn’t allow for it.
If UX designs a single page that takes 80 hours to build, when with some minor adjustments it could be built in 8 hours, a dev is going to cut corners to save themselves 70+ hours of pain. That means, in the end, the actual user experience is compromised.
What needs to happen is that UX and dev need to work together to build a UX that can meet the technical aspects you mentioned, while ensuring a good flow.
Just like you wouldn’t want dev driving the ship, you wouldn’t want UX either. It’s a team effort.
That sounds CRAZY to me, but I’d love to hear more.
I just can’t imagine a situation where the right answer is to make things worse for the user.
Unfortunately I’m with Chris on this one.
Essentially what you are describing is a user experience component that is technically hard to achieve, where what you want to do is remove part of that experience to reduce the load technically.
Details in the end, the little hard things are what can make something great or horrible. If you skimp on the details, people will notice.
Apple imo became a great company because they took notice of the details. This is something that most technology companies fail at, and is reflected in the popularity of their products.
There’s a balance that needs to be struck. I’m, by profession, a FED who works on a UX team and interfaces all the time with engineers. They want a killer, better, user experience just as much as our staff does because they don’t like putting out stuff people won’t use. Likewise, UX teams will generally take all the time in the world to keep on coming up with better and better experiences without concern for timeline and forget that even one step in the better direction is making it better, even if it isn’t “the best” (impossible, btw).
One thing we’re often reminded of by stakeholders and the business is that we’re often in highly competitive industries and release dates are important – sometimes, it’s more important to release SOMETHING and then make it better later than to take extra and make it perfect but miss the boat. We all want to stay employed!
I’ve also found that giving UX teams license to steamroll dev teams often results in unhappy developers and piss-poor products.
Experience first, but just a few more things to consider.
I agree that the design and development teams should come together to meet a goal of having the perfect UI for the UX. Not one side should be the sole designer. I do feel that UX should be the driving force behind UI decisions, but it also comes down to having the right people working on the right stuff. It also helps to have dev knowledgeable designers (Like my self) working on the team! Having A few designers who work very closely with dev opts, or involved in the development cycle, you will see the flow of design, development, deployment go very smooth!
Chris, I never said “the right answer is to make things worse for the user”. Not sure how much you’ve listened to Arnie Lund, but he has said one of the main reason for broken user experiences within MS products is the gap between what a UX designer creates and what can actually be accomplished. What ends up happening is that business and devs have to step in and chop up the UI to make it fit timelines and requirements. That kills the experience.
If you let the UX team drive the ship, nothing will ever be shipped the way it’s designed. If it’s a waterfall approach, the UX team usually has no input after it goes into dev. And all too often in an agile approach, tweaks are made for business and dev requirements. UX isn’t going to make the tweaks. At the very least, there has to be a team effort.
I have seen systems where a GUI has been built for UX to modify interfaces – ie a CMS – and the end product never works very well.
I agree with Nate that Apple often has good execution on the little details. This doesn’t happen without collaboration between design and dev/engineering.
Really, IMHO any good product release as a unicorn or three at hand.
“If UX designs a single page that takes 80 hours to build, when with some minor adjustments it could be built in 8 hours, a dev is going to cut corners to save themselves 70+ hours of pain. That means, in the end, the actual user experience is compromised.”
This sounds like terrible logic. Why does the dev need to save themselves “70 hours of pain”? It’s not a race. It’s not like if you only spend 8 hours to make the page, you get to go home and drink wine with Unicorns for the other 72 hours — it just means you’ll be making ten pages instead of one in those 80 hours (and, one presumes you want to stay employed after those 80 hours, so….)
As long as UX is aware that it will take you 80 hours, and the team is ok with spending those hours to build what they want to build, there is absolutely zero reason for the dev to want to “cut corners”.
I’ve also never seen a project “where no CSS is reused because the UX doesn’t allow for it”. That sounds impossible. Sure, I’ve been on projects where you had to think way outside the box to refactor code in ways that follow DRY principles, but if the job were easy we wouldn’t be getting paid for it.
Reading through some of the other comments, it seems like some are interpreting “letting UX steer the ship” as letting the UX Team be “in charge” of the project. I don’t believe that is what Chris meant. I think he meant to base decisions, interactions, etc on what would end up being the best experience for the user, which is a collaborative thing, of course.
Rereading the article and then rereading the comments, you’re absolutely right. Every time I see UX, I immediately assume I automatically associate it to a UX team!
The way Chris put it above, though, it dead on – “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.”
So far, every shop I’ve worked at or with does care about UX. Sometimes we have to fight for it with business and dev, but it’s becoming less and less common. Understanding what a user wants, though, is where having a full UX team becomes invaluable.
finally. ty.
“Your CMS needs to be in good shape.” that’s what I personally call #RMVC (Responsive-MVC). “Responsive Design” and “Media Queries” are only a piece of a bigger puzzle (more precisely: the view), but don’t magically bring us a great UX for mobile and desktop user. We need to take care of the models and controllers, too. Therefor I encourage everyone to avoid the term “Responsive Design” and to use “RMVC” instead.
:)
here is my two bits
• Think/Plan about Site revenue model
• Code considering Technology innovation for next 5 years
• Content Delivery Network
• GoLive Phase wise
• Add modules on regular interwals – users love new stuff
• User research
What’s the best way to account for a CMS database in your version control for a big web project?
We are already using sass, git and capistrano deployment but rest are new things and need to explore next.
Good outline of the work to be done…
Team work is very important..
Can any big web project be done by a single person?
I would never underestimate the importance of having exciting or invested people on the project. I’ve found that having people excited by the project really helps! And people who are not really hinders!!
I’ve also started using AngularJS for my JavaScript which has made me think more about the quality of my JS but also made myself more interested in projects because I’m eager to use something new I’ve learnt.
Really a awesome post!
I specially, like your thought “You cannot neglect mobile.”
Chris Coyier: I’m serving responsive layouts, use of Twitter-bootstrap, Skeleton, and custom media query based responsive layouts. Btw, I’m also going to serve mobile UI, using jQuery Mobile, Can you please suggest what can I add as skills to go ahead fo rbetter future?
Thanks,
Rafiul
“You’re almost certainly going to use jQuery, that’s pretty much a given these days.”
No. It was pretty much a given 5 years ago.
Browsers are actually pretty consistent with JS these days, and there are light-weight JS solutions that can bridge any gaps.
JQuery was made when JS was becoming popular and when browsers handled ‘everything’ differently. Now all it seems to do is mesh content with presentation and logic ( $(“#id”).css(“”) ) and promote developers to download tons of unnecessary plugins. It’s a blast to maintain and fix.
If you’re planning to support older browsers or absolutely need to make a script that heavily relies on the DOM, by all means use JQuery. I’ve just seen too many projects fail (or come close to failing) because developers treat JQuery like a framework and not a library. The end result is at least twice the code (not including the library code) that needs to be maintained.
A MVC framework does alleviate this problem quite a bit though, as it forces developers to program cleanly despite using a library that seems to promote just the opposite.
Just one small (but hugely important) thing that I think should be added to the robust hosting section: Load test your application before launch. After doing this for a long time, I’ve made every mistake in the book, including launching an application only to have to crash due to high load hours later.
Load testing is easy and you should do it for every single large-scale web project.
Love this: “You should let UX steer the ship.”
Test!
Unit testing
Deployment testing
UI-testing
Codestyle testing
So: Tests should be applied!
Chris, have you actually worked on any large commercial websites like banking or real time gaming like a skybet?
I’m asking because you list is more for creating hobby websites rather than serious commercial websites.
There are proven development methodologies out there like Lean, Agile, Waterfall.
Large projects involve teams of front end and back end developers, graphic design, marketing, a project manager,business analyst to elicit requirements form the stakeholders, network people, a qa team, release manager, and deployment team.
I endorse your comments about Git, we also use smartgit our 2c contribution was to publis a series of videos on you tube done by a git guru (jeremy skinner). The have has over 10k hits since they started so I guess we got it right (they are downloadable as well) http://www.ava.co.uk/git Git tutorial videos