I've used a variety of processes but the ones I enjoy the most get right to the point and try to keep as much noise out as possible. I like to follow something like this:

• Initial conversation around goals (This could be an hour long hangout session or a physical meeting if all of your stake holders are all in one place. What this also allows is for everyone to get on the same page before you start having mini conversations that go nowhere inside something like a google doc. This initial conversation should be driven by one person, you! Most of the time you'll have a basic understanding of the goals for the site previous to this meeting.)

• Create a goals doc (This is a basic high level understanding of your goals. Big picture stuff, eg. Make the site easier to read by having a cleaner design, etc.)

• Create a requirements doc (This is a granular list of requirements for the site. I like to split this up into pages/sections/features/tech . So you'd have a page like: Blog. Inside blog you'd have sections that require headers, authors, tags, images, videos, etc. Inside those sections you have features like, "allow readers to make comments inline like medium does". Then you'd have tech, like; we'll do this using this tool.)

• Sitemap (The sitemap is a simply visualization of all the pages required for the site. You'll use the requirements doc to define this sitemap)

• Content Definition (The last step before building and designing is to get an understanding of the content that will be on the site. Most of the content is going to be driven by both the requirements doc and the high level goals. It's also important to map your content to your sitemap. I like to visually do this in something like sketch.)

• Prototype (The prototype phase is fairly broad. This could include building out little proofs of concept, like the inline commenting feature from above. The prototyping phase also includes coming up with the visual design for the site. Most of the time, at least on small teams, I like to skip right past the static mockup phase and just start building right in the browser)

• Integration and building (This is phase where you actually build the site and integrate the design. I like to keep the prototype phase as close to production ready code/markup as possible so this phase runs fairly quickly)

• Styleguide (Building the styleguide is a continual process. Because things are changing so much in the previous phases the styleguide is constantly being updated. I don't like to retroactively build the styleguide, rather I retroactively finish the styleguide)

Beyond that there's also a smaller process for deployment. Depending on the experience of your designers you may or may not handle that. At Catalyze everyone is an engineer so it helps to be able to spin up a node server and launch a test environment without bothering devops.

What's with the title of this post in Panda (Chrome)? Never seen this before.

While I've never personally had the opportunity to work on a large-scale site, Brad Frost's process for the Greater Pittsburgh Community Food Bank site is exceptionally well done. Take a look here (it starts at the bottom of the page): http://foodbank.bradfrostweb.com/timeline/

The sections you have are pretty much what there is but the devil is in the details.

For the goal definition, consider doing stakeholder interviews across the organization and hosting collaborative discussions to get everyone on the same page from the get go. This is important because later on in projects stakeholders can swoop in and complain about their pet ideas/goals/projects not being addressed–having an original agreed upon set of goals helps shut that stuff down.

The next big step is to perform a content audit. Don't skip this. Make sure you're tracking URLs of existing content so that you can setup 301 redirects if things move around, people forget this kind of thing.

Otherwise, everything else is pretty much what you would think.