Have you ever wondered exactly what your developer is doing after you hand a site design over to her?
Unless you’re a super-seasoned web professional—and even if you are!—the web development process can be a bit…mysterious.
Today, I want to help clear up some of the secrecy surrounding the web development process. I’m going to peel back the curtain a little and explain my “standard” WordPress web development process for you in-depth.
After reading this post, the next time your developer takes the baton from you to begin her part of your web project, you might not feel so “in the dark.”
Step #1: Prep work
Okay, okay: the REAL step #1 is sending out a proposal and project negotiation, but you’re probably already familiar with that part of the process, so we’ll skip it for now. 😉
The prep work phase involves a lot of information-gathering.
I reach out to the client before the project begins to let them know when I need the site mockups and/or style guide. I also ask for copies of all images and graphic elements that I’ll need to replicate the mockups saved in the appropriate file type. And, if there’s an existing site that has content to integrate into the new site, I get access to it so that I can duplicate it on my server.
Before development officially begins, I create a tracking board in Asana that covers all the important milestones of the project and invite my client to it. Then, she can easily see when she needs to deliver each item and when she can expect to see a completed demo site.
She can also follow my progress, since I check things off the project to-do list as I finish them. I find that this helps alleviate some of the nerves associated with working with a new client, since they can see that I’m actually working on their site and moving toward demo site delivery.
Step #2: Site setup
Once the project actually begins, I set up my local development environment. I work locally because it helps move development along faster and I don’t have to worry about anyone stumbling across the partially completed site on the internet.
For WordPress sites, I prefer to use Local by Flywheel to set them up: it’s quick and painless, and works just fine even though I don’t actually use Flywheel’s hosting (I’m team WPEngine). If needed, I upload the existing site’s database and files into Local as well.
Next, I’ll create a folder for the new theme I’ll be developing and install any necessary parent theme, such as Genesis. I then set up my new theme structure to work with gulp, a task runner that automatically performs steps in my build process, and make an initial commit to my GitHub account to test git integration.
I like to back up each site I develop to git in case of a computer failure or natural disaster! Also, I love git’s version control to make sure I don’t lose anything.
The final step in my local site set-up process is adding pages to the navigation menu(s).
Step #3: Basic site structure
The first bit of real development I do is creating the basic structure of the site. The site structure consists of universal site elements—like the header, navigation, and footer—that appear site-wide or on many of the site pages.
Like everything else in my development process, I work on the site structure in a mobile-first fashion. So, I build and style the mobile header, navigation, and footer BEFORE I start working on the desktop version. (For an overview of the benefits of mobile-first, I highly recommend Mobile First by Luke Wroblewski – it’s an oldie-but-goodie!)
Step #4: Individual pages
After the basic site structure is complete, I start developing the site’s individual pages. I’ll develop every page except the homepage during this phase, again following a mobile-first pattern.
Step #5: Blog
After the individual pages are complete, I work on developing and styling the site’s blog (if one is included). I begin by styling the blog index and archives, then move on to work on the single post layout.
Step #6: Home page
Finally, I wrap up development by building and styling the homepage. Many developers start with the homepage since it’s the site’s entry point, but I leave it until the end of the project.
It’s simple: often, the homepage design includes elements from other parts of the site, like blog post excerpts or short bits of content from the other pages. If I’ve already created and styled those elements, it’s a lot faster and easier to drop them into the homepage.
Step #7: Upload to demo server
After development of the full site demo is complete, I upload the site from my local server to a demo server on the web so that the client can preview and use it. I normally host my demo sites on a transferable install in my WPEngine account so that I have full control of hosting, but can simply hand over control to a client when the site’s finished if they want to use WPEngine as well.
The sites are password-protected, so only project stakeholders with the login information can view the demo site. And, the demo site is fully functional, so clients can log in and update content or otherwise make changes to it.
Step #8: Revisions
Once clients have had around a week to review the demo site, revisions begin. For a standard project, clients get a choice between either one week of unlimited revisions (as many rounds as desired!) or three rounds of revisions spread over no more than two weeks’ time.
Clients send me revision requests via Asana, we discuss if needed, and then I perform the revisions and upload them to the demo site for testing.
Step #9: Cross-browser testing
After revisions are done and the final site has been approved, I—or one of my trusted junior developers—perform cross-browser testing (CBT for short) on the finished site. I make sure the site looks and acts as it should across the most popular browsers in OS X, Windows, iOS, and Android. If any bugs are found during CBT, they’re fixed before launch.
Step #10: Launch!
The most exciting part has finally arrived: site launch! I either transfer billing to the client (which converts the transferable install on my WPEngine account to a full install on their account) or upload the site to the server where it will “live” indefinitely.
This is usually the last step of most of my development projects, but some clients prefer to keep me around on retainer to deal with any issues that may arise or to add new content to the site. Even if we don’t have a maintenance agreement in place, I fix bugs on the completed site (as long as they’re not caused by updates) for a year after launch.
Though it sounds long and complicated, the development process moves along fairly quickly: the entire thing from start to finish is usually completed in six weeks.
Do you feel more enlightened about what goes on behind-the-scenes when you turn a project over to your developer now? ?