Blog

First off, let me preface this by admitting every project is different. It is completely impossible to account for every possible variable. It is possible, however, to mitigate most issues by having a solid process in place. Ours has be developed over the years by trial and error, but the great thing about running into problems is it forces solutions to be created.

So without further ado, let’s dive into how we handle client projects after contracts are signed and the rubber meets the road.

Step One: Functional Specifications

The importance of functional specification documents are discussed in another post, and this is step one of our process. In our experience if you dive into design, or start writing code based on a few conversations, problems are destined to arise. By having brainstorming sessions to cover as many variables as possible, then actually writing them down formally in a structured format, the blueprint of your project begins to form.

As different types of functionality, user types, database schema requirements etc are derived, this enables us to form both a realistic timeline expectation and a pretty accurate budget estimate. If all these brainstorming sessions have generated great ideas, but don’t fit the budget or would be better saved for version 2, having all this in a functional specification document gives you an opportunity to choose what is the best for you at the time. Equally important, expectations on both sides can be set.

Will there still be variables that come up? Yes. But let’s avoid as many as humanly possible. There are several other elements to this process which are vital and will be discussed in more detail in another post.

Step 2: UI/UX

Now that we have our blueprint, the UI/UX team can get to work. The first item to tackle is wireframes. If the designers can visualize the different pieces of functionality required, plus all the different types of users and therefore the views needed, their creativity can now be sparked. One of the things that most people don’t think about is we live in what I call a 4D world online. Not only do we need to think about how users react on screen one, we also need to think about what we want them to do on the next screen...and the next. You can have the coolest looking aesthetics, but if what happens next isn’t accounted for, user interaction will be lost.

Once we all come to an agreement on the user experience aspect, now is time to dive into the actual look and feel.

Designers reading this post will think I’m glossing over their portion of the project, but we have an upcoming post about this specific part and how much it has changed over the last several years. For now, let’s describe it as one of the most interesting aspects of your project as all the ideas put down on paper start to take shape and actually be seen.

Step 3: Development

While this is actually one of the most complicated, and ultimately without it you end up with a blueprint and great design, since the vast majority of us aren’t programmers, it is very hard to comprehend what goes into this part of a project. Thousands and sometimes millions of lines of code are written. All nicely compacted into files on a server.

In terms of our process, we often refer to this as “when things go dark”. While we all wait for the developers to make the project come to life, until all the parts come together, we can’t really show anything. Sometimes this is a couple weeks. Sometimes several months.

It’s also important to relay that some of this is actually happening during the UI/UX part of the project, often times laying the equivalent of a foundation to your project. Creating databases, connecting to APIs, core functionality and so on.

While nothing seems to be happening, a lot is happening behind closed doors. We make it a point to keep you up to date on how things are progressing until it’s time for step 4.

Step 4: Bug Testing & Quality Assurance

Now that enough of the puzzle has been put together to actually start seeing the picture, it’s time to start figuring out what works, what doesn’t, what needs to be added and how to get things ready to launch. Many companies completely undervalue this part of the process, While we think it is one of the most important. So vital in our opinion, that we have a team of 5 who’s only reason for existence is to figure out what is wrong.

Unless you have multiple minds looking for bugs, it’s very likely that some will be overlooked by the rest of us, yourself included. It is very common for people that have been very focused on a project for a long period of time to “skip over” issues. When a fresh set of eyes start looking, small and sometimes big bugs are found and fixed.

It’s better to go through this process now, rather than start getting emails from your customers, employees, or random visitors who are now getting a bad impression of you because something doesn’t work right. Now is it highly likely something random will come up at some point? Yes, it is. It’s impossible to account for the user that clicked a button 16 times in a row, while using IE7, running 12 different browser add-ons and having turned off javascript for example.

But let’s assume this process goes well and we all agree it’s time to go live. On to step 5.

Step 5: Launch Approval & Going Live

In the interest of utmost honesty, until that final invoice is paid we’re not going live. Assuming that happens, it’s now time to launch.

If you’re hosting with us, we will point the DNS of your domain over to our servers. If you’re hosting elsewhere, then all the code has to be transferred to your hosting company servers, new database created, and the DNS pointed to the appropriate servers.

What Happens Next?

There is much more to cover, but will be tackled in the next post. Client training, moving forward on version 2 functionality, A/B testing and general maintenance. If you made it this far, hopefully you have a good understanding of how your experience with us as a client will be!