Archive for August, 2008

Web Designers and Their Clients: Which Is To Be Master?

Tuesday, August 19th, 2008

In Alice in Wonderland, Humpty Dumpty, sitting precariously on his wall, tells Alice, who is standing and peering up at him,

“The question is which is to be master – - that’s all.”

Web designers and their clients are a bit like Alice and Humpty Dumpty. The question often comes down to “which is to be master”: who calls the shots, and who makes the rules?

Ultimately, it’s the client who’s master. After all, the client pays the bills, and has the final say on what the site will look like. But designers often chafe under this yoke. When the client shows up at the design company’s office, it’s like the enemy is at the gate.

Since we’re developing Sketch, which is designed to speed up the process of creating the structure of a site and populating it with content, it isn’t really appropriate for Webstruxure to take sides in this conflict. But we know what it’s like for web designers, trying to cope with content being delivered late if at all, last-minute demands for major changes to site structure, and naïve requests for visual design changes: can we put the Chief Executive’s photo on the home page, top left? Wouldn’t the whole site look better if the colours were green and red?

So we think it’s important that designers lay down some clear groundrules early in the design process. Clients need to be told when it is the right time to have input, and when it is the right time to let the designer go off and work in peace. If the designer lays out a clear process with clear checkpoints to the client early in the process, it’s more likely that the designer will be left to do the parts that they can do best.

One of the big advantages of Sketch is that it lets the designer specify what aspects of the site the client can work on – whether it’s adding content only, or being able to change both structure and content. The client is provided with an easy way to get on with their part of the process, and is therefore less likely to pester the designer. Sketch gets clients involved in the website creation process – but it gets them involved in the right aspects of that process, not the wrong ones.

Sketch is like a sturdy wooden box. Place it next to that wall in Wonderland, and Humpty Dumpty can meet Alice half-way. He can climb down without a painful fall, and she can communicate with him without getting, or being, a pain in the neck.

Beta planning

Friday, August 1st, 2008

Well, things are hotting up with Sketch. We’ve wireframed a full beta version and gone through it with the whole team. We’ve discussed what should be in and what should be out. And we’ve been brutal. There are two basic criteria for feature inclusion:

  • Is the feature strictly necessary to provide the core value of Sketch?
  • Without the feature, would Sketch fail to work acceptably?

The second question legitimately catches things that the first doesn’t. For instance, a designer’s ability to access and add to a list of projects that are active in Sketch doesn’t solve their core problem. But without it, Sketch is unusable for more than one active project – not a good thing!

We’ve said ‘no’ to other features. It’s been hard, but the generosity of many web designers, who have allowed us into their businesses and their problems, gives us the knowledge we need to assess the relative value of many ‘nice-to-have’ ideas.

So we are really excited about delivering a tight, clean solution to a basic and widespread web design problem. How to get clients delivering their content before the technical build, so that information architecture, testing, and revision can all take place without cost, and so that completion deadlines for the project can be met?