Designing the next generation customer experience in multi-channel retailing

« September 2008 | Main | November 2008 »

October 20, 2008

User Generated Requirements - Part III

In the last post, we looked at how blogging could be used as a means of requirements elicitation for customer facing web sites. In this final part of the post, we will extend the concept outlines in the first two posts and take a look at the challenges surrounding this approach and evaluate scenarios which are appropriate for requirements collection through this means.

Monitor Use

The initial investment that goes into developing a new business service is just a small part of the service’s lifecycle expenses. Over time, significant effort and consequently money is spent in keeping that service updated, hosting it and fixing issues. From our experience, we have sometimes seen businesses spending hours and dollars into maintaining and hosting a service which none of the users seems to be bother about. Examples range from a weather portlet on a financial service provider’s B2B portal, personalization features that are never used, stock ticker portlet on a Telecom company’s website.

Look, it is understandable that we can sometimes err in thinking on behalf of the user. That’s quite alright. But to roll out an application or a service which is not being used a lot and still keep pumping time and money in it is no less than a crime. Enter Web Analytics...

The thing that I love about web analytics is the shear common sense that it makes to utilize this service. It is absolutely essential that when you roll out a new service, you also dedicate half an hour of your time to roll out the analytics code with it. This code will later provide you feedback on how often is this service being used, by what categories of users and how. You can use this valuable information in either deciding how much money needs to be put in this business service or how soon can you get rid of it to launch something new.

Though this topic is not directly related to the subject of our discussion, it is one of the essential new skills that the new age business analysts should be abreast of. Our discussion about the new age BAs would not be complete without this discussion.

Issues in roll out

Like any new idea, this subject too has some issues that need to be weeded through before it can be implemented. Let us discuss a few key ones.

1.                 Concerns about idea leaks


One of the first and the obvious issue about putting your requirements churn out process online and out in the open is the concern for IP. What if you come up with an idea that will totally revolutionize the way B2B transactions are carried out? You don’t want to share it with the whole wide world before it is actually implemented – besides stealing its thunder, it will also negate any competitive advantage that the idea could bring with it. So, how do you handle such ideas in this new world?

The answer can vary based on your personal preferences between the following two options:

    1. You don’t

    2. You do it in a controlled environment.

The first choice is an obvious one. Just because you adopt this new approach on requirements gathering, does not imply that it becomes a mandatory part of your project’s lifecycle. You will still need to use your discretion in deciding which ideas go to the blog and which do not. An IP sensitive idea, obviously, should not be discussed using the approach outlined in this paper. It needs to be very closely guarded and discussed with very few, trusted individuals probably including an IP Attorney.

In certain cases, you may have an idea which could boost your organization’s business potential but you also have a need to test the idea with a reasonably sized group of say, ten to twenty people. Here again the blogs can help you in developing the idea further through facilitated discussion with the only difference being that instead of being a public blog, it is now a private one – with authorization to read and write the content only to that group of twenty odd users. The remaining rules of the game remain the same – you still go through the three phases of floating an idea, facilitating discussion and rationalizing feedback.

2.                 Change Management


Although this approach is no rocket science, it is a little out of the way of how regular SDLC is executed. Like with any other change you will need to address the implications of adopting this new approach in your organization. First and foremost – the people on whom this approach has the biggest impact – our business analysts. Your organization would be extremely lucky to have BAs who are avid bloggers and totally up to speed with how to employ them. If you are not so lucky, then your first course of action would be to enable the BAs to handle this new role – through workshops and trainings.

You will also need to explain them the rationale behind adopting this approach – why it is important to your business, what would happen in case you don’t, what is expected out of the BAs. In short, you will need to sell this idea to your battery of BAs in order to achieve some degree of results. If they are not convinced, they will not be able to do the job right. Make sure you to provide them with a basic primer of enablement before you put them on the new job.

3.                 Analyzing User Opinions


Another stumbling issue in using this approach effectively could be the analyses of user opinions. Remember – not all users may have the right intention or opinion. There will always be some people who feel everything is unnecessary, useless and a waste of time. As a BA, you will need to learn how to weed out users of this type and concentrate your effort on the remaining lot. An effective filtering strategy could be asking these users for reasons, data or other references that they base their opinion upon.

A second, more comprehensive strategy could be to tag a user based on his contribution with a few thumbs up or thumbs down. Whenever you find a reasonable contribution, give a few positive points to this user and few negative ones when the opinion is biased or baseless. This user rating could be made available only to other fellow BAs of your organization. Over time, this accumulated user profile indicator will give you a good idea to see if a particular user is helpful or otherwise.

4.                 Business behind the Technology


One of the traps that you consciously need to avoid is attempting to utilize technology without any business model behind it. In other words, if you set up a Blog service for your portal without backing it up with business analysts, who can facilitate discussions, solicit user reactions and then slice n dice them, then you would not achieve much.

Remember, this approach proposes to employ technology to aid us in getting requirements, it does not automate the process! Requirement gathering is still very much a human activity and it needs to be executed by experienced Business Analysts.

Other Trends

Most large organizations conduct a goal setting exercise at least once in a year where they get their key people in a three to five day workshop to discuss what should the organization focus on for the next financial year. This in turn drives unit wise targets and measurements for the year. This activity is usually carried out with the top brass because of the sensitivity of the discussions and manageability. I think it is a great idea because it lets the organization tap into the collective knowledge, insights and gut feel of a lot of people – not just the board of directors.

With the approach outlined in this blog, a little attitude and dash of drive the same exercise can be extended to your whole organization! Organizations can plan an annual 2 week corporate blogging event where the focus areas for the next year can be set up as blogging subjects. Each area could be moderated and facilitated by a few key members. The floor should then be opened to all the employees to throw ideas and opinions out. At the end of the blogging event, the core team can start dissecting and all the posts and come up with a handful of differentiators.

If you think about it, this is an extremely powerful thought. These days it is hard to say where the next big idea will come from. By extending a discussion from an audience base of hundred or so to more than fifty thousand users you are increasing the probability of landing up with some amazing ideas by a few thousand percents. The technology go achieve this is available, the approach – conceivable! Let us start gathering requirements from the whole wide world.

October 06, 2008

Thinking About The Acquisition Funnel and Conversion Rates

Conversion rates are often on the forefront of the mind when operating a website.  In the simplest of models, increasing conversions can be lumped into those that increase the total number of visitors making it to the point of conversion and those that increase the conversion rate by increasing the probability that a visitor completes a transaction.  Ideally you would like to increase both simultaneously.  A useful way to look at and diagnose problems related to web conversions is through an acquisition funnel model.  This is the first post in a series that will be discussing this model in the context of a generic eCommerce site. 

The acquisition funnel model analyzes the macro behavior of visitors from the traffic drivers that brought them to the site up until to the transaction conformation page.  The premise is that at each stage in the model is associated with a probability that the visitor will leave the site or effectively not complete a transaction.  Thus the total conversion rate can be approximated by a multiplicative function whose variables are the individual probabilities of each stage in the funnel.  Although this does assume independence between the events that caused the visitor to leave the site or abandon the transaction it overall offers a reasonable approximation. 

The first stage of the acquisition funnel examines the relationship between traffic drivers and how effectively the website encourages visitors to stay on the site past the landing page.  This critical step affects not only the total volume of visitors browsing further into the website but also is a direct factor in influencing the effectiveness or cost per visitor to the site. 

An effective means of optimizing the cost per visitor and marketing spending is to link an individual traffic driver to the probability that a visitor will engage with the site.  This probability is typically referred to as the “bounce” rate on a landing page.  This allows one to correlate the effectiveness of a marketing campaign directly to the cost per click.  It also can be fashioned into a marketing effectiveness dashboard to clearly denote which campaigns are working and bring attention to those that are not.  Common reasons for high bounce rates typically include an inconsistent user experience and/or content that differs greatly from the users expectations when they clicked on the advertising link.  Tracking a specific traffic driver all the way through conversion can also be useful to understand the quality of visitor that a specific traffic driver is bringing to the site.

In my next post, I will be discussing landing page optimization in the context of the acquisition funnel model.

October 05, 2008

Browsing Behavior

Experts from digital agencies have, for quite a while, focused on the user experience as the core differentiator on-line.  One-click purchasing has been the target for many on-line retailers since the concept was introduced by Amazon.  While I agree with the importance of the user experience I wonder if there is too much hype around the utopian one-click concept.

My experience is that site visitors exhibit a range of e-commerce browsing behaviours depending on the site, its product range and their point in the purchasing cycle.  I believe my premise applies to all retail e-commerce websites from music to banking and grocery to TVs. 
 
My starting point is the nature of the product.  Typically regular users of grocery and retail banking websites are task oriented; these users make regular visits and typically repeat transactions. Users are annoyed by web-experiences that divert them from their task and the nature of the task is very functional in nature.  Features that streamline purchasing enhance the user experience; these include shopping lists, favourites and one-click checkout.  Products such as clothing, consumer electronics and, to some extent white goods, are less frequent purchases and typically involve comparison shopping, such shopping often involves more than one website.  On an initial visit users may browse through a product set to get ideas about which product to buy, on later visits they may have decided on a product and now  return in order to buy; these websites therefore need to support multiple buying behaviours. 
 
We can identify four browsing behaviours that a site should support:

  • Recreational: The visitor is looking for new ideas and opportunities.
  • Functional: A product type is in mind (for example a camera or a sofa) and the visitor is deciding which product to buy.
  • Pre-qualified: The visitor has a particular brand or model in mind and is looking for the best deal and delivery options across multiple vendors.
  • Surgical: The visitor is here to buy a specific product (probably having been to the site before).  They may have been browsing a paper catalogue.
My argument is that a typical retail website must support all browsing behaviours because a single visitor may exhibit several browsing behaviours over time; no single route to purchasing will suffice.
 
Here are a few ideas about how a website should support these browsing behaviours: 
  • Recreational: Employ sophisticated browsing, search and product promotional mechanisms.  Guided navigation, advanced search and very creative and interactive user interfaces are key.  I like the interactivity on furniture sites for example (take a look at www.boconcept.com).
  • Functional:  Use commonly recognized terms in the navigation scheme.  Surface content to as high a level as possible using product carousels and list best sellers to anonymous visitors.  Provide buying guides and product information for the more complex products.  RS Components has a massive product range and does a very good job of categorization and surfacing content in a browse/search interface (www.rs-online.com).
  • Pre-qualified:  Enable users to browse by brand and product name perhaps using guided navigation techniques.  If possible build a comparison capability (e.g. across multiple vendors), as a minimum make it easy for the visitor to return to buy.  Visitors can browse by brand name at John Lewis and Bloomingdales for example (www.johnlewis.com / www.bloomingdales.com).
  • Surgical:  Help the user to return to the same product easily; Lands End enables users to enter part numbers on the home page as a way of supporting the paper catalogue (www.landsend.com). You can also enter a part number into the search engine at Heals furniture store (www.heals.co.uk) and get to the specific product, although it is not clear from the web site that this is possible (someone in store told me about this feature).
Browsing behaviours are not a substitute for personas; I fully endorse the use of personas to develop and enhance the user experience.  However I do recommend personas are created with visitor behaviour in mind and that page designs are tested for their ability to support all four browsing behaviours.

 

 

 

 

October 03, 2008

Welcome to the Goat Rodeo!

In my travels and conversations with clients, I’m often excited about the high levels of interest I see in all things Web2.0 and Social Commerce. Corporate executives find themselves taking cues from their teenage offspring about what’s hot in this space, chatting to friends about these weird and wonderful behavioral creatures called Social Networks, and engaging on the web in ways they never have before just to keep up with the fast pace of industry developments.

Having said that, I’m struck by the fact that, despite all their excitement, very few people and companies actually have a meaningful strategy to employ the many powerful concepts these topics embody.  As a result, they’re forced to give cagey responses to questions from superiors about how much to budget for Web2.0 and Social Commerce in the next year. It’s almost as though there’s a reluctance to experiment with the ideas because there’s no clear answer to where they should begin. Is a company blog the right place to start? Perhaps ratings & reviews are the way to go? Or maybe we should build a widget for Facebook? You get the point… lots of action but not a whole lot of strategy. Kinda like a goat rodeo…

Recently, I heard the folks from Forrester allude to this phenomenon as “approach avoidance” syndrome. You know, the “I should probably be doing something about this, but I’m not quite sure what, so I’ll just continue to dabble and perhaps one day I’ll wake up and it’ll all be crystal clear to me” approach. This isn’t a challenge unique to web2.0/social commerce, and I’m sure we can borrow countless examples from the history of emerging technologies to illustrate how disruptive technologies can put you into a strategic tailspin. But, that doesn’t mean we shouldn’t address it.

So then, the question remains, isn’t it time for a simple, easy-to-apply framework for understanding the social commerce possibilities and defining the right strategy for your company? I think it is….

Stay tuned for my next blog, when I’ll break social commerce down into the handful of business models it  supports, and discuss a simple approach to creating a meaningful social commerce strategy.

User Generated Requirements - Part II

In the last post, we looked at how blogging could be used as a means of requirements elicitation for customer facing web sites. In this part of the post, we will extend the concept outlines in the first post and take a look at the specifics of how to blog for requirements.

Float an idea

The start of any new business requirement is an idea – an idea that your customers, your business analysts or you may have. For a dotcom portal, when a new idea is conceived, it could be tested in waters by floating it on the official blog. This could be accompanied by providing freedom to provide a ‘Yay!’ or ‘Naah!’ vote buttons or by letting other users comment on it using the pure blogging mechanism. It is up to the business analyst to collect comments, analyze responses to ‘Yay!’ or ‘Naah!” float new threads to clear up the topic, if it was a little ambiguous.

Facilitate a Discussion


Floating an idea is just the first step. For any good, concrete requirement to be finalized, the idea needs to be brewed for a while. During this phase, the business analysts will need to make sure that they keep adding fuel to the fire, maintain the interest and activity while collecting useful information about the requirements along the way.

In certain cases, when the requirements are a little tricky or hard to visualize, it might make sense to put a small prototype out for the users to test drive and give their comments. These prototypes could range from non functional screen shots or visual drawings to a semi functional live application which demonstrates the concept and its uses. The business analyst would again have to track the user feedback – implicit (web analytics) & explicit (blogs) and shape up the requirements accordingly.

Collect & Rationalize Feedback

The last leg of this requirements gathering exercise deals with using the collected feedback to reflect on your system. The approach could vary based on your starting position – if you were planning a new release for your system with limited budget, then you’ll need to come up with an opening moves matrix the following:

Table

The first three columns of this matrix are self explanatory – they talk about the categorization and cost of these requirements along with their brief description. The fourth and fifth columns specify the results from your blogs. The fourth one has a factor of Yay! to Naah! ratio, which implies that for every 100 users that said AJAX requirement should be implemented, 65 said, it should not be. The last column gives an idea about how many people participated in these discussions.

How to Interpret the Matrix

The factors that will decide which requirements should land up being part of your release will be dictated by the last three columns. The requirements that have a Yay! To Naah! ratio of more than one can become candidates for being shelved; unless the ratio is marginally above one and number of votes are extremely high. Such a spread indicates a 50-50 opinion and it can be left to the business sponsor or business analyst’s discretion to can or to go ahead with such a requirement. The low Y to N ratio requirements are the ones that the customers are holding their breath for, the ones that could provide your application an edge over others. These should be considered for development right away.

Other forms of Feedback

Besides the opinion votes, other valuable feedback can also be received from the user which can be used to refine the requirements. Let’s consider the Personalization requirement in the OMM matrix above which had a price tag of $800K for instance. Your original idea of personalization might have been to provide customizable themes and skins, a stock portlet and a weather portlet. From this blogging activity you may realize that most of the users do not feel that they will come to your portal for a stock and weather portlets. They would rather go to a specialized portal for these services. However, they are interested in the themes and skins functionality.

Although this feedback does not give you a go, no-go decision; it does you provide you an opportunity of trimming down your requirements and the associated cost before a single pence was expensed in its development. This kind of feedback can be crucial to keep your costs under control and effectiveness at an all time high.

Not a silver bullet!

It is prudent to mention at this point that this approach is only applicable for your functional requirements – not the non-functional ones. I can’t imagine a dotcom portal discussing its security and availability requirements on a public blog for obvious reasons. NFRs belong to different category and are best discussed and acted upon, internally. Besides, it will be difficult for your end users to understand, relate to or contribute to these requirements.

Support Mode

For most dotcom portals, the support service is offered through a toll free telephone number or through an email.  Since both of these mediums need some effort and at times - hassle, they are usually employed only by users who have a problem. They inadvertently shoo away people who may have an idea for making things better. In today’s world, it is difficult to imagine customers picking up a phone to call in with their advice. Besides, the easier option for them is to hop on to an alternate portal which offers the functionality that they need in the manner that they want.

Now, let’s see what could get the users to speak their mind and why. First, the ‘how’ part – Instead of emailing their feedback, the users can post it on a blog on the portal. This has an implicit answer to the ‘why’ part embedded in it. By giving the users a platform to voice their opinion, you are also giving them an opportunity and a medium to get a social reaction to their opinion. I could write pages about why it is important and how it has worked in the past, but it will make more sense if you look at your favorite socialization website – orkut.com, facebook.com or what have you.

So, in the new world, our support service will also take shape of a blog – where users can list their problems, support staff can reply to queries, other users can respond to issues and users can rate the responses that they get. The beauty of this approach is that besides providing the support infrastructure, this medium automatically builds a knowledge base for the users that new users can search when they have a problem, other users can update and keep it up to date. Or in other words –knowledge base of the users, by the users and for the users.