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,
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.
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.
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.
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.
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.