Web Projects: Never Rush Into Design
You know how it usually goes… the client likes your agency and decides to go with you based on one or two great pitch meetings, a stunning proposal that includes the right timeline / budget and a couple of speculative mock-ups of what their new site could look like in your capable hands – brrrrap everyone rejoice!
You sign contracts and NDAs, and it’s time to actually get to work kicking off the project… the first question comes “When can I see some designs?”
To which many a Web Project Manager out there will reply “In a week” – I believe this is a big mistake.
I’ve experienced this approach, and taken my own enough times to back this belief up, let me explain…
The Speculative Work Trend
Before we get onto why I think providing mock-ups too early is a mistake we’ll deal with something some of you may object to right from the off – speculative web design work at the pitch stage.
There is a strong feeling amongst the web elite that providing visual mock-ups as part of the sales process is wrong for many reasons. Back in 2009 Ryan Taylor wrote a very concise article called Why Speculative Design is Wrong listing reasons like:
- It costs everybody money
- It’s about selling not delivering
- It’s wasteful
- It’s uninformed
- It ignores the collaborative nature of design
I happen to agree with every single word of this post and there have been focussed attempts to champion this approach in the industry, by the likes of NO!!SPEC, in the hope it slowly but surely changes our industry’s attitudes about providing this ‘free’ and misguided work and ultimately eradicates it from the prospective client’s expected sales process.
However, back then, as much as now, I couldn’t help feeling that this would be a hard nut to crack for the very fact that it relies on three things:
- Enough web agencies and freelancers get on-board and refuse to do speculative work
- Those same agencies and people have a solid enough portfolio that they can rely on as sales aid
- They’re skilled enough in sales and client management to sell the ‘no spec’ position and still win the work
I would love this shift to take place and never have to do any speculative design work again, but my gut feeling is this just will never happen on a permanent basis.
The fact of the matter is I believe it really is only established web agencies and freelancers who can pull this off and the majority of lesser known people out there will always submit to the request for mock-ups and see it, as do most clients, as an integral part of the web sales process.
But while I don’t believe this tradition will change anytime soon, I do believe many agencies then make their first crucial mistake – and it isn’t producing speculative designs, but beginning the web project based on the speculative designs that helped them win the work in the first place.
The First Mistake
I understand it because I learnt the hard way, but some people don’t seem to learn. Three of the reasons Ryan Taylor states as a reason to not do speculative work are actually the exact same reasons why using a pitch design is precisely the wrong thing to base the final design solution off – in fact the “It’s wasteful” reason IS often the result of following this path.
What was the point of producing a piece of design only to discard it? Because ultimately you (the client) are paying for the design it is absurd that you would then choose not to use it.
Ryan Taylor, Why Speculative Design is Wrong
However this statement was made on the assumption that all those who produce speculative designs throw them away upon commencement of the web project, well unfortunately they don’t.
Many out there seem to think it’s best to keep the designs in place for one main reason – if the client loved the designs; it must be what they want. Well maybe yes, but it’s important to identify what the client liked about it before proceeding to base the rest of the web project on it.
All too often it will transpire that the functionality implied by those very early designs, based on probably only 3-4 hours of communication with the client, will actually be built without nearly enough thought given to if they really need it.
What you’ll usually find is the client actually loved the style and colours used in the speculative designs – the final design and functionality should not be set in concrete at this stage.
The Second Mistake
The second mistake often made is to start a won web project by briefing your designer to create a homepage and perhaps some sub-page designs for client approval – no no no!
Why not? Well because at this early stage of the project you still have an awful lot of research to do in order to clarify exactly what the best solution is, from a design and functional perspective, so how can you really expect to produce designs that satisfy the user requirements and ensure that the business goals are aligned with the agreed functionality when they haven’t all been completely agreed yet? Quite simply, you can’t.
Good design comes from being well informed. The designer needs to understand business objectives, success criteria, brand personality, competition and numerous other factors in order to provide the right solution.
Ryan Taylor, Why Speculative Design is Wrong
What invariably happens next when adopting this approach is what I believe to be one of the biggest causes of budget overrun in web projects – the designs will be ‘signed-off’, the functionality will then be agreed and defined, and then come the budget and time sapping design revisions that bring those early homepage and sub-pages in-line with what will actually be built.
Don’t rush straight into solution design and build before you’ve done the groundwork. Take time to create a good plan, gather customer requirements, and create solid functional and technical specifications.
Duncan Haughey, PMP: Six Cliches That Make You a Better Project Manager
Why not just skip these unnecessary revisions altogether with some confident web project and client management skills!
The Alternative Approach Bombshell
My approach is to win the web project and then definitely not agree to produce a single design for quite a while.
Now I know what you’re thinking “Haha you naive fool Mr. Barnes, none of my clients would accept your ridiculous approach, they will insist on designs early and throw a complete hissy fit if I don’t do this for them!”
Well yes, in my experience most clients will not expect this approach easily but that’s when the confidence in the approach must show itself in the form of articulate explanation as to why you follow this approach.
The Alternative Approach
It’s at this point, usually in a kick-off meeting, I will explain to the client how the web project will be managed, what phases are involved, in what order they’ll occur and why, and it goes something like this:
- I will take the budget and deadline and cast them in concrete (for now)
- We’ll then talk, and talk for quite a bit and as we’re no longer in sales mode our conversation will almost certainly be more valuable. In these talks I will discuss your business goals and then cross match them against the functionality laid out in the proposal, crossing some off (with your complete approval and buy in) that actually don’t align with any of your goals and keeping those that do
- We’ll then explore those that do in more depth and also discuss other functionality that may not have been in the proposal that would help you achieve your goals, to the point where I can visualise what your requirements are from a design and functional perspective, and have a pretty good idea of how the functionality will work, both in front of and behind the scenes
- I’ll then vanish into my web project management Batcave and create an initial project breakdown that lists all the things we’ll need to complete and my estimated hours and hope and pray the total matches the agreed budget
- If the numbers match, I’ll walk you through this list and explain that this is the first step to confirming what exactly we’re going to build and deliver and eventually you’ll approve this initial list
- Then we produce a sitemap and functional specification for sign-off
At this point the client may protest and insist on designs much earlier as they “need to know what it will look like” or the “board of Directors want designs” – this is when you start the explanation for wanting to take this ‘crazy’ approach.
Convincing Clients on the Approach
Now this is a debate you may win or lose. Losing means the client listens to your point of view and then says they don’t care, they must have designs first – but winning means you have not only almost certainly and immediately stopped precious web project hours being spent on design revisions, but you’ve also gained the client’s trust and respect – both the most valuable digital account and web project management commodities.
The actual explanation itself is nothing short of a crash course for the client in web design and functional separation. During the crash course you need to communicate five key points:
- Achieving the business goals are the primary aim of the web project
- The pages that need to be included to meet these goals can be decided independently of what they look like
- The functionality (what the website or application must be able to do) is completely irrelevant to any design that will essentially be overlaid on top of the moving parts
- By the mere fact the client has hired you means they’ve seen, and liked, the agency’s creative and UX capabilities and need to trust that the same quality level will be applied at the right time
- When designs are eventually produced and presented they will be perfectly aligned with the required functionality, sitemap and business goals and thus reduce web project hours required and minimise budget overrun and thus more money needed
I won’t lie to you, most of the time this conversation is not easy and the client will challenge you at certain points, but the real secret lies in your ability to convey absolute conviction in your approach and if possible back it up with examples of previous web projects where the process was, and was not followed.
For example you could show the client some previous speculative design work, followed by the first set of post-sale designs produced too early, then all subsequent revisions right up until the final version – and then show the amount of hours spent, and duration in work days / weeks, to reach the solution.
This can be followed up quickly by an example where the unorthodox approach was taken and, having used it many times before, I can assure you both the total hours and duration will be comparatively less.
When you start talking in a client’s language about best use of their money and quicker time to market they’ll invariably take a keen interest.
Of course with any web project management approach come challenges and so here are a few tips to help you with this one.
Don’t Be Afraid To Rip Up the Proposal
One thing I’ve learnt over the years is that the sale is the sale, and the project is the project – and both are very different beasts.
By this I mean in my early days as a Web Project Manager I used to take a sold web project proposal, with included speculative designs, and pretty much attempt to use those as a statement of work.
As the web project progressed it transpired that some requirements had been misunderstood, were no longer in the same priority and other requirements would emerge – and by the end of the web project, the final solution was often quite far from the outlined solution set out all those months ago – bad times.
Over time I began to view all of the sales documentation as a guide more than a blueprint.
Nowadays, upon receiving all of the sales ‘stuff’ I’ll open talks with the client and define their business goals, target audience, marketing plan and required functionality again. As described earlier in this post, I’ll then create a web project task list with time estimations and see if they match the numbers in the proposal – often they don’t and this is the point at which I’ll start talking to the client about what it would be best to deliver to them for their budget they have.
This may all sound a little odd, and perhaps if the people selling your web projects are amazingly accurate in requirement gathering then you’ll rarely have to go through this step, but in my experience sales documents are pretty high-level and numbers are ‘ball-park’ estimates.
At the end of the day, when I’m given a web project to manage I consider that it has an initial scope, rough budget and ideal timeline, but that none are final and all are negotiable – and ultimately if I can deliver a solution that the client is happy with, produces commercial return, and my agency can be proud of, then I’ve done my job well and my boss will be happy no matter what he originally sold.
Don’t forget, a happy client is not always one that you delivered a web project for as per the budget and timeline set out in the proposal, but one that is happy with how much they spent on the project and when it was delivered – these numbers and dates are in your control as a Web Project Manager, as is the relationship you form with the client.
I’ve delivered many a web project where it was delivered for twice the cost and weeks or even months later than the original proposal stated, but the client was a very happy person as the process was managed and communicated clearly and the eventual solution was the right one – food for thought.
Ultimately you’re looking for the following client reaction at the end of the web project… is this too much to ask for? I don’t think so.
Collaboration is Key
Moving ahead on a web project without any designs is not easy for some people, but it can also come across as a very waterfall-based approach where the Web Project Manager works in a silo with the client until such times as he or she are ready to hand over to the web designers and developers – but this is most definitely not the correct path.
At all times a Web Project Manager should be working very closely with everyone in their team, in fact failure to do this will always have a negative impact on the web project – no matter what your approach is.
With regards to my own approach, although I will not produce designs for a client until a sitemap and functional specification have been approved, this doesn’t mean I haven’t been talking to the web designers, UX and development teams while producing both – far from it.
For example, when writing a functional specification you have to, to some extent, be able to visualise and define certain parts of the website or application that will influence or perhaps even dictate an eventual design or UX factor – but that’s fine – talk though these aspects with the teams, and talk through functionality with developers.
Not only is this collaborative approach getting the key people involved early, which always help to gain buy in and motivate teams, but in most cases a Web Project Manager is not the best person to define any of these things – this is not their expertise.
Part of a Web Project Manager’s expertise however is to get the right people involved at the right time, to utilise the experts in their field and to gently ensure the solutions provided by the experts are within the web project boundaries such as budget, scope and timeline.
This Works For Me, What Works For You?
So this approach works for me, and works well, but as always in web project management different people have different approaches – so tell me
How do you manage the design phase to be as streamlined as possible?