You're a good looking blog, what's your owner's name?: June 2006

Friday, June 30

Web 2.0 – Four Key Metrics

Many people have put up web sites with the aim of selling a product or a service, want to improve things to sell more of their product but target the wrong things (such as page hits), or make random improvements without really understanding how effective they are.

Four things that can be easily tracked, the results of the tracking understood, and improved.

1) When someone enters your website, which actions do they perform.

You need to understand the percentage of people who visit your web site who perform different types of action.

Actions may include things like viewing detailed product descriptions, looking at product comparison charts and sending a message to a customer service representative.

2) Does each action drive sales

You need to know the percentage of people who undertake an action who buy from you, and compare it with the percentage of people who enter your site.

How to measure 1 and 2

When someone enters your site you can start a session and record the ID of the session to a database table.
When someone performs an action, you record the ID of the session and a code for the type of action.
When someone buys your product, you record the ID of the session and a code representing "sale".

How to use this to improve sales

If lots of people undertake action 1, but action 1 is not positively correlated with sales, then action 1 needs to be developed to ensure people buy your product as a result of taking it.
If a few people undertake action 2, but action 2 is positively correlated with sales, you need to draw attention to action 2 to ensure that people see it.
If few people take action 3, and action 3 does not drive sales, the action can probably be dropped.

3) Convert Sales into Buzz

People buy based on recommendations from their friends. You need to ensure people tell their friends when they have had good service and track this.

How to measure this

Search for some of your company's sales terms using a search engine. If you sell blue widgets, search for "blue widgets".
See what percentage of these contain positive "buzz" about your company.

How to use this to improve sales

Develop user communities and ensure people can see them.
Encourage people to write about these communities and your products in blogs.
Track how the number of sales compares with the number of web sites with buzz about your products.
Note which user communities and ways of encouraging people to write about your service are successful and do the same in future.

4) Ensure customers remember their user experience and come back for more.

It is easier to keep an existing customer than generate a new one.

How to measure this

Track the percentage of sales that are repeat orders.

How to improve this

Develop a catchy URL and promote it on all your sales materials
Remind users about your site, with carefully targeted promotions. You might want to target some promotions at half of your users, to better see if they result in improved sales.
Note which of these result in an increase in the percentage of sales that are repeat orders, and do the same in future.

Thursday, June 29

Dimensions of Quality, Scope, Budget and Timescale

There is an interesting discussion here about the variables that you can control to decide how to deliver a piece of software. Sam argues that there should be five variables of Scope, Time, People, Process and Risk. In a comment, Basil posted a link to his site, where he says he thinks you should consider four variables of time, resources, scope and quality. I agree with Basil, and think it is important to know what contributes to each of these variables. I came up with the following diagram.

The attributes that define quality are Availability, Performance, Scalability, Security, Accessibility, Extensibility, Deployability and Maintainability. You might decide that some of these are non-negotiable, and others can be traded against each other or against budget, scope or delivery deadlines. (I got these criteria from Ed Tittel's Book, where they are described in more detail)

The attributes that define scope are the numbers of features required and their complexity. Some features might be non-negotiable, but you might be able to simplify them to meet deadlines, budgets or quality requirements. Sometimes you might be able to leave features out.

The attributes that define budget are people, equipment and acceptable risk. You might have flexibility to change the numbers of people or quality of equipment on a project to meet other goals. You might also be able to think about the risks. If someone were to become ill just before release date, is it going to be acceptable to get an expensive consultant in for a few days to ensure the release happens, or should other people within the team know what to do so this won’t be necessary. Obviously it will take time to transfer knowledge amongst the team, meaning less can be done or quality has to be compromised.

Finally, the attributes that define time are a deadline, the acceptability of risk and the time taken to learn and reflect. It may be possible to negotiate the deadline. A degree of risk with the deadline may or may not be acceptable. If someone is ill, it may be acceptable to wait a few days and postpone the deadline, or it may not. You also need time to learn and reflect. The more time you spend learning and reflecting on what went well and what didn’t the faster future projects will be.

When you have thought about these attributes, you need to understand what can be changed and what is fixed. The more that is fixed, the more likely it is the project will fail. However, if there are lots of things that can be changed, you need to think about what the priorities are – is it more important to implement lots of features, or is having a few features of high quality preferable?

When you know this, you can choose a process, waterfall or agile, that is best for this particular project.

Friday, June 23

Attractive User Interfaces with Agile Development

Marc McNeill writes that agile methods result in cleaner and more elegant code than waterfall methods, but waterfall methods produce a more attractive and consistent user interface, giving users a more positive impression of your application.

When features of your application are developed iteratively as separate "objects" by different people, the temptation is for a developer to think about what the user interface needs to be for that object, and not how it fits in with the overall experience.

The way I like to approach this would be to make the first feature to be implemented the "user interface", where we can show users things like what the menu structure of your application should look like, and how in general things should work (e.g. should any dialog boxes be complex with lots of information on the same box, or should they be simplified and spread over several dialog boxes).

As new features are developed, developers can use the basic user interface for guidance and to ensure a consistent looking application. If a new feature needs a new dialog box or web form, the developer can look at the basic UI and see how this should be done. This will also mean that anyone writing documentation or producing sales materials can start earlier as the UI is less likely to change.

However, you need to be careful to make sure that users don't see a user interface and conclude your application is almost complete. Careful communication is important.

Monday, June 5

A bug fix is an enhancement

Dave Churchville writes that not all bugs should be blindly fixed without considering the consequences. I think the decision to fix or not fix bugs should be considered using the same criteria as a decision to enhance your software.

A decision to enhance your software should depend on the following:

1) The payback from implementing the change (in terms of increased sales or reduced operational costs)
2) The cost of making the change
3) The risk that the change will be unsuccessful or cost more than originally anticipated.

A decision to fix a bug should be based on the same principles :-

1) Increased sales or reduced operational costs if the bug is fixed
2) The cost of fixing the bug
3) The risk the fix will be unsuccessful, cause other things to break or be more difficult than anticipated.
4) The risk that if the bug is not fixed it will cause a problem.

Often, bugs are considered separate from enhancements, go into separate databases and decisions are based on different criteria. If they are considered the same thing and tracked and prioritised in the same database, the correct balance can be struck between delivering feature-rich software with lots of bugs or a product with few features but few bugs.

Thursday, June 1

What's on your bookcase?

The books below are currently on my office bookshelf. What is on yours? What does this say about me?