To recap, in part one I talked a lot about the methodology itself – comparing and contrasting it to other ways of doing the same thing, and getting into the nuts of bolts of how a project might look.
Example Case: Forms
Even with all the background from the previous article, you may not be clear about a typical workflow. So let’s take a very common example. When developing back-end systems for clients, there are almost always some kind of human inputs to be collected from creating customers, changing prices, or some other standard process. Forms are what we use to create these inputs.
An example application of the Rapid Prototyping methodology would look like this:
- Requirements gathering – what form inputs are needed, what reports will be needed, who is using the forms (sometimes an admin needs extra fields, for example)
- Model development – build the forms in HTML with no database yet, just the interactive form elements
- Review by client – send the sample to the client and let them play with the forms.
The client usually comes up with some other options they want added, some new inputs, or they want the forms organized a bit differently. Just add these requirements, redevelop the model, and roll them back out for another iteration of reviews.
Requirements Tracking
As you can see from our example with forms, you can end up with a lot of requirements. You will forget if you don’t start documenting the requirements. You don’t need a complicated system, but it helps to have something, anything to help you keep track.
I use a Google Drive spreadsheet that I can share with clients. This allows me to list the requirements and a status, such as “In Progress”, “Completed”, or “Not Started”. If I have multiple developers, I can list who is working on what, making the spreadsheet double as a worklog.
Before I even add requirements to a spreadsheet, I almost always have pen and paper in hand at the interview. I am terrible at drawing, but it helps when you can pull out a piece of paper and get a diagram going or use a white board even.
Immediately after meeting with a client or user of the system, I sit down and write out the requirements. That’s when your mind is fresh and the goals are clear. It takes a few minutes but can save you a lot of time later.
Create a Sandbox
Most of my clients live far, far away from me, so working on a local server that I can use to send ideas to my clients isn’t an option. I usually just work right off of my own site and create a sandbox site, usually on a sub-domain, for my client.
This gives them a fixed location that they can bookmark. I’ll build out the functionality they want, and when it’s approved, I’ll move it all over to their servers. This process has worked very well and gives me complete control of the project.
While I prefer working on local servers just so I don’t have to FTP every little change, I’ve gotten fast enough that it’s not a big deal any more.
Get Good with a Few Key Themes and Plugins
A big key to profitable WordPress development – Rapid Prototyping or other methodology – is to have a few themes and plugins that you work with regularly.
The better you know a few themes, the faster you’ll be able to make changes and create functionality. Every now and then a client will send me a design they like and I’ll have to learn a new theme structure, but the vast majority of designs I launch are based on 2-3 core themes that I know inside and out.
The same goes for plugins. I have a few that I reach for just about every time for anything from testing to membership management. When edits need to be made, I know exactly where to go and what to do.
If I have to learn a new theme or plugin, I do my best to know that on the front end of bidding the project and work that into my bid. At least I’m getting paid to learn something new that way.
Start Reviews with an Approximate Base Theme or Layout
Before I send anything to my clients, I like to have the general theme and layout in place. This is the first thing that clients will notice – things like the website banner, whether they have a sidebar on the home page, and general footer content. These make a big first impression when a client sets their eyes on your prototype.
You don’t want their first impression to be of a very, very rough start. I’ve gotten off to a rocky start a time or two because I rushed some pages and didn’t nail down some basic requirements of the design first. They client got to the page and immediately contacted me with a long list of concerns – all of which I already knew about from requirements gathering but hadn’t gotten around to completing yet.
You don’t need a polished design for a prototype, but you should still be very clear and careful to communicate – set expectations. But I still like to have a base layout and theme in place before sending the clients to the test site.
Ready… Set… Go!!
The biggest part of Rapid Prototyping is to just get started fast. You’re not trying to create a polished product on the first iteration. You just want to get the core features in place and confirmed. Then you can jump into the details, getting client feedback on the fly as you go.
Recap
Rapid Prototyping is a powerful methodology that I’ve found my clients love as much as I do. It’s a clear set of practices that you can apply consistently to get the job done quickly and efficiently. It’s not for every development project, but for the most part it’s a solid place to start.
If you do need extra steps, look to the waterfall method or Agile Software development. These processes have extra steps – or at least the same steps broken into more detail. There may be a longer requirements gathering phase or more thorough testing requirements, for example. Clients may want a maintenance phase where you back everything up and keep the database clean.
Whatever the case may be, it always goes back to your clients. Taking the time to understand their needs and documenting requirements is at the heart of walking away with a paycheck and a happy customer. The Rapid Prototyping method lets me get into the project fast, involve my clients throughout, and to keep the project flowing in a positive direction.
The post Rapid Prototyping Part 2: A Model for Killer WordPress Sites appeared first on YinPress.