Posts Tagged ‘web content’

The Secret to Smooth Project Delivery

Friday, June 27th, 2008

Kate Rutter recently published an interview with Kristina Halvorson, who in the previous month had spoken at Adaptive Path‘s Queens of Content event.

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.

Sketch alpha logo

That’s why we’re making Sketch.

Sketch Update

Saturday, June 21st, 2008

On the surface, not much has changed with Sketch over the past couple of months. The alpha version of Sketch is still available to be tried out online. Some of the web companies we’ve talked with about Sketch are already using this alpha version to work with their clients on planning sites. Even though there are many features yet to be added, they’re finding that the ease of use outweighs the restricted feature set.

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.

Sketch_beta_logo_small.gif

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!

Both Sides Now

Thursday, May 1st, 2008

I used to be the content manager of the corporate web site of a large New Zealand organisation, with over 200 static pages and a whole bunch of dynamic pages to look after. During my time in that role, the site went through one complete redesign (in 2002) and a further partial redesign (in 2004). Cunningly, I managed to leave just as the next full redesign was getting into stride.

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.

Content: The Spectre at the Feast?

Friday, March 21st, 2008

A while back, I blogged about how content is supposed to be king (or queen) in the website development process but often gets relegated to last place in the scramble for resources and time.

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.

Small is Beautiful

Saturday, January 19th, 2008

When I’m not working at Webstruxure, I’m an author. One of the things authors like to do is list all the bizarre jobs they have done on their books’ dust jackets. You know the sort of thing:

Malachi Jevons has been a deep sea diver, alpaca farmer, test pilot, oil rig roughneck, Formula 1 driver, social worker and lie detector test administrator. He now lives a quiet life in rural Afghanistan.

My dust jackets don’t match up. Most of my career has been spent working with language: both the English language, as a technical writer, editor and proofreader, usability tester, documenter, and now blogger; and computer languages, as a programmer way back in the mainframe days.

I’ve worked for big organisations, little organisations, and those in between, and I’m here to tell you that when you’re selecting a web development company, small is usually best.

But why? Aren’t you better off dealing with the big players, with their staff in the hundreds or thousands, their battalions of account managers, their reams of legal boilerplate?

We don’t think so. When you’re working with a small company, you get to deal directly with senior staff and with the developers working on your project, not with an account manager who may have very little knowledge of your organisation and your needs.* You get personal service from people who know your name and what you’re all about (yes, I know this sounds a little like Cheers).

Small companies specialise, whereas big companies generalise. By choosing a small company, you can ensure that you are dealing with people who understand both your business need and the best way of meeting that need. That cuts down on overheads and reworking.

Nobody’s perfect, but the track record of big IT projects strongly suggests that there’s a better way. Unfortunately, in the government sector at least, procurement policies can make that better way hard to pursue. I’ll return to this issue in a later post. Till then, when you’re thinking of which company to use for your next web project, think small.

*I’m not knocking all account managers here. A good one can do a great job of keeping a project on track. But when the account manager sees their role in life as being to ensure that the client never talks directly to the designers or developers working in their project, you have a problem.

Content: The Once and Future King?

Saturday, January 12th, 2008

We all know that content is supposed to be king (or queen, if you prefer). Users may be impressed with the fancy graphics and the Flash animations the first time they visit your site, but it’s content and usability that will keep them coming back.

Yet it’s all too common in the web development process for content to be treated as the scullery boy rather than the king. Lots of people want to talk about the design and argue the toss over what size the logo should be, the precise shade of green to use in the footer, and whose photo goes on the “About Us” page. Other people realise how crucial navigation is, and are prepared to sit down with wireframes and card sorts until the site structure is sorted out.

But as for content … all too often, about two weeks before the site is due to go live, some poor schlub from the client company is told to sit down and deal with the content. If the site is new, they’ll be handed a long word processor document and told to cut it up into web pages. If the site’s a redesign, their task is even simpler: copy the content of the old site and paste it into the corresponding pages on the new site.

Problem solved, right? Now everyone else can forget about content and concentrate on important things, like ordering the canapés for the site launch party. They’ll even let the content person attend the launch, provided he or she stands at the back and doesn’t say anything.

Unfortunately, no. Major flaws in a site structure may not be revealed until someone sits down to flesh out the structures with content. But when the site launch date is staring everyone in the face, no-one wants to hear that the structure doesn’t work. “It’s only content,” someone will mutter. “What’s really important is that senior management agrees on the home page colour scheme.”

So here’s an idea: develop the content along with the structure, so that one informs the other. Use a tool that helps the designer and the client work collaboratively. Use a tool that can turn your online prototype into a basic working site at the click of a button (and the payment of a small amount of money).

Use Sketch, in other words. And it’s coming soon.