Webtogs: Diary of an eCommerce start-up

For the last 11 months my team and I have been working on a new ecommerce site, webtogs.co.uk, selling outdoor and adventure sports gear. Sep ‘06 turned into month 1 for our new start-up.

It starts with a blank screen

How well a site converts its traffic to sales is the most important aspect of a good design and has to be the number one goal in anything we do. The average e-tailer converts traffic at roughly 2%. A cutting edge, best practice design, therefore, should be aiming at converting close to 5% of its traffic. eMarketeer did a study on some US sites that were achieving conversion north of 12%. So the design and usability of a site can make a compelling difference to the profitability of the business, the effectiveness of paid traffic and a host of other juicy things.

Amazon have spent years using every evaluation trick in the book to test new methods on their sites. An insider tells me that, whilst they aren‘t that happy with how some of the site looks, it‘s the best possible design they‘ve found for converting browsing traffic to sales.

’Simple is good‘ is another mantra. When designing any kind of application or site, it‘s easy to get carried away and add every feature under the sun (we did to start with!). The more the design of Webtogs evolved, the more we removed. We also stuck a banner on the office wall, that reads “You can‘t sell an interface…”. If you look at a good product page, all you should see is the product.

One of our large competitors (to be) — Cotswold Outdoor — recently re-launched their website, with a new, flash based, offering. Now, in my mind at least, this is a classic example of form before function, and I‘d take a large bet their conversions will suffer as a result.

So what‘s the eCommerce holy grail? As far as we‘re concerned, a site that coverts 100% of it‘s traffic and gets loads of it. Now it‘s fair to say that a whole host of factors come into play here, not least the perceived brand of the retailer, on and offline marketing strategy, etc. The purpose of this article, however, is to talk about what we did, in terms of the site itself and to try and explain why we did it.

Raising the bar

I came across an interesting article, 17 New Rules for Successful E-Commerce Websites which makes some very valid points on what not to do and how to improve the shopping experience. The interesting thing here, is this is really only a place to start.

The bar for eCommerce sites that really want to stand out is getting ever higher. These days, there are many sites selling the same or similar product. A non-negative user experience, with good customer service and on time delivery of the correct product is no longer enough to ensure repeat business or the kind of stellar growth seen 5 years ago.

Page Design

We started off with a truly bad design. We made several classic mistakes and didn‘t think our market through clearly enough.

Our top 5 mistakes:

• We didn‘t start with a basket of actual, relevant, products, giving little or no consideration to attributes (size, colour, etc) and how these would work within the design.
• We didn‘t consider the gender split, resulting in a very ’male‘ design.
• The interface was far too prominent, and with a boxy 3 column design, very limiting for layout. We constantly ran into problems with product titles, breadcrumb trails, long descriptions, long logos (in fact anything long really!), not fitting the layout.
• We gave far too much real estate over to ads and upsell/cross sell type links. Now this works for some things, but for technical outdoor clothing, footwear and gear it‘s not so practical.
• We completely ignored navigation by brand, a critical aspect of any eCommerce site selling branded items.

The next iterations saw some significant moves in the right direction. By this time, we were getting input from a larger and far more experienced team, had some design expertise on board and had Phil Wilkinson aboard, providing valuable insight into conversions from his Kelkoo days.

The current version of the site is our 4th. We‘ve split the development into multiple phases, with less critical but more interesting features put on hold for a future release.

The top 5 improvements we‘ve made, as at Version 4:

• The site is now centrally constructed around our product set, with real-time stock checks for size and colour combinations, via AJAX. This gives us the ability to filter results by size and colour, leading to more relevant results and (hopefully) greater conversions.
• The design is far more gender neutral, and has gender selection as a global element, switching product views on the fly. The conversion benefits here are obvious, as we‘re not alienating 40% of our market.
• Brand navigation is now core to the site, with an integrated ’by brand‘ menu system and brands tagged into the search system. Using Google to take a look at keyword searches in our sector, shows that over 60% of product related searches, include the brand name. I would imagine this is the same across most market sectors.
• Ads, promos and large header graphics have been dropped in favour of a more sophisticated product matching engine, that pairs products together, recommends similar / complimentary products and generally ’cross-sells‘ in a more intelligent way. It will be interesting to see if we‘re right about this, in terms of conversions. I certainly think the trend is moving away from blatant up-sell and irrelevant adverts.
• The interface is far less prominent, allowing a 500% increase in product per pixel on landing pages, results pages, etc.

Showing lots of products on screen

The more product you can pack per pixel, the better the site will be, right? It‘s certainly one of those unwritten rules that gets banded around these kind of articles. We did quite a bit of work on this. We looked at how the ’majors‘ did things, talked to everyone we could, read a multitude of articles and generally examined how we used ecommerce sites ourselves.

50% of our research supported the ’grid‘ view, 5 or 6 products across by any number of rows deep, as used by Play, Gap, etc.

The other 50% supported a more detailed ’list‘ view, with more information per product, but less product per pixel, as used by Amazon and others.

So, in the end we did both. Each product result page can be viewed either as a 5 across grid, or in list view. The default (at the moment!) is grid as we think this will convert slightly better, but if the user changes view, we remember this and always show the preferred view thereafter (cookies willing).

We also allow the customer to change the colour of a product and see an enlarged view, from the results page, assuming they are in ’list view‘.

An interesting side effect of the grid/list topic, is the ability to buy from a list view, without clicking through to the single product view. Gap does this on their website, I would love to know how or if this increases conversions.

How do we improve things further?

Until our site goes live, we have no traffic to play with. With that in mind, we‘ve set-up a closed test group of about 40 people. We‘ve split the group roughly in half for gender, and tried to get a good mix of technical / non technical and nice spread of ages.

Every couple of weeks we release a new version of the site, and ask the group to test new features. Each page of our ’sandbox‘ version has a text box below the footer for comments and bugs. The users log in and we track where they click, what they look at and, obviously, what comments they give us. I would highly recommend this approach to anyone doing a similar project, it‘s proved hugely valuable on a number of levels.

Top 5 things we‘ve learned from our closed testers:

• You can never make things too obvious. Buttons can never be big enough and contrasting elements are hugely important to draw attention to features. The first few releases we did, we were amazed at the number of features people missed.
• You can‘t ever show too much detail about a product.
• When customers have to fill out forms, give them as much help as you can (checkout for example).
• More experienced users spend a very small amount of time on a page, and you‘re lucky if they read 10% of the content.
• Men are far more likely to shop with a product in mind from the outset. Women tend to browse for things and will visit a disparate set of pages.

So, if we get a chance to write anymore here, we‘ll talk in detail about other areas of the site like the checkout process, our detailed product pages, and how we‘re going to bring community features to the venture. We’re happy to be honest, open, and upfront and of course get any feedback we can.

Original post by contact@thinkvitamin.com (Carson Systems Ltd)

The new Opera building in Oslo

Johan Bakken posted a photo:

Original post by nobody@flickr.com (Johan Bakken)

Deliverables That Work: Design Description Documents

Communicating design is tricky business. Designers have invented all kinds of deliverables to handle this job, but we continue to run into the same issues over and over again.

First, we forget things. We leave out some small element that, as it turns out, is absolutely essential to making an interaction work, so we need to revise our designs and send out a new set. Second, we run out of time in our busy schedules and never actually get around to presenting the design work to our clients (whether internal or on the other side of the planet). Third, we forget to include a few extra hours in our project proposals for the inevitable questions developers will have as they dig in and start trying to build the deviously brilliant designs we’ve concocted for them.

Fortunately, there’s a solution to this mess. But for several months now, I apparently couldn’t be bothered to tell you about it.

So today, I’m turning over a new leaf. I’m giving away my secret weapon. (But not until the end of the article.)

Introducing the Design Description Document (DDD)

A Design Description Document (DDD) is, essentially, a slide deck that shows detailed use cases alongside wireframes or comps in an effort to detail all the interactions in a design. And it has quite a few major benefits.

Typically, when an interaction designer completes a set of task flow diagrams and wireframes, she ZIPs it up and sends it off to whoever is pounding on the wall for them and hopes everything goes well. This method invariably backfires.

The ZIP gets sent to the boss, and the boss comes back with questions. The ZIP gets sent to the development team, and the developers come back with questions. The ZIP gets sent to the Documentation team, and the writers wait until something is in QA, because they know the final product won’t be anywhere near what you designed, and then they write their Help documents as quickly as humanly possible.

The Design Description Document cures all of this. First, it communicates to the boss how each interaction will occur, so he has no questions. Second, it tells the developers exactly how things need to work so they know what to build and can immediately start cranking it out. Third, it gives the Documentation team something they can start writing about sooner than later. After all, if the developers know exactly how everything needs to work, odds are much better that the final product will be in line with the original design.

Do you see a trend here? DDDs are good for everyone. Oh wait, what about the designer?

Well, DDDs are designer-friendly, too. They take very little time to create, they’re wickedly easy to update, and, well, they can be branded, and what designer doesn’t love that?

And in addition to answering questions, it helps prevent you from making mistakes and sending them to everyone you know. Because a DDD includes detailed use cases (more on this in a few), you have to actually write down the steps to complete each interaction. As you do this, you can continually check the wireframe to make sure each step can be performed as you’ve written it. If not, you probably forgot to add something to the wireframe. Now you can fix the wireframe, update the DDD, and send out mistake-free design deliverables.

The elements of a DDD

The Cover slide (the first slide in the deck) of every Design Description Document includes a few key elements. Here’s the list:

• Client name
• Project name
• Version number of the application
• Designer’s name
• “Last modified” date

Each subsequent slide of the DDD includes a few more essential elements:

• Wireframe for a single screen, or a storyboard for a complete interaction (you will likely need to scale this down to fit it on the slide, hence the inclusion of a full-size version of each wireframe in your design deliverables)
• Detailed, written use cases for each interaction shown in the wireframe or storyboard
• The file name of the accompanying full-size wireframe image (e.g. 01-Homepage.jpg)
• Notes (if needed)

And if you find that you need some extra room for longer explanations, you can always add Notes slides to the equation, either mixed in with the wireframes or at the end of the slide deck.

The low-down on the how-to

To put one of these babies together, you need the right software. Fortunately, it’s probably already on your machine. As I said, DDDs are slide decks, which means you can put them together in Microsoft Powerpoint or Apple Keynote. You could, in theory, also use Adobe Illustrator or even use keyframes in Adobe Flash.

I created templates in Powerpoint and Keynote to get you started. I use the Keynote version often, and I find that it’s the easiest, but not everyone is lucky enough to own a Mac.

Both versions make use of “master slides”, and this is where the graphics are located. So that I don’t have to reformat text every time I create a new DDD, I keep a version that has three slides by default: the Cover slide, a Design Description slide, and a Notes slide.

To create a Design Description Document, simply pop open one of these files and do a quick Save As to make a copy without affecting the template. Then:

1. Access the Cover master slide and replace the ClientName, ProjectName, Version#, DesignerName, and DD/MM/YYYY text with the name of your client and the project, version number, designer name, and date.
2. Open the Design Description master slide and replace the AppName and V# text with the appropriate info.
3. Go to the second slide in the deck and copy and paste it to make new empty slides - as many as you need to show each wireframe you created. If you have 20 wireframes, create 20 Design Description slides.
4. Next, either insert a wireframe image or paste one in, and then start writing out use cases in the sidebar for each interaction on that screen.
5. When you’re done, either send it off as is, or turn it into a PDF. (This is good for preventing people from editing the document.)

In Keynote, you can simply export the entire document as a PDF, directly from within Keynote, by choosing File > Export and selecting the PDF tab in the resulting dialog box.

In Powerpoint on Windows - well, you’ll have to figure that out yourself. I’m allergic to Windows. Can’t go near the darn thing.

Use cases 101

These templates are designed to help you write effective use cases, but here is a quick crash course.

First, replace the term “Use case” throughout your Design Description slides with tasks. For example, “Sign in” is a very typical heading for a use case. “Retrieve password” is another.

Next, write out the steps to complete each interaction in the wireframe.

Finally, go back over each step in the use case and look for exceptions. Exceptions are things that can occur if a user doesn’t execute your use case exactly as you intended it. A user who enters an incorrect password on a sign-in screen, for example, needs to be shown an error message. The use case exceptions are where you detail these facts.

To do this, explain which use case step is being excepted, then write out the steps for the alternate use case. In the example shown here, a user can enter an incorrect user name (Step 1 in the use case). To remedy this, we show an inline error message, the user enters the user name again, and clicks the Sign In button.

Click here to download

Ha! Made you click.

So, you’re sold? You want the templates so you can create your own Design Description Documents and stop sending out mistakes and answering questions long after a project is over?

Well, then download the template already.

For just a few cents a day, you can help a designer break the habit

Once you get the hang of creating your own DDDs, spread the word. The more designers use these templates, the easier life will be for all of us in the future. I can’t tell you how many times I’ve been sent a set of wireframes designed by someone else and had to go hunt them down and ask questions.

With the DDD, life is richer and more rewarding. It’s like one of those commercials where everyone is happy.

For a full collection of templates, visit www.rhjr.net/ddd.

And if you happen to create a new template in something other than Keynote or Powerpoint, send them to me at “robert at rhjr dot net” and I’ll add them to the collection. (Be sure to give yourself credit in the template. You deserve it.)

Original post by contact@thinkvitamin.com (Carson Systems Ltd)

Richard Moross and Stefan Magdalinski

This interview was recorded at the Future of Web Apps conference in London, February 2007.

Moo has of course recently launched its fantastic stickers - hinted at here. Richard and Stef also discuss the origins of Moo, working with investors and why they chose London as their base.

The Future of Web Apps is back on October 3-5 2007, with more speakers, more topics covered, and more networking events than ever before. Find out more information and book seats now

Oops! You may experience some synching issues - we apologise for this

Vitamin: How do we refer to you guys?

Richard Moross: We’re a printing business – an old school printing business. We’re very print 1.0.

V: Unlike a lot of companies who talk at web events, you actually produce a physical product. How did that come about, and why are you still a tech firm?

RM: I think we have to be. We may be making a 300 year old product with a 500 year old business model, but we have to make it for an audience that’s interested in it today. And to be able to do that in a large way, we need to be online. So I have a design background so it’s my interest in making it look good, but then we need experts like Stef to translate how you turn that into a store, turn that into an experience online so that anyone can buy it from any country in the world. So we have to be a tech company, to be global, to be interesting, to be accessible to people.

Stef Magdalinski: I think the main thing is using the community, using our own community and other people’s communities. The fact that the final bit is print is incidental, we’re more building a way that people can express their creativity.

V: Does that mean we’ll see other products and new areas coming from MOO?

SM: Very, very much so.

RM: I think so. We’re only ever going to do anything if there’s a demand for it, and right at the very, very beginning when we launched minicards, Flickr users were saying from day one “Are you going to do a business card shape? Are you going to do posters? Are you going to stickers?”. I think we said “Yes! Yes! All of those, definitely”. I think it’s a question of what are we going to do first. We want to put as much love into the next product as we put into minicards. It’s a question of how quickly can we do that, how we prioritise which things we’re going to do – but you’re certainly going to be seeing a lot more products in the near, near future.

V: A lot of your customers probably don’t realise where you’re based, they don’t realise you’re a UK company – you’re some guys on the internet. Was that a specific decision?

SF: It was quite a conscious decision. Most companies like us are based in Silicon Valley and we wanted to be based in London, but we wanted to ship globally. We’re on the internet, and it doesn’t really matter where we’re physically based. We happen to be in London. It’s actually turned out that there’s been some good operational reasons for us to be based in London, with the Royal Mail and so forth, but we could be anywhere.

RM: We’re in Clerkenwell, which is the literal and spiritual home of print. It’s home to the oldest printing business on the planet, it’s fantastic. We wanted to be somewhere with some significance; Silicon Valley’s not known for its printing.

SF: I still have a plan for Rio at some point…

V: What came first? Did you start off looking at Flickr and how you could use it for your business?

RM: The business started off completely differently. It started with the idea that business cards are a huge phenomenon; they’re 300 years old in idea, they’re the single most successful networking tool of all time – bar none – they’re still around today. You don’t need batteries, you don’t need Wi-Fi to make them work, you don’t need Bluetooth and they’re still around. They’re here because they work and they’re simple, but there’s never really been a consumer proposition for them. I looked at this and thought this is completely ridiculous; people today have more ways of communicating with each other – I’ve got 10 different instant messenger accounts, email accounts, websites and things I communicate with. And yet most kids don’t have business cards, most young people don’t, even people who are employed lots of people don’t. So we wanted a personal version of the business card and it seemed like there was demand there.

The Flickr part came about 18 months in, I think we launched our business around the same time as Flickr was getting going – we started around 2004.

V: You’re still a young business, but what are the biggest challenges you’ve faced?

SM: In terms of technical challenges, supporting all the languages and character sets that people wanted to print on the cards.

RM: We underestimated the global thing a little bit.

SM: …And how complex that can be. When we launched we could support Western European character sets and we’d never tried a Chinese character set, we’d never tried a Georgian character set.

RM: He doesn’t mean on the web, he means in print as well. We were optimised for web languages, for UTF-8 Unicode, but when it came to printing it – printing Hebrew, or Chinese or Japanese or Georgian…

SM: …Gave our printer a heart attack.

RM: The thing we were worried about was scalability, initially – not necessarily technical scalability, but operational scalability. But again, the machines that poduce the cards can go incredibly fast. We can print around 3 million cards a day – we don’t get 3 million orders a day, yet, I think next week we’re planning on that kind of volume. But that was the thing we were initially were worried about, but it wasn’t really a problem. It was unprecedented how many countries would be interested. I think we’ve shipped in about 107 countries so far and I don’t know how many languages we’ve printed in, but it’s certainly more than five or six.

V: You’ve been entrepreneurs in the past too. Are there any tips you can pass on?

SM: This is my third startup, my third funded startup. I would say the difference this time round is actually having really good investors who are interested. It’s true – I’ve done this before and last time we weren’t well looked after, there were conflicts and difficulties. This time round when you get good support, I think it makes all the difference to a starting business – especially if you’re not doing it in the van…

RM: My piece of advice is don’t work with animals or kids and you’ll been fine. And that is a metaphor, I think.

Original post by contact@thinkvitamin.com (Carson Systems Ltd)

Phishing: continua l’avventura…

Non potevo non pubblicare uno screenshot dell’ultima novità in ambito di phishing, adesso sono anche gentili, e ti avvertono anche dei pericoli che si corrono cliccando i link da queste e-mail.

No Tags

Original post by Spina Rosario