An Overview of a Typical WordPress Design and Development Process
January 30, 2013 — Writings
The web design and development industry is one that is booming in these recent years. There’s a plethora of focuses that one can hone their skills in and philosophies and patterns are a dime a dozen and can be as different as day and dark. For those that are just starting out or want to get some insight in how some designers do things, I wanted to share how a typical project goes for me from start to finish.
No matter the size of a project, it’s always a good idea to spend some amount of time researching target audiences, competitor sites, and design trends in the same topic or industry. It may be tempting to just jump right into a wireframe or design based off of a few details, but I’ve never regretted taking the time to learn as much as I can about the client and the project first.
It’s also helpful to discuss with the client what the action items for the site should be and then strategize over how to make sure that happens as simply and repeatably as possible.
Not every project may require a full blown wireframe stage where I might use a tool such as Moqups or Balsamiq to draw out exactly how a website will work on every single page, but it never hurts to put my idea to paper first. Once I begin to commit to a layout in Photoshop it’s hard and often too daunting to turn around.
I make a list of the most important elements for the landing page, and any other pages of major importance, and try moving them around in various sizes and positions until I find something I like and think will accomplish the goals I established in step one.
Now that I know what the project should do and it has a skeleton to give it a shape, it’s time to open up Photoshop and begin fleshing out the design. This is where I spend a lot of hours playing with different type treatments, colors, and textures. I recommend grabbing a copy of The Principles of Beautiful Web Design by Jason Beaird; it’s a great little read that has helped me focus on each part of the visual design.
I agonize over the details. It is amazing how things like white space, contrast, and texture can have a huge impact on a user’s experience. One rule I have for myself is to never work on a major design such as the homepage and deliver it for review on the same day. It’s always good to take at least a few hours break from staring at something and come back later. I find myself able to make decisions I couldn’t before, finding little places to make big improvements, and more.
There are lot of days, and sometimes weeks that go between this step and the next that will include client reviews, likely some revisions and quite possibly a lot of frustration. It’s important to listen to everything a client has to say, but not always take their exact direction. The old “make the logo bigger” issue sometimes boils down to something that can be solved in a different way. I try to focus on the problem, not the solution.
Another frustration I often have is when a client just won’t budge on a revision they want. I tell myself, “I’m the chef! I know what side dish and which wine will best pair with this entrée!” But sometimes I just have to bite my tongue and put ketchup on someone’s honey braised duck. It’s okay. Let it go. Move on.
Here’s a part where I find myself bouncing back and forth on a lot. A lot of times a design is kind of basic and typical. It will have a logo/masthead area, a horizontal navigation, a main content column, sidebar, and a footer. For these types of projects I will generally wrap steps 4 and 5 together. But when I’m working on something really unique or out of the box, I start with a blank HTML document and begin laying my markup down naked. Er… let me rephrase that. I write my HTML without any CSS or PHP code behind it. This helps me make sure my code is clean and semantic. It is especially useful for responsive layouts because I will probably have some markup that appears in some views that aren’t in another. I go ahead and put it all in there and then manipulate it as needed using dummy content and a placeholder image site such as Placehold.it or Placekitten.com.
Speaking of responsive design, if you’re not already in the “mobile first” persuasion, well… you should be. Writing CSS for mobile first and then building it up to work in each view as it gets larger is a lot easier than having to override styles going the other direction.
Another nice tip on CSS would be to think in a taxonomy fashion. If there’s something I’m going to be doing a lot to a lot of different items, I create a basic class name and reuse it to my heart’s content. Don’t be afraid to have 5 classes on a single element if it helps you keep your CSS easy to manage and read.
Okay, my site looks great, has all the calls to action in the correct places and is ready to be fitted with an engine: WordPress. Since I already have all of my markup in place, this should be pretty quick for basic sites. I start replacing bits and pieces of the markup and dummy content with the WordPress loop and other template tags. I go on to create any custom widgets and perhaps a theme options page. If my design requires a lot of custom data for various post types, I like to use my Meta Box class as it is an easy way to create custom meta fields.
Shotgun spray of tips: Don’t be a hacker and cut any corners. Create functions that you can reuse for doing repeat operations. Use a unique name space so that you don’t bump into core functions or plugins that may get installed along the way. Don’t “cowboy code”; work on a local dev environment. Use versioning with a Git or SVN repository and use descriptive commit messages so you can go back and figure out what happened and why if something breaks. PHP Doc everything so that you know what it does when you come back to the project 3 months later or have to share some code with a friend.
If I’m working on a team or have a buddy that can help, it’s a good idea to have someone go through all my code and make sure that the code I’ve been staring at for dozens of hours doesn’t have any major bugs in it. In this case, two heads are better than one, because like it or not, I’ve probably made a mistake a three. At 10up, where I am a Design Engineer, this is a required step in our projects and is part of what makes our team strong and educated and insures stable, reinforced code.
I always set
true and use the Debug Bar plugins to fix warnings and notices. But I don’t just test and debug code, though; I test behaviors such as clicking from page to page, using any special functionality the site may have such as a shopping cart or members area. I test in multiple browsers if possible, and have the client working on this as well. I test breaking things on purpose to see what kind of error management I may need to setup. And I don’t forget to play with the 404.php template and make sure the page is useful to users.
When you’re going through this process, try to remember to not look at major issues as setbacks, but as challenges to improve upon the work that you’ve already done.
Finally, I’ll get to a launching point in the project. We may be working in phases and iterations with a “ship early and often” philosophy, or I may be working on small project to a normal completion. I always find bugs after launch that I just couldn’t foresee in all my testing. But I try to bask in the work I’ve done and make notes and snippets of anything that can be used again in the future. I like to find some way to share what I’ve done with others, whether it be a post on Dribbble, an open source project on Github, or just tweeting, “Hey check this out!”.
Question: What do you do differently in your process? Do you add or take away a step or two?