Posts Tagged ‘web design’

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.

Introducing: Ian Edwards

Thursday, May 22nd, 2008

Tim writes:

Here’s the second entry in our series of posts introducing the members of the Webstruxure team. The company was founded by Aaron Stewart and Ian Edwards.

I met Ian when I was working as website content manager for a large Wellington institution, and Ian was part of the team who revamped our website and added new functionality. He has the patience of a saint, because not only did he cope with all the change requests I made as a client, but he’s even been prepared to cope with me as an employee!

And now let’s meet the man himself.

ian_edwards_small.jpg

Ian writes:

Since school I’ve always been interested in the combination of mathematics and design – the patterns in the way things are and in the way they work. Having done my time in academia and the corporate world, working with Aaron Stewart to build and run Webstruxure is my opportunity to do something useful with this interest.

I was lucky enough to be part of the early growth of web development in New Zealand. During that time I learnt not only how to apply consulting and development skills to a revolutionary new way of making things work, but also a lot about running businesses from some very wise heads.

Webstruxure is still small enough that I can legitimately practise all those skills. My glorious title is “Chief Technology Enthusiast” (in small companies you get to have interesting titles), but in practice it’s what you do with the technology that matters …

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