Posts Tagged ‘web design’

Are sitewide redesigns counter-productive?

Tuesday, April 14th, 2009

For the last ten years I’ve made a living from implementing redesigned/rearchitectured websites, but it’s started to dawn on me that perhaps this isn’t the right approach to be going forward with.

As a coder I learned pretty quickly, the best way to debug something is the scientific methodical way. 

The first step is to identify the area of code/class which the bug is in,  this can be done in many ways so I won’t delve into my particular preference.

The second step once you have said offending class/method is to start logging and commenting sections out to see what fixes it. Now this is the step I’m interested in. 

Depending on your skill level with the language on first pass you may have a ‘hunch’ as to what the problem is so you’ll go straight for the quick win, you’ll change a variable and retest to see if it fixes it. If it works ‘woo hoo’ -> moveon. If not then go to the beginning and start blindly commenting out and testing variables, you may be in for the long haul.

The key though, and if you spot someone not doing this it either means they’re exceptionally competent or exceptionally inexperienced (read:  stupid, a moron, dimwitted, a duh) is that you do one test at a time.

The reason, if you change more than one thing and then retest and it works or breaks, how do you what did what? You don’t.

So a question: when as a company you do a sitewide redesign, how do you expect to know which elements for your redesign worked and which didn’t? Answer: You don’t. You hope that the successes outweigh the failures and that your client decides to pay you regardless. It’s very similar to the problem of knowing if your advertising is successful.

What secret successes went to the grave with this building demolition?

So rather than doing sitewide redesigns just for the sake if it, It would be far more prudent to take the existing site identify key areas which have both flaws and successes and start drawing up experimental alternatives to be designed and built, which can then be a/b tested and analysed in the existing framework and then ported easily into a new design ethos. This way there would be no more of the ‘hit it and hope’ mentality plaguing web design today.

In repost to Ian Lurie’s - Stood Up at the Altar

Thursday, January 22nd, 2009

Today I received the following from MarketingProfs:


gsb_9_09‘Because your customers will abandon online purchases if they encounter a tedious checkout process, it’s critical to make your e-commerce functionality simple and efficient. In a post at the Conversation Marketing blog, Ian Lurie offers recommendations like these:

Never make a customer log in before checkout. “If you show any kind of form requiring a password on the first checkout page,” he says, “you’re losing customers.”

Display shipping costs on the same page as shipping options. There’s almost nothing more frustrating than getting to the confirmation page and discovering the two-day option costs much more than anticipated. A surprised customer might abandon the purchase, rather than going to the trouble of 

choosing a cheaper alternative.

Request information you actually need. “Don’t need their phone number?” says Lurie. “Don’t ask for it. Don’t need their full ZIP+4 code? Don’t ask for it! Are 99% of your customers in the USA? Have that pre-selected in the billing and shipping form.” Make it quick. Small conveniences count for instance, let customers check a box if billing and shipping addresses match, and make any edit from the order confirmation page.

The Point: “If your developer says they can’t make these changes, or even tries to bill you for it after swearing they could build a great site for you,” says a tongue-in-cheek Lurie, “slap them. When they fall down, kick them. When they stop crying, tell them to fix the damned site.”‘

Now I think the main reason this annoys me is his last paragraph which to be fair makes him look like a complete moron and shows just how little he actually knows about what he’s talking about. This is my repost:

All these suggestions are valid, but actually he show’s his ignorance in that most developers or agencies are more than happy to make these changes. The sticking point is generally the business analysts, which actually invalidate the simple logic by looking at the bigger picture.

For example: with his point about not needing the full zip code - is valid from a usability point of view as it takes time to fill in, yet from a business point of view the cost of orders getting lost due to not having a zip code could be substantial so the drop off at this point ends up costing the business less than not having the field at all.

It could be argued that having a more usable form is more profitable in the long run due to brand experience and word of mouth i.e. you may get more customers returning due to a nicer experience, but this is impossible to measure and collate statistics on so it inevitably loses the argument.

I know I’ve had it several times.

Badly Designed websites

Tuesday, January 13th, 2009

This web site is badly designed. I picked colors that I wanted to clash and avoided using anything complementary. The alignments are poor & the effects are cheesy.

WHY? Because I’m soooo bored of polished looking web sites. Someone once said to me that if the web runs along the same lines as the motor industry, then we are nearing the end of the chrome car. So no more:

A classic 1950's car

A 1958 Edsel Pacer

lets move on. I’d like to see a website like this:

a Cadillac Eldorado

a Cadillac Eldorado

(that one goes really well with my new briefcase). Then one day in the future we could get a web site that looks like this:

A Delorean

A Delorean

Although given the political and economical fiasco surrounding the above car, perhaps we’ve already seen it embodied in various behemoths mainly those sponsored by Microsoft (e.g. vista) …