Where the design community meets.
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.
Style guide is so important and building a big UI kit to back this up will make life a lot easier.
From a design perspective you should always consider best and worst case scenarios of content; in the wrong hands, CMS stands for content manglement system and before you know it your beautifully crafted layouts are destroyed (content guides also help with this problem)
Where the design community meets.
Designer News is a large, global community of people working or interested in design and technology.