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 rejoices!
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 Digital 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 digital 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 digital 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 digital 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 digital 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 digital 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 digital 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 digital project and client management skills!
The alternative approach bombshell
My approach is to win the digital 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 digital 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 digital 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 digital 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 digital 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 digital 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 digital 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 digital 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 digital 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 Digital Project Manager I used to take a sold digital project proposal, with included speculative designs, and pretty much attempt to use those as a statement of work.
As the digital 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 digital 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 digital 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 digital 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 digital 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 digital 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 Digital Project Manager, as is the relationship you form with the client.
I’ve delivered many a digital 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 digital project… is this too much to ask for? I don’t think so.
Collaboration is key
Moving ahead on a digital project without any designs is not easy for some people, but it can also come across as a very waterfall-based approach where the Digital 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 Digital 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 digital 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 Digital Project Manager is not the best person to define any of these things – this is not their expertise.
Part of a Digital 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 digital 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 digital project management different people have different approaches – so tell me
How do you manage the design phase to be as streamlined as possible?
Hi Sam,
Thanks for the article. Do you work on fixed costs projects at all? Just curious on how you handle expectations vs budgets in these cases. Do you have a very clear list of functionality in and out of scope, number of design rounds etc at the sales process?
The approach you discuss in this article is what I’m encouraging at the moment so was great to read more on it.
Hey Sam this sounds like good stuff to me. I really dislike designing, until the functionality and site specification is signed off. Only thing is, when you’re a designer, you kinda have to go along with what the project manager has agreed, if only I had like minded people around me! :)
@Amy, I think every project I’ve worked on has been fixed cost and so I take the full budget and break it down into phases like sitemap, wireframes, spec, design, front-end, back-end, testing etc.
This gives me how many hours I can spend on each part and is communicated on a weekly basis to the client.
From experience you know roughly how much time you have for revisions based on the hours you have and set expectations accordingly.
If approaching what I think is the limit and more is needed, I’ll either ask for more budget or maybe if a feature or two can be sacrificed to free up some budget.
As long as the client has been involved throughout the process and youve built up trust, theyll know youre not managing poorly or looking to simply get more revenue.
As far as defining numbers of scope and revision numbers… the scope must be set clearly as early as possible in terms of features and phase hours yes, but having tried many times to set a numerical limit for revisions I’ve not seen it stick once – instead it’s based on hours allocated vs. hours left – I’ll do as many revisions as you want, as long as you pay for it :)
@Gem, well I have to admit, in business it’s not always possile to follow this approach, but when you can it works!!!
Although, if as a designer youre ever having to just go with what scope the web project manager has decided and have had zero input up till then, I would say thats not right at all.
A good web project manager will collaborate as much as possible throughout the scoping phase. However that said, if the functionality has been defined with true presentation separation, the designers and UX teams still has full control over how that functionaliy is displayed and worked – this can work just as well.
Cheers for the reply, enjoy your articles alot.
Great post, Sam. My biggest problem with web project management has always been the sales hand-off process. Similar to your process, I sit down with the client to again clarify goals, target audiences, timeframes, and so on. While this has worked well for me, sometimes it feels as if I’m being overly redundant. I’m curious — how much collaboration do you have with sales?
@Amy, you’re welcome :)
@Chris, I like to have as much collaboration as possible so I can minimise exactly what you talk about, misaligned expectations. However sometimes collaboration doesn’t happen for a variety of reasons, or the sale is one of those ones where any scope alignment at that stage could affect the chance on success.
In either scenario I’ll just really make it clear in my early talks with the client what my web project process is and that it starts with “re-clarification” of the requirements.
Some may hint it sounds like going over old ground from the sales process, but to that I respond that for that reason it may not take long, but with the web project, and result for the client’s business, now being my responsibilty I want to be crystal clear to maximise the chances of success and to act as a concrete reminder at various stages of what the underlying business aims are.
While there are various takes on the above, the theory remains constant – to establish the end of the successful sale and mark the beginning of the process that delivers results.
This is exactly how we run our studio. It works well because you take the client on a journey, so by the time they see a piece of design they know exactly why it looks the way it looks and why elements are on the page. I believe this reduces revisions and frustrations between the designers and the clients.
In terms of handover from sales, we usually have a few handover meetings with the team that pitched the work and the people that will run the project, and also ensure the client is aware we will validate the costs presented in the pitch with what we would like to do and their budget. Things can often change a lot, particularly during a long-winded RFP!
We present costings at these phases of projects:
* pitch – ballpark range
* reqs – fixed price
* solution definition – fixed price, estimate/ballpark to completion
* visual design – fixed price, estimate/ballpark to completion
* development/implementation – fixed price
This way there are no surprises!
@ani, well f**k me, I thought this had come out of my brain and been learnt through many instances of pain!
Glad to hear it’s not just me though, this being my approach I know how well it works, and how other solutions tend to go – completly tits up!
And the point about reducing frustration of designers is an excellent one and I should have included this in my post.
When working this way I found designers produced better work and defintely loved the fact they knew revisions would be minimal!
Well, I’m sure our process has come from exactly the same place! Our studio was established 16 years ago, and our MD has been working there for about 10. He is anti-speculative work, and I’m guessing that can only come years of experience and trying to solve the same problems!
@Sean, I understand what you’re saying and agree to an extent. Generally if I’m selling to a niche then example of previous work are shown as “examples of what you can have” – and if similar enough to previous projects and the client’s expectations are set correctly, then sometimes you can design first from old projects, and even re-hash sitemaps, wireframes and functional specifications.
But where it’s not a templated type approach, I still believe in holding off from designs early simply because the slightest mistake can really hit you later on in the project.
In a similar vain, and as I mentioned in the article, if you try this approach and find it works for you enough, instead of showing the client a previous project template and features as examples what they can have, you can show previous project approaches and the results with testimonial… changing the niche from industry type to web project approach :)
Great article Sam; just to note that Ryan Taylor wrote the article on Boagworld in 2009, and not Paul Boag.
@Peter, thanks and whoops! :) Edited now, thanks for the spot.