Making websites isn’t easy. In fact it can be very, very difficult. I want to be extremely candid in this post and tell you about our process of evaluating a piece of work through to completing the work.
The service industry is notorious for being a tricky path to tread. Unlike running a product business, where you are selling software or a physical item repeatedly, with design and development you’re actually selling time. But much more significantly than that, you’re also selling hard earned skills and experience.
These can be really hard to put monetary values against.
Most agencies have day rates which inevitably vary (sometimes significantly, sometimes marginally) based on client and/or project. The truth is that many factors govern these rates; such as client budget, the nature of the work, skill requirement, the value of the relationship, and so on.
Arguably these factors should not affect rates but hey – this is business, right?
When we engage a potential client in the discussion to build a website the conversation usually includes (at least) the following topics:
It will probably come as no surprise to learn that quite often we find ourselves starting from a base point because every business is different. So we tend to factor in some time to understand the client business and work out how we can translate these objectives into digital assets.
This brings us onto the first part of our process: scoping
I’m not a fan of ambiguity so I try to get down as much information as possible about the business, it’s customers and all technical requirements based around this. The aim of scoping is to eliminate as many questions down the line as possible, as well as inform the following stages. If you’re interested in jargon, I opt for the agile-fall approach, which is a combination of agile and waterfall. The scoping stage may include creating user stories, wireframes, a technical specification and HTML prototyping (essentially trialling ideas live in the browser).
Typically, clients can expect this process to take 4-8 days.
Sometimes, we’ll build a website on WordPress. Other times we’ll use Drupal. Other times it might even be static (with no CMS, though this is rare). Regardless of the chosen platform, I find that designing and building key pages as static HTML/CSS before integrating into a CMS is very useful because;
It is worth noting that this stage doesn’t abandon Photoshop or Illustrator; we still use these tools, just not as much as we did in the pre-responsive design era.
We would typically allocate 7-14 days for this stage.
You could look at this stage as putting the engine into the bodywork of a car. The CMS, being the engine, powers the website entirely. Without this, none of the content is dynamic or changeable by the site owner, no contact forms work, no blog posts or anything like that can be written. This sounds like a huge job – and it is – but it’s often about the same amount of time as getting the front-end architecture right (in the previous step).
Typically, the client would expect this process to take around 7-14 days.
Quite often budget is an issue for a client. They know what they want to achieve and they know that a website is absolutely the right platform to get them there. The time allocations above are typically what we would regard enough to fully flesh out a mid-large sized project in its entirety, the result meaning a client can expect to spend up to 36 days working with us.
As you may imagine, the cost of this time will add up.
We’re often faced with accommodating smaller budgets so we need to squeeze as much value out of every step in the process as possible – after all, we can’t just lose any of the aforementioned steps. In real terms this means that we focus on the important stuff first. The priority features. We look at the core requirements for the business and the end customer, and we look at the core messaging and content, and we develop out of this.
Essentially, we build a minimum viable product.
But what is a minimum viable product (or MVP)? It’s basically all the things you need to get moving and none of the stuff you don’t. For example, a website selling umbrellas may include a feature to inform the user when it’s going to rain in their local area. This would be filed under nice-to-have and not given priority status, giving way to more important features such as a shopping basket and a well-written delivery and returns policy.
This all ties back into the aforementioned process. During scoping, we would identify the weather forecast as a feature, but if time and budget do not allow, this would not be included in development. Of course, it doesn’t mean we’ve forgotten about this feature altogether; it may be addressed in the next iteration of the website, after our priority features have been implemented first.
In answer to the burning question can you build us a website? the answer, of course, is yes, but we will be fiercely pragmatic in our approach. We believe that focus is the key to delivering a product which does exactly what it needs to do and keeps costs, and timescales, under control.
If you’re one of our peers or perhaps the client of a digital agency, I would love to know what your thoughts are on this subject. Please feel free to leave a comment or tweet me @matt5409