A Business Technology Place

Defining an eCommerce Operation – Experience and Usability

UPDATE 10/27/10 – I posted a mind map of my eCommerce Operation on mindmeister that replaces the original map contained in this post. This includes the latest updates to my organizational thoughts on an eCommerce team.

This is my seventh and final post in the series on the topic of defining an eCommerce operation. Certainly I’ve not covered every detail or function of an eCommerce grouped tasked with operations,

eCommerce Operation

An eCommerce Operation Team Structure

maintenance, and new growth. However, this and the previous posts provide a baseline of the most important functions needed in an eCommerce model and provide guidance on the eCommerce team structure.

The area tasked with defining the customer experience and usability of the site is of utmost importance. This part of your team defines the flow of the site, the visual appearance,  and how customers interact with it. The important thing to remember is that to the customer, they are not interacting with your site. They are interacting with your brand. Your eCommerce site is an extension of your brand. It can find, make, keep, and lose customers based on the experience they have with your site.

The experience and usability of the site can be molded in four key areas of release management.  They are prototypes, mockups, use cases, and process maps. They fit logically together and in sequence to guide the designer and implementors in the final output.

Prototypes

The prototype is used to show the concept of a software program or release. The eCommerce team could use a basic functional piece of software, a sequenced set of pictures, a storyboard of hand drawings, or any other type of visual output to display their prototype. The idea is to gain acceptance of the software concept and to create discussion about it to help mold and shape the final output. I know many traditionalists will argue that a true prototype must be a functional piece of software. I do believe this is valuable, and one form of a prototype, but today with today’s tools we have the ability to link static pages together without necessarily making them functional. Remember, the key purpose of this step is to communicate an idea or concept to stakeholders.

In some cases, the prototype is used as a proof of concept. Can the design team make something work on a smaller scale so that it increases confidence it can be done on a larger scale. In this case, the prototype is important in order to secure funding for the software release.

Use Cases

The use case describes how a system responds to actions on it. In an abstract sense we can think of objects performing actions on the system and then specifying how the system will react.  The objects could be people, other programs, or events.  The objects are often called actors and the use case creates a series of steps that describe the action and the resulting response from the system.

The use cases have value because they help the designers and testers to craft the expected flows of the system.  A use case document is also typically easy to read and less formal and verbose than many traditional requirements documents.

It should be noted here, that my good friend Mike Cottmeyer tells me the proper name in agile development methods is “user story“.  Looks like in the case of a user story, the documentation of the requirement is simplified but requires and additional step of documenting an acceptance test.

Regardless of the methodology used, remember the key task with this work is to define the expected use of your system. Define who will use it, how they will use it, and what they expect to see as the results.

Process Maps

Once you have established use cases for a release, you can combine all of them with a process map, or flow chart.  This document defines how all the pieces of the software will fit together and flow to make a complete system. It shows how various use cases may be linked, describes decision points, and shows the possible paths through a system.

Mockups

The mockup is a way of designing the user interface of system through images or drawings. The mockups are not functional. The purpose of the mockups are to allow your designers to create the page layouts that comprise the system. They’ll be considering things like object locations, form layouts, colors, fonts, etc.  Don’t discredit the importance of this step. Many a A/B test has proven that things like the color of button or location of an object on the screen can have impact on your site conversion rates. You don’t necessarily need a designer for this task, but you do need someone who is visual that can bring your process flows to life.

I added the experience and usability functions to the concept map for an eCommerce model that I’ve discussed.  I welcome your feedback and input.  No model is ever complete and in the spirit of continuous improvement I’ll always be looking for ways to tweak to so that it creates more value.

Defining an eCommerce Operation – Release Management

UPDATE 10/27/10 – I posted a mind map of my eCommerce Operation on mindmeister that replaces the original map contained in this post. This includes the latest updates to my organizational thoughts on an eCommerce team.

This is my sixth post on the defining elements of an eCommerce Operation. Previously, I’ve written about management in the areas of solution ownershipcontent managementproduct management, demand management and metrics management. In this post I’ll explore elements related to release management activities.

Release management provides for the justification, prioritization, and specification of software that comprises your eCommerce portfolio. Certainly software development is a discipline unto itself, but these elements cover the basic disciplines and functions of the process. This area of your eCommerce operation needs to focus on the ability to get work started, the ability to prioritize a lengthy queue of requests, and the ability to specify what to build.

Business Case and Modeling

Business case activities are mostly used for new software development or development that can be capitalized according to Statement of Position 98-1. Business cases will typically cover:

  • Objectives
  • Risks
  • Estimated costs
  • Estimated return

Building a business case is not likely to be the favorite activity of the team. But doing this does provide great deal of value for your organization:

  • Allows you to build financial forecasts
  • Allows you to build a project budget
  • Shows the expected return of the work
  • Mechanism to gain upper management support and resource allocation to your project
  • Removes pet features
  • Keeps discussions on the merits of the features
  • Removes emotion

Software modeling is another term with a diverse meaning and that comprises many disciplines, tools, and methods. For an eCommerce team, modeling can be a piece of the front end project justification. A software model provides a simple representation of the eCommerce release for the purpose of relaying its purpose, meaning and structure. The model may be composed of graphics, wire frames, or flow charts.

Feature Prioritization

Software shops have lists of items comprised of new feature requests, previously discovered defects, marketing tests, and customer requests. Developing a framework for prioritizing all these ideas can be tricky due to office politics, available resources, financial justification, etc. But prioritizing the list is an essential activity because the size of the list is longer than what you can accomplish. Plus you’ll want to make sure you are solving the requests in a proper order. Here a few ideas for how teams might prioritize work:

  • Based on what customers will pay to receive
  • Based on estimated return value
  • Based on level of effort
  • Use prioritization families – Groups of related requirements
  • First in First Out
  • Value to cost – Highest value to lowest cost first
  • Contractual obligations first

Requirements and Specifications

Documenting requirements is another area that’s a discipline all unto itself and their are many alternative methods for requirements specification. The important aspect of this part of your organization is that you have team members that a) know the business b) know your customer needs and c) are flexible to be able to modify requirements with changing business conditions. Rather than focusing on any one particular method, I advocate having the right type of team member on point for requirements gathering and specification. Adaptability to change to is paramount because the needs of the business and dynamics of your environment will change.

I added these elements of the eCommerce organization to the concept diagram that I’ve grown with each post.  This updated image shows the team layout that I have discussed so far.  I have one other area to cover customer experience, so stay tuned. ( Select the diagram to expand it.)

eCommerce Operation

An eCommerce Operation Team Structure

Defining an eCommerce Operation – Metrics Management

UPDATE 10/27/10 – I posted a mind map of my eCommerce Operation on mindmeister that replaces the original map contained in this post. This includes the latest updates to my organizational thoughts on an eCommerce team.

This is my fifth post on the defining elements of an eCommerce Operation. Previously, I’ve written about management in the areas of solution ownership, content management, product management, and demand management. In this post I’ll explore elements related to the metrics management of the group.
The term metric in this case refers to a measurable unit of an item that is relevant to the success of the eCommerce operation.  Typically, management will also specify a few key performance metrics or key performance indicators to provide focus on those with direct correlation to business success.  The measurements are intended to be a measure of success against some threshold. That threshold might be a value set by previous baseline or it could be a stretch goal to show improvement in a certain area. Within the eCommerce group I’ll call out the areas where its important to have metrics.

Web Analytics

Web site analytics provide information about how many people are visiting your site, what actions they take, information about their purchase, and other metrics about their identity. This area is important because it assists with determining if your merchandising tactics are working to close sales or provide customers with answers to service needs. Common metrics in this area include:
  • number of visitors
  • number of cart abandonments
  • number of session abandonments
  • number of purchases
  • geographic location
  • referral source (organic, link, keyword, etc.)
  • keywords or adwords used for entry

Customer Involvement

Metrics for customer involvement include traditional survey results but have expanded in recent years with the advancement of social media. Marketers now have the ability to measure customer involvement through other techniques such as Twitter, Facebook, blog comments, and customer reviews. Results in customer involvement can be both qualitative and quantitative. Common metrics in this area include:
  • number of customer reviews
  • average ratings on customer reviews
  • customer feedback on survey questions
  • number of customers participating in discussion groups or fan pages
  • reach of customers as followers

Financial

Metrics related to sales of your products and services are also part of metric management. Depending on your business, you may look to measure revenue, average cart purchase amount, product up-sell statistics, or retail value.  When measuring the financial results of the operation be sure to specify if the metric is taken from the web site analytics or the back office reporting. It’s important to note that the numbers may vary slightly based on the ability of customers to cancel, modify, or return their order after its placed on your web site.

Channel

Metrics related to channel are used to measure the effectiveness of the Internet channel compared to other channels such as phone, paper, or retail store front. In some businesses, it’s important to get as many Internet orders as possible if it provides the lowest cost to service. In other cases, it may be more desirable to have channels work in tandem to capture a sale in anyway possible. Create goals on channel usage and then measure the percentage of orders that come in by each channel. You should also keep the financial metrics split by channel.

Product

Metrics related to products will involve the type, attributes, and quantity of products sold on an eCommerce site. Cross-sell and up-sell metrics belong in this group. Common metrics in this area include:
  • items per order (IPO)
  • number of SKUs sold
  • optional attributes purchased
I added these elements of the eCommerce organization to the concept diagram that I’ve grown with each post.  This updated image shows the eCommerce operation that I have discussed so far.  I have a few other areas to add so stay tuned. ( Select the diagram to expand it.)

eCommerce Operation with metrics management included, more areas pending (merchantstand.com)

Defining an eCommerce Operation – Solution Ownership

UPDATE 10/27/10 – I posted a mind map of my eCommerce Operation on mindmeister that replaces the original map contained in this post. This includes the latest updates to my organizational thoughts on an eCommerce team.

ecommerceoperationMy boss sent me a mind-map from MindMesiter last week for an eCommerce Operation. The map attempts to define the elements that make up an eCommerce operation in an organization. This type of thought and discussion is relevant for those that are running eCommerce and Internet Marketing groups. I’ll summarize my thoughts on the topic in this and future posts. The first area of the map is for solution ownership.  By the way, I don’t actively use the MindMeister site, so I’m converting the thoughts to a concept map using the software found at CmapTools.

Obviously there is not a single owner of an eCommerce operation. There are multiple individuals and team roles that serve as owners of specific elements. I see ownership or ultimate accountability in three key areas of the operation.

Feature Set

The product manager is responsible for sorting and prioritizing inputs from stakeholders that represent multiple functional areas of the business. It’s essential that the product manager know and understand the goals and objectives of the current business plan. These serve as the guide post by which decisions related to priority are made.

The features of a website may be grouped into high level categories such as communication, order entry, or customer relationship. Communication features are related to targeted messages, product display, guides, and instructions. These types of features aim to merchandise the products in the store effectively and to guide customers to targeted areas. Order entry features make sure the customer can put products into a cart and complete the sales funnel. Typical features in this area involve payments, delivery, and order processing. Customer relationship features involve the customer profile, self service ability, help pages, and contact-us type pages.

Results

Depending on the area being measured, the results of the eCommerce operation are owned by the product manager, marketing, or the IT group.

The product manager is responsible for ensuring the site content and functionality are aligned to business goals. This role should make sure that system stays up-to-date, contains fresh content, and does not contain elements that prevent customers from ordering. Results are measured in areas such as product accuracy, web site release cycle timing, and resolution of business needs.

The marketing group is responsible for defining programs and metrics that align to the three eCommerce key performance indicators:

  1. The number of customers to the store
  2. The number of customers that buy from the store
  3. The amount of money that customers spend in the store

The IT systems group is responsible for the availability and performance of the site. If you don’t have IT at the table as an accountable group for eCommerce results in your organization then you need to think twice. Sites that are unavailable to a customer when they choose to shop create a lost sale. There are plenty of sites on the Internet to shop from and chances are a competitor site is available. Slow speed? A definite customer turn-off. Make sure the store is open and the lights are on.

Competitive/Industry Alignment

Who is responsible for making sure  that your site content and offering are competitive with the current market or better yet distinguish you from your competition? This part of the operation should be assigned to Sales and Marketing. Sales because they have the closest relationships with customers and clients. They should be aware of how competitors are positioning their products and services. They’ll know why you’ve not been able to close deals in the past and they’ll know what customers are asking to have in the web site. The marketing group may contain a strategist that can analyze industry level trends or provide input on potential new products where there could be market demand. They can use tools such as SWOT analysis (Strength, Weaknesses, Opportunities, and Threats) to examine how the eCommerce site fits into its market space.

Certainly there are more team members in an eCommerce operation. Each team member is part owner of the overall system and responsible for their contributions. Let me know your thoughts on a eCommerce operation. Is your organization structured differently or do you think it should be structured differently?