Design Proposals, Specifications & Gestalt Theory

Sometimes the thinking takes longer than the doing. Getting to know the client, the opportunities and limitations of the job, and how that can all be folded into the underlying structure of the site takes much longer than actually writing the specification. For us, as designers, that means getting the information architecture — the URLs — right. All you have to do then is write the proposal.

So the thinking is the complex bit, and that’s how it went in the last few weeks as two more jobs were won, both starting today. One for a fellow developer and the other for a social networking site. ‘The most thorough proposal we’ve ever seen’, said the social networking client who works in IT himself. High praise, and many thanks! (You know who you are.) After that kind comment I was trying to identify what differentiates specifications and what we do. Trying to boil it down to a common denominator, I arrived at “experience”. Not just experience in technology though, but in life; business, financial, social and emotional.

It’s a little like Chinese poetry or Gestalt theory: Part decoding the homographs and part prompting thoughts into self-organisation. That might sound like a lot of blather, but creating websites is more a mental exercise than a physical one. Even though we get paid for the doing, it’s the thinking that wins the job and creates something useful.

A user-centred design methodology is all about evidence, forming a plan around empirical data generated by users, to the benefit of all. It’s wonderful, obvious, needed but because of it’s empirical nature, relatively time consuming. It can easily eat a client’s total development budget before a single line of code is written, especially in the case of start-ups or small and medium–sized organisations.

So, we fall back to intuition and experience. We get a good grip on the context for the client: The market, the audience, the purpose. Call it requirements gathering. Then we do a mini usability study of what’s currently available, ask ourselves what features meet the overall objectives and fold them into the specification. We create a user experience from our own experience. We’re not afraid to debate the issues with clients either. In fact, even if they seem to be paying for the doing, it’s the thinking they’re really paying for, so we have to make our case if we want to do good work for them.

So my advice is to do a lot of thinking even at the proposal stage. Isn’t that a waste of time and effort if you don’t win the job, I hear you ask? Yes, it is, but the key word in that question is, “if”. My personal experience has shown that if the thinking is good and has been well presented in a wholistic proposal then you’ll win the job and do a great one to boot. Plus, if you win the job you will have to do the thinking at some point anyway. You might as well do it to help you secure the job in the first place. Even if you don’t get it, you’ll still be learning through experience, so it’s all good.

Here’s a quick list of the steps in a process that enables us (and hopefully you) to develop great relationships with clients, do great work and win business:

1. Show a little leg! By that I mean allow your personality to show in your site. Letting potential clients get to know you passively as people before they contact you mitigates the anonymity of the Web. Let clients see they’re contacting a person or group of people, not an anonymous organisation.
2. Think! Engage! Talk to them, get to know them and their organisation and what drives both. Basically, build a relationship with them before you even write the proposal. Understand exactly who they are, who their audience is and what they want. Use that as the baking tin, stir in some technology and fire up your imagination.
3. Create a template. Use it to organise your thoughts. The headings in ours look something like this:
   1. Executive summary
   2. Brand
   3. Audience and purpose
   4. Features and scope
   5. Technical design
   6. Information architecture
   7. Timetable
   8. Charges
   9. Contact

   In sections A to C you’re demonstrating an understanding of them and what they need you to do. Section D is where the meat starts and section F is where the design starts. If the brief requires it, include a further section about you or your business, keeping it short and sweet.

4. Writing the proposal. This is all about collaboration. Keep talking to your client, feedback ideas that may not have been in the original brief as they come to you. Debate the features, benefits and incentives (function, usefulness and bottom line impact) of each. Give away your knowledge to the client to be paid to use it on their behalf after you’re successful. It’s an investment of the best kind. Throw the final version out to colleagues or proof readers and include the feedback from them too before you deliver.

The very final piece of our particular proposal puzzle is understanding the fundamental purpose of a proposal. If, like us, most of your clients come to you directly, then they have already seen what you do and like it. What they are looking for from you, in essence, is to give them confidence that you can do something of quality for them too. The primary function of a proposal is to demonstrate understanding, provide expert advice and thereby give reassurance that their site, organisation and audience will be in the best hands.