Archive for the ‘web development’ Category

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.

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.

Dangerous Enthusiasms

Thursday, November 29th, 2007

Webstruxure is a small company – seven staff members. So how come we’ve got Government departments among our clients? Don’t public sector IT projects always go to the big players?

The answer to that is that, all too often, they do. And that isn’t just bad news for small to medium enterprises (SMEs) in the IT field. It is bad news for the Government, and therefore for taxpayers, as well.

In future posts, we’ll be discussing why Webstruxure thinks small is beautiful when it comes to Government IT procurement. But let’s start with a trip to the dark side. Let’s start with Dangerous Enthusiasms.

Dangerous Enthusiams. Image courtesy of the publisher.

Robin Gauld and Shaun Goldfinch did the world a favour by writing this 2006 study of how and why large Government IT projects often fail, or if they don’t fail, cost much more and take much longer than intended. They focus on two projects that failed – the Police INCIS system and Health Waikato’s installation of software package SMS – and one that came in well over time and budget, Land Information New Zealand’s Landonline.

Every failed IT project is different, but Gauld and Goldfinch identify some common factors:

  • government managers’ inflated expectations of what the project will do
  • vendors’ inflated promises about system performance and delivery
  • long lead times that make the technology obsolete by the time it’s installed
  • staff resistance to the changes the project will bring about – especially when they have never been asked for their advice on the project or its impact on their work
  • reporting designed to reassure superiors that all is well, rather than raise the alarm about projects in trouble.

Earl Mardle has more to say about Dangerous Enthusiasms.

The difficulties Gauld and Goldfinch identify are hard to avoid in large projects. At Webstruxure, we believe that many of these problems can be avoided by breaking these projects into smaller, more manageable chunks, and using small vendors who have much more capacity to be flexible, responsive, and focused on the user experience.

I’ll say more about this in future postings. In the meantime, does your experience of large Government IT projects, from either the vendor or the purchaser side, match what Gauld and Goldfinch have described?