One thing which has been really interesting over the past 5-6 weeks is that having an actual site live is a very useful thing. We debated for quite a while whether we were going to put the current version live, bearing in mind the list of bugs and elements that didn’t quite seem to work correctly, going through the following points:
You actually have deployed something which is a great morale booster- You learn a lot from how people use (or don’t use the site) through asking them, and mainly analysing detailed statistics on usage
- It’s a chance to get out of a development environment and really see what the real world issues that are thrown at you are.
- People stop asking you when you are going to launch!!!
Users who come to the site think that it is a finished version and may not be patient with the flaws- You have to keep fixing the bugs in the live environment which takes up valuable development time
- Investors start asking for traffic figures on the site and to see “traction” when you’ve only just launched and know you need to put another 20 things live and perfect them before your plan really kicks in.
Well – what “have” we learnt directly in relation to Crowdstorm then?
- Not implementing a menu bar sucks in terms of navigation!
- Developing the site with a graphic design team and then implementing everything in one big chunk is wrong and inefficient (I’ll explain why further down in this post)
- We shouldn’t let design get in the way of functionality and usability – it may look great but not if people can’t use the thing
- Use some good quality analytics packages – we have a combination of our own internal tools, Google Analytics, and Clicktale
- Make sure you get the blend right between people who want to browse and people who want to search and know what they want.
- Some design elements and layouts on the web have evolved in a certain way for a reason – being adventurous is good but need to pick the right battles
- Don’t try and gain traffic too quickly so that you can get feedback and improve the proposition before the masses arrive
Iterate, Iterate, Iterate!
The first version of Crowdstorm was a big step for us in terms of trying to build functionality and a design with no historical work to base it on. We took the concept and vision, built 75% of the functionality, then got a graphic design team in to come up with our look and feel. Once the graphical work was done and we were happy with any changes, we then tried to match the CSS / XHTML up with the technical feature set to create the finished product. There was no real way to go back and tweak things without losing time and money.
Fast forward to Jan 2008 – and Crowdstorm V3. This time we have a great team who have had me drill the words “iterate, measure, deploy” until their ears bleed. In a small team of 5, we’ve got two technical developers, one front end interface designer, a search engine specialist, and a product / commercial guy (that’ll be me then).
We build a basic wireframe of a page, write what we want from it, look through any data from the existing site to back up our ideas for change, then code a designed page up in CSS / XHTML. We look through it, play around with a few elements, then go and simplify it by reducing 20% of what we have on it. Once we’re happy with this first version we get the front-end hooked up to the technical backend and deploy it on our beta site behind the scenes, then move on to the next page.
Even then, we’re constantly going back to the older versions and trying new things with the implemented design and refactoring in the technical implementation. We run the analytics software on the pages and get people to try it out too. The main thing I’ve found is that this works very, very well, but it does rely on having all the team on-board in order to understand that nothing is set in stone and everything they do will change.
It’s what I love about the web – seeing a product as a living, breathing entity that evolves every waking minute of the day!
