Wow that’s a mouthful of a title. I want to outline my WordPress development process when I’m doing client work. I see some freelancers doing odd stuff sometimes that makes me really scratch my head. Like doing dev on a client server or editing locally but uploading every change or new file.
That’s just crazy but whatever floats your boat.
Some notes before we get started: This process has been meal pieced together from working with or seeing what other developers do. I have my own unique way of doing certain things but most of this may look pretty normal. I’ll talk about UI Design, UX, User Testing, and any other phases in another perhaps more thorough post. This is more of just an overview for phases, approvals, or whatever you might consider a milestone.
Let’s assume we are doing a PSD to WordPress theme… contract is signed, deposit received, final PSDs in hand.
You can’t be anymore ready than right now, because you should have already done an overview of any technical requirements for markup or special WordPress functionality while you were quoting… right? ;)
Step 1: Setup Your Environment
A. The first thing I do is get all my files ready. My working directory looks something like this:
- /ui-assets/ (PSDs, wireframes, any stock, etc)
- /static/ (this contains my Front-End Starter)
- /WordPress/ (wp-content and DB… eventually)
- /docs/ (contract, quote, build notes, training docs, etc)
B. Create any local environments, github repos, etc.
C. Setup the client staging site on my server. Clients get a subdomain (projectname.mydevbox.com) that is protected by htaccess/htpasswd.
Step 2: Screencast & Final PSD Approval
Get those PSDs open and hit record in ScreenFlow! Walk through the layouts header to footer talking about how you’ll handle each element, especially if there are some tricky spots or you expect some kind of css or jquery animation to take place. Pull up an example to confirm thats what they want.
No responsive views? No problem. You can always put together some real basic wireframes with a site like Wireframe.cc and send those over with your screencast.
Talking through how you’ll build something also usually prompts questions you didn’t think of.
Pro tip: Don’t be a slouch. Use a legit mic like a Yeti and upload to Vimeo in HD.
Step 3: Markup
Here is where I might separate myself from some of the pack because I don’t use a starter or base theme. Custom design gets custom development.. but to each their own.
Load up your blank slate and get slicing. Once you’re done all your HTML/CSS upload it to projectname.myprivatedevbox.com/static/ and send it over to your client for any revisions.
This is the last stop to make any large changes to markup. Make sure they know that and once its #donedone you might even send an approval doc to be signed saying everything is kosher.
At this point I will zip the static pieces and send those over as a deliverable if requested. Most of my projects are 50% payments, so In my opinion we just hit the half way mark and you get a fancy zip file for your money.
Step 4: WordPress
Time to start building our WordPress theme. In my opinion there is no best way to build or organize a theme. It really depends on the project and its requirements.
There are a few different schools of thought on this so you may want to see these posts, but more than likely you already have a preferred way you do things.
- Andy Stratton Interview (Code Poet)
- Functions.php vs Plugin (Tom McFarlin)
- Creating a Site-Specific Snippets Plugin (Otto, man!)
- Functionality: Plugins vs Themes (Pippin Williamson)
At this point we might get into paid plugins or tools. If its used specifically for this client and not your developer license than they need to buy it. I don’t want your license being in my name. Occasionally I will bill clients for plugins and do the purchase for them but I prefer not to. The client should own everything they pay for.
Pro tip: Load up WordPress specific sample content showing all the design elements like headings, block quotes, img floats, captions, etc. and make sure they are styled to match!
Step 5: More Screencasts or Docs
As your client is going over the WordPress theme (issue them a user on the staging server install, duh) it’s time to start thinking about any custom functionality you built. If you didn’t I recommend WP101 for training if they need it.
But lets assume you’re just doing overflow for an agency. I hate writing docs but sometimes its a requirement. When it’s not though I prefer to still walk the client through how to use any of that custom stuff with a screencast.
Step 6: Final Deliverables
Send over a final sign-off document for the theme along with that final invoice. :)
Once I get final payment I send them the final deliverables:
- Zip of working directory
- Zip snapshot of staging
This was rough and slapped together. I promise its a bit more refined than this but ultimately you need to find what works for you. My finite details aren’t going to work for you. Any little pieces or steps I didn’t include in this are too specific. Just like theme building or the way you write html/css (if you even do?) there is no “right way” to do anything, only suggestions of what’s working for someone else.
Different clients also get different processes or milestones. Some clients are super hands off, so they don’t get the approval doc treatment or maybe they get github access from the kickoff.
Feel free to voice any suggestions, praise, or hate below.