It’s maybe an unfortunate consequence of the web being so instantly accessible that the development process is often forgotten about when dealing with clients and their expectations.
I’d like to put forward some suggestions and reasoning behind as to why the development processes should be adhered to, even on smaller projects. This article takes you through each step of the process and explains why each bit happens and what it achieves.
Contact our team today to discover how Initforthe can help with the development process.
Come up with a conceptual plan
After the strategists have done their thing and come up with a conceptual plan for what could be done to improve the brand/ROI/other business-related things, the next step is to decide exactly what they meant by it all. The best way to look at each project is to take each part as a sub-project of a much larger umbrella project.
Scoping
Scoping doesn’t mean you have to get technical. It just means you have to decide what you want to achieve from the site, and what you want the site to do as a user. In actual fact, scoping can take on some technical aspect, but I’d suggest looking at
RSpec stories as a good way to describe what it is you want the user to be able to do.
Scoping can take anything from a couple of days to a few weeks to get right, depending on the size of the project and the number of people who have a say in the matter. I recommend limiting this to the client, an Interaction Designer, and a technical person of some kind (usually a Senior Developer or a Tech Lead, both of whom would have a breadth of knowledge). If you don’t want to use RSpec stories, you’ll probably want to split this project up into two - Scoping and then Technical Functional Specification.
RSpec stories allow you to do both at once though, saving time and money in the process. They’re easily understood by non-technical people and they show exactly what needs to happen to the developers later.
Deliverables for a successful scoping development project
- Project Scope (containing outline business case, the method by which this will be achieved, and the salient parts of the functionality therein)
- RSpec stories for the functionality; giving a bit more detail to the project
- Cost estimate for building the project according to the signed off Scope and Stories.
Note that I added the cost estimate at this point rather than before the start of the overall project. This is because usually, we don’t know beforehand the size of the project. Admittedly it doesn’t always work this way round either, but it’s a good idea to aim for. If at this point you find the cost is prohibitive, it’s time to push some functionality back into a second phase. One further contributing factor to the cost will be the complexity of the design, though this isn’t deal with at this stage in the process.
Again, this will need to please the designers, yet keep within the required budget as set out in the initial cost estimate. This can change, as a change request, if the design comes in as more complex than was originally specified (this must be detailed in the scoping document)
Interaction Design
A lot of companies are calling this IA, meaning Information Architecture. I think this is a little misleading, as it infers a technical assessment of the data storage and delivery. Those things are dealt with by a separate process later down the line, though the basics will have been thought through during the RSpec story development earlier. Interaction Designers should be highly aware of the various issues surrounding
accessibility,
web standards and how alternate technologies should be used within the remit of the project. Flash is a good example, and there are countless arguments as to how it should be used on the web.
A good ID should understand these fully and design the interaction of a site accordingly. This will take the RSpec Stories into a format that can be visualised by a web designer, and scaffolded (making up a basic page without an overall look and feel) by the developers. Tools like
Axure RP Pro can make this a straight forward task. Many ID’s like to use Visio, but the interaction doesn’t exist and Axure allows you to model complex scenarios and demo them to the client.
If you’re using Axure, the deliverable for this part of the project will be a model of the site annotated as needed and signed off by the client.
Web Design
The contentious part! Anyone can design a website, right? Wrong. A good web designer will know (mostly through communicating with web developers and gaining experience) what should, shouldn’t, can and can’t be done. Often, everything can be done that is desired, but it’s the method by which that should be done that will ultimately come out from the design. The designs should always be done in collaboration with the same group of people involved in the initial scoping of the project. Peer review is an incredibly important part of making a project like this successful. Get it wrong now, and future maintenance costs will soar. Get it right, and you’ll have yourself a beautiful site that is a joy to use.
Deliverables will be a set of designs, along with annotations within the Photoshop files, and guidelines in a document, which would detail general branding throughout the site - colours, link decoration (underlines, colour, etc), fonts and sizes used throughout, and anything else that is to be held consistently throughout the site.
Development
Given an accurate Interaction Design, this phase can actually happen while the design is in progress. At Initforthe, we often provide a timeframe where we’re not doing the designs ourselves by which we need to have final signed off designs. As long as this is met, development can continue, and the project isn’t held up by requiring designs first. There are two aspects to development in this regard. Front-end development, and Back-end development. The former will usually include building the designs once they have been signed off, and the latter involves building the functionality according to the RSpec stories. The back-end developers will usually build the scaffold according to the Interaction Design, and then plug in the front-end when that has been done later on. This allows everyone to get on with their part without affecting the other.
Depending on how the project is being built, parts of it can be put on a development server during the build, or working parts can be put up as soon as they are done. These can be shown to the client as working models based on the RSpec stories, which now form an acceptance test, and the wireframes built as the deliverables for the ID. It is important if you’re doing this that the client is made painfully aware that the site has areas that don’t work yet, and they don’t yet look like the design that they’ve signed off. But it does give them some level of confidence in seeing things happening. Each day or a couple of days, something new goes up for them to look at.
The key deliverable here is the final working project.
Testing
Testing can be carried out throughout the project. Developers should be testing, and if using languages or frameworks that provide for testing the functionality, this should be used. It takes longer to develop, but you can usually be more certain that the bugs won’t be there if it’s done properly. This is called
Test Driven Development.
Ruby on Rails is predicated on this as a concept.
Final testing should be carried out to perform a number of tasks. Firstly that the functionality works in the browser. If the functionality works, the acceptance criteria can be signed off as complete. The second is the look and feel. This should be as per the designs signed off by the clients and peer-reviewed by the ID and developers. It should be tested in a multitude of browsers, though at the time of writing this article, I’d recommend the following set: Mozilla Firefox 3, Apple Safari 3, Internet Explorer 7, Opera 9.5. The reason for this is because each of these browsers will prompt the user to upgrade when there are new versions available, and as there is no reason not to upgrade, only the latest should realistically be supported. My previous article on supporting IE6 details why old browsers shouldn’t be supported any more.
Once you have functionality and look and feel signed off, you have a working product.
Things to remember during the development process
- There are always a few things you need to keep in mind when you’re building a project of any size. Firstly is the scope. If something falls outside of the scope, it is important to keep track of these changes as requests. Some will impact severely on cost, and often also on time, which will push the delivery date back if it’s agreed that they’re needed for launch. Alternatively, they should be put into a separate project to be started after the end of the current one.
- Next is the copy. Signed off copy is what should be delivered to developers for inclusion in the site. If the copy changes at a later date, this is also classed as a change request and should be charged for. There is a good reason for keeping a strict rule about this. In offline work, if you change the copy after the artwork has gone to the printers, or you change the credits in a video after sending it to the distribution companies, they’ll charge an arm and a leg to get the new version out on time and the printing presses/distribution stopped on the version you initially sent. Just because the web feels instant, it should still be adhered to in the same fashion. A lot of the time, copy changes are where the money is either made or lost on the project.
- The final thing to remember is that it always takes longer than the client wants to build what they’re after! So make them aware of it, and make sure they know they may have to drop some functionality to get the project out on time. Further things can always be added later!
Get in touch with Initforthe today to discuss how our team of software specialists can help with your project.
