The response has been excellent. Over 10% of those companies have said that they would like to take part in the beta development process, and about another 10% have said that, although they don’t want to take part in the beta, they would like to be kept informed about Sketch.

We have received many extremely valuable comments about the features that designers would like to see in Sketch, and while many of these suggestions won’t be incorporated in the beta, we have taken careful note of them for future releases. And we’ve also got a lot of good feedback about how web design companies are likely to use Sketch, and where they look for information about such tools.

Because of this focus on Sketch, we are going to discontinue this general Webstruxure blog and replace it with a blog devoted specifically to the Sketch beta development process. Here you’ll be able to see detailed feedback on the progress of the Sketch beta. We hope you’ll look out for the launch of this new blog (which will be linked from this page), and follow us as we take the next steps on the journey to the full release of Sketch.

She had it exactly right. Sketch beta is about to be built after almost a year of idea development and market validation, and I feel almost constantly like I’ve got butterflies.  I’m not worried about the product itself, because we’ve worked so hard to make sure we’re solving a real, pressing problem – and our beta proposal has been so thoroughly endorsed by the market.

It’s more all the things I have to do and pull together for the first time – a whole project consisting of technical build, design, integration and deployment, and of media content and relations, marketing, conferences, sales and support. As project leader and front-man, every day is a challenge. Every day I wonder if I can do it, and every day I have to back myself to try.

But it’s great. Truly great. This is what I chose to find out when I decided that I didn’t want to retire from law, even if from a very distinguished career, and wonder “what if?”

It’s the dream.

“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.

• 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?

Halvorson is clear about the consequences of not focusing on content early in web project planning:

“Oh, where do I begin. Delayed start to the writing process, since Web content documentation needs to be agreed-upon, standardized, and built out. More delays, because suddenly gathering up the content becomes a messy, time-consuming, overwhelming task. Dozens of unplanned revisions as more and more content keeps being requested or remembered. Incredible, unavoidable scope creep. Tensions and frustrations because no one has the time (or the power) to slow down and make sure everything is consistent, relevant, clear. And, of course, the end result of crappy content that none of your customers care about.”

Delayed start…more delays…mess…overwhelming task…unplanned revisions…unavoidable scope creep…tensions…frustrations…crappy content…missed customers.

This is not a happy picture.

Our own research backs this up. Our data shows that ninety-five percent of web design companies suffer from late content delivery and late change requests.

Why is this? They can’t communicate the importance of content effectively. And they can’t collaborate with the client to ensure it’s produced early in the process. Therefore, it doesn’t influence the website architecture until too late.

What’s needed, then, is a way for designers and clients to rapidly begin drafting the website so that the importance of content is clear, and so that the client feels able to deliver it effectively. This solution needs to be flexible, fast and very responsive to changes – a site-before-the-site.

That’s why we’re making Sketch.

Behind the scenes, we’ve been conducting research to confirm that Sketch will meet the needs of a significant proportion of web companies and their clients. We’ve talked to as many Wellington companies as we can, and we’re now doing the same in Auckland.

Results so far confirm that the relationship between web designer and client is often strained, and suffers from poor communication; that content is often not provided until very late in the site development process; and that, when it is provided, this often results in late, and therefore expensive, changes being made to the site structure. A tool that:

• makes it easy for designers and clients to communicate and collaborate
• makes it easy to align the expectations of web designer and client, and
• leads to early agreement on site structure and content

is likely to find a ready market if it’s priced correctly.

Our research is continuing, but we’ve gained enough data already to start moving ahead with a beta version of Sketch, built around the set of minimum functions that our research has told us Sketch needs.

We know that we can’t give everyone everything they want, all at once. We’re not even going to try! We’d rather start with something relatively small, something that’s going to give web designers and clients a huge amount of help just by itself, and make sure we’ve got that right. Then we’ll start adding to it bit by bit, testing usefulness with every step.

We figure this is a good way to build something that web designers and their clients are truly going to enjoy using.

So, a Sketch beta is on the drawing board!

In the 2002 and 2004 redesigns, I was the main day-by-day client point of contact with the web design company. Now, as Webstruxure develops Sketch, I’m spending a lot of time on the other side of the fence, talking with web designers and information architects and hearing about their experiences working with clients on sites.

As a client, I worked with the same web design company in 2002 and 2004. The experience in 2002 was very good, and whereas the experience in 2004 was rather fraught at times, we were still happy with the end result.

My main concerns as a client were with ensuring that the designers knew what I wanted, getting direct access to the designers’ technical staff rather than having to go through a gatekeeper, and making sure that the site went live on time – which, in practice, meant a few minutes before it was due to be demonstrated to senior management. The worst times in 2004 were when I felt that our redesign project was a low priority for the design company, and that they were committing resources elsewhere which our project should have had access to.

Now, talking with web designers, I’m getting to see the other side of the coin. Designers’ experiences vary widely, but a common thread is that the site redesign is usually a relatively low priority for the client organization in general, and even for the client’s representative(s) on the project. The core business of the client is not web design, and the work that the client needs to do on the project – confirming information architecture, approving designs, and in particular, providing content – tends to be well down the client’s list of priorities.

So, both clients and designers often feel that the other ‘side’ is letting them down. Both go into projects fearing that something will go wrong, and that expectation is often fulfilled. And both wish that everything could work more smoothly. We hope that tools such as Sketch will help to ease the pain that both parties feel, but the barriers are at least as much psychological as technical. I hope the closer cooperation promoted by tools like Sketch will help break down those barriers as well.

What has this got to do with companies developing new products? I’ll leave you to make up your own mind about ambitious and greedy, but humility is a key attribute for a company trying to match their product to a market that wants it. The discussion starts with a post by Marc Andreessen on Product/Market Fit, which Paul Buchheit then responded to. Rowan Simpson pulls these threads together and adds a little story about the humble origins of Gmail.

It’s another way of saying that the customer (or, in this case, the potential customer) is always right – despite some recent dissenters.

The application developer doesn’t know what the customer wants; the customer does. A feature may be brilliant, the product of hours of inspired coding, but if it doesn’t meet a customer need, then it’s useless. Conversely, a product doesn’t have to be perfect before it’s launched on the market. If it meets a need that wasn’t being met before, then it will be a success. If it doesn’t meet a need, it won’t.

The hard part is to figure out whether the product you’re working on meets a need before you spend a lot of money developing and launching it. That takes a lot of thought, a lot of talking, and most importantly, a lot of listening. And when you’re gripped by excitement, conviction and enthusiasm for a new product, it takes humility to put that to one side, and hear what your potential customers are telling you.

Webstruxure was chosen to build the site by the Government’s Energy Efficiency and Conservation Authority (EECA). This is the third vehicle sustainability site that Webstruxure has built for the Government over the last two years. These sites are becoming increasingly important for motorists hit by the strongly rising trend in fuel prices.

First came Fuelsaver, which allows motorists to work out the fuel consumption of their vehicle, or of a vehicle they’re thinking of buying, based on the vehicle’s characteristics and their own driving habits – and figure out how they can reduce fuel consumption and costs.

Next, we developed Rightcar for Land Transport New Zealand. Rightcar lets users compare vehicles on a range of criteria, including fuel economy, the safety of passengers and other road users, and carbon dioxide and pollutant emissions. The site has been a big success, with a lot of people researching potential car purchases online.

The Fuel Economy Labelling site allows car dealers and others in the industry to print the fuel labels that will be mandatory (with some exceptions, as explained on the site) from 7 April. It also provides information for vehicle buyers and private sellers, including an extensive set of FAQs.

Behind these sites are our tools for collecting and managing vehicle data on behalf of the various government bodies. This has to be understood and massaged into a shape useful for such things as information-based websites and fuel labels.

That’s the link between these sites and our products such as siteNav, Sketch and the forthcoming Canvas – we make tools to turn big blocks of data into useable information.

We are pleased that our expertise in this area has continued to be recognised by Government agencies. We’re also happy that we can make a contribution to improving the sustainability of New Zealand’s vehicle fleet.

I finished by noting how Webstruxure’s Sketch can help with this process, by ensuring that clients get on with creating content earlier in the web development cycle, with content being created in parallel with the creation and approval of the site structure, rather being left to till last. That’s crucial, because it’s often not until they create the website content that clients realise the proposed site structure won’t actually meet their needs.

I stand by what I said then, but discussions with web designers have made it clear that it is almost always difficult to get clients to provide content. Even when the site has been designed and built, and the only thing to be done is add the content, delays and reworking are common.

Why is it so hard for clients to provide content? After all, clients – especially in a government town like Wellington – spend much of their working lives creating complex documents, so it’s not as though they are unused to working with words.

But writing for the web is different. It requires the ability to spell out key points in simple language and put them up front on the page, and it requires the ability to conceptualise content as part of a hyperlinked matrix rather than a linear document.

Those are specialised skills. The people who specialise in them are called web copywriters. They’re experienced at providing content for not just the main text of web pages, but also all the other types of web content: metadata, quick links, ads in the right-hand column.

Naturally, however, web copywriters charge fees commensurate with their skills. In keeping with content’s generally low status, budgets for smaller sites rarely stretch to employing them.

There are books like Rachel McAlpine’s Web Word Wizardry that teach clients how to write content. There are courses that do likewise. But unless content is accorded its necessary level of importance, the books won’t be bought and the content won’t be paid for.

To help deal with this dilemma, we’re looking at ways in which Sketch can help users to improve the quality of their content. A software tool – at least, an affordable tool – can’t do all that’s needed in this area, but it’s possible we can find ways to help clients write content which is clear, concise, focused and readable. This isn’t easy, and it may not be in the first commercial release, but we’re determined to do what we can to make sure that content can wear its rightful crown.