We never present visual designs at pitches. Never. How can we possibly hope to get the visual right when the content or functionality hasn't been ironed out? In other words, if you don't know what something is yet, how can you define its appearance?
Unfortunately, we're asked to do this all the time! Imagine the same scenario in the lifecycle of a new vehicle design:
"Right, so we're going to make a new vehicle."
"What colour do you think it should be?"
"Eh? What, er, colour?"
"Yes. I was thinking red."
"Right, sure... It's just I was wondering how many, you know - wheels the thing might have. Is it a bus? A lorry? A scooter, what?"
"Hmm. Good point. Maybe orange?"
The 'D' word
You get the picture. Of course, usually we'd at least know the kinda thing the client is after, but there's an awful lot of detail goes into making a successful design. Oops, I let the 'D' word slip out there...
When people hear 'design' they tend to think 'colour, shape, layout, fonts, logos...' But that is just one element of the design process. When we talk of design we mean it to apply to the entirety of the enterprise at hand.
First, we'd design the functionality; what's required in the main menu, what happens when you log in, how the cart stores your details, when the email confirmation gets sent out, how long your session lasts and so on. All of those things, and more, define the thing we're building. Of course, how it looks to the user is important too, so we do that next. Colours, shapes, layout, font - you know the stuff!
That's swiftly followed by how it behaves. This is the 'feel' part of the phrase 'look and feel'. For example, how does that link react when I hover over it?
Building in problems
There is another big problem with presenting visual designs as part of a pitch. The problem is that the client might love it so much that they are then disinclined to change it once you've gone through the process of gathering requirements and actually planning the thing they wanted in the first place. "Oh no, we can't move that to over there - I liked it where it was." We've had that countless times when we've attempted to build something 'designed' by a visual designer rather than a user experience/user interface designer.
It's all about the user
Design should start with the user. What do they want to achieve? How will they get there? What are their capabilities? The worst kind of web designer (or any professional service provider for that matter) is one that simply 'follows the brief' without asking those questions.
The true value a lucky client gets from their excellent provider is in the answers to those questions.
The trouble is that most clients don't know about the stuff that happens under the hood - and why should they? They are not experts in user interface design; usually they're experts in the thing that they do. Even then they may only even have a vague understanding of the very business needs they are attempting to address.
For example, when we say "we designed Rapha.cc's despatch system", we do not mean "we did the layout". We mean we, with the client, defined the very steps that their staff would carry out, from printing an order right through to the goods being collected by Fedex, and even including it's return for exchange items.
Now that's design.