Today was good for me. I got a fair bit of work done, and managed to almost finish a fairly hefty document off for a client. That’s what’s bothering me; not the “document” bit, or the “almost finishing” bit… The “hefty” bit. Some of the paperwork we’re churning out for our customers at Bottlebrush is verging on ridiculous.
I think the problem is that we’re trying to be a little too transparent with what we do. We’re offering the client too many options in our solutions, when all they necessarily want is to just “get a web site running”. The competing company around the corner have the philosophy of making the process of getting a web site as easy as it can possibly be, and even though their product might stink, their process is fantastic.
I’ve been idly musing over how to make our “project proposal” — the document that we use to judge if we’re on the same track as the client — a little easier to digest. Currently our standard one is about thirteen pages, chock full of facts, ideology, options and a fair amount of page breaks. While it’s all really important information, surely there has to be a way to condense it into something that is easier on the client.
Some good techniques that we’re already including involve using bullet points, tables, and short paragraphs to get our points across. Another good idea is to have a summary of what the document is trying to say at the start, so that the reader can get the facts straight up and then read on if they like.
I’m thinking that it would probably even be possible to separate our “proposal” into two sections; The first with the price, goals, what’s expected from the client and other proejcty stuff. The second document can be for more generic things like our policies, and an explanation of how things work. But the problem of having an enormous document to wade through isn’t solved by breaking it in half; there’s some important design considerations that need to be made.
We’re in the business of creating semantically rich, well formed, and generally high quality web solutions that make life easier. We should be expected to apply the same principles to our administration work too. My next project is to crack this usability barrier, and I’ll report back here with my results.