Being the gadget obsessed, late thirtysomething geek that I am. The notion of Webtrends Analytics Insight being built with web standards pleased me greatly for a number of reasons most notably:

1. I could digest dimensions/measures/reports and add context to them ANYTIME,ANYPLACE ANYWHERE so much so we should have called this release Webtrends Martini !  this link truly shows my age

2. Not having to depend on plugins, adminstrator access,mobile applications, being tied to a particular machine or license is a truly liberating experience, imagine measuring the success of a campaign or understanding your traffic IN traffic on the bus, train, tram or tube…

Well you can! Web standards rock!

Props to all involved in the project to make this happen, its a fantastic addition to the Webtrends arsenal.

In order to demonstrate this I went around the house and I tried Insight on all the internet enabled devices within, below are the results of this experiment.

first off, I tried the humble Blackberry Curve and it worked!

I then moved to the lounge and tried the trusty PS3 browser it worked again.

it also works on the iPhone…

and on the G1 Android phone so well I included an extreme close up (below).

I also tried it on the old PSP (excuse the bling colour) it worked.

And finally…It didn’t work on my Pure Evoke Flow Internet enabled radio

So as a challenge, I urge fellow geeks, technoheads and analysts to try Analytics Insight on the devices that you own and let me know results, I will offer a truly amazing Webtrends pen for the image of Insight on a chumby.

During the previous four parts of this series( intro, paper prototyping, design, and web standards), I focused on the redesign of Tag Builder that we completed in the spring. While authoring these posts, I didn’t have the liberty to disclose the application we launched just last week, Webtrends Analytics 9 Insight. However, these posts were not unrelated as the methodologies and principles that guided the redesign of Tag Builder were also core to the genesis of Analytics 9 Insight. In the final post in this series, I’ll introduce Analytics 9 Insight features that were inspired by working directly with our users as we progressed through designing, building and testing.

Stories

For the past year, we have been collecting stories from our customers. While listening to what is currently working for them, we paid special attention to what isn’t. We found that our pro users spent a majority of their time creating dashboards and reports for other users in the organization, from executives to marketers. These other users greatly outnumbered the pro users and found that the Webtrends interface was difficult to navigate and had too many options. We incorporated this feedback into stories that guided our design and development.

Some of the stories that guided Analytics 9 Insight

Prototyping and User Testing

Working from these stories, we prototyped the new application completely on paper, using a process called paper prototyping. A cross-departmental team made up of designers, developers, writers, testers, and others “built” the application with markers, paper, scissors, and tape. We then took the paper prototype on the road to our customer conference in Las Vegas. There, we had multiple sessions where our customers attempted to accomplish tasks derived from our stories. When they succeeded, we knew we got it right. When they didn’t, we broke out the markers and paper and designed new solutions. In the end, the paper prototype became a blueprint for our design and development efforts.

David working on some paper prototypes before testing with users

Beta

We developed the application in just nine weeks. We wanted to get it in the hands of users as soon as possible, initially releasing it into a private beta so we could gather feedback and address issues before releasing it publicly. It was a great thing to do because it gave us the opportunity to fine tune the performance and remove many issues before launching the application to the entire On Demand user base.

White board used to track key issues during the private beta

Launch

We were all a bit nervous as we launched the product. It was exciting to see the activity on Twitter and the early reviews pour in. Our goal was to make the most intuitive, useful analytics application in the industry, but because the stories that guided our design efforts came directly from our customers, we were also confident. To keep the dialog going, we included a Get Satisfaction link right in the product. We want to continue to hear from our users.

Get Satisfaction feedback built into the product

New Features

The main features of Analytics 9 Insight have been fairly well documented by now. Web Services URLs ready to embed in Excel, Story View, and RSS overlay among others. The following are features that you may not have heard about that come directly from listening to our users.

1. Shareable URLs

The original version of share included an email option. Then we thought about how people communicate in the office today and realized with corporate IM, intranets, message boards, etc, email was just one way in which users would like to share reports. We took a step back, removed the email option, and created a URL system that would allow anyone to copy and send the link to any other user. This makes sharing reports extremely easy.

URLs reflect choices in interface. Great for sharing.

2. Dimension and Measure Auto Suggest and Search

Creating custom reports in Webtrends allows for endless possibilities. Unfortunately, it can also create endless reports. When considering many different options in which a user could categorize reports, we discovered that most users could remember which reports they were looking for by identifying which dimensions and measures that the report is made of. In the profile dashboard, below the fold, is a list of all reports available to you for that profile. If you start typing a measure or dimension in the search box, the auto complete will kick in at three letters. Choosing one of the measures or dimensions will filter the list to only include reports with that measure or dimension.

Auto-suggest for dimensions and measures across reports

Filter by measure or dimension

3. Copy and Pasteable Content

Sometimes, when scanning through analytics data, you run across a bit of data here or there that you need to copy and paste into a spreadsheet or report. We prioritized this ability over almost everything else. Whether you are in the profile dashboard and click on table view or are in a report, you are able to select the data directly from the interface. Very handy.

Trend view

Switch to table view for easy copy and paste

4. Weekend Indicators

Insight uses 7-day, 28-day, and 91-day date range shortcuts. The first is typical but the second two are a bit peculiar. There is a reason why we chose them instead of the standard 30 and 90 day range options—weekends. You see, both 28 and 91 are divisible by 7. This allows us to display data ranges in compare mode where the weekdays align. Interesting patterns emerge when you show one date range compared to another and the days of the week align perfectly. This is extremely useful as most businesses see a difference between weekdays and weekends.

28 day compare view with weekend indicators

91 day compare view with weekend indicators

5. Date Range Options

The default date range options, as mentioned, are 7-day, 28-day, and 91-day ranges. However, if you click on Custom, you are able to select any range of days you want. After you make a selection, the compare default is to choose the same number of days just before the selection. To change your compare range, all you have to do is select the starting day and the application will automatically select the range equal to the same number of days as the main range. There are also other shortcuts available in the custom option. The year, quarter, and month are all selectable as shortcuts. You can also use one of the numbered week selectors, just to the left of each week.

Custom date range allows for day, week (shown), month, quarter, year, and custom ranges

6. True Visitor Metric

If you select one of the calendar shortcuts mentioned above (year, quarter, month, week, or day), the Visitors key metric will appear in the profile dashboard. Because Analytics is tuned to scan across these standard date ranges and produce a true visitor count, we added this when those ranges are selected.

True visitor count when date selection is set at standard report period

7. Pivot

When you drill into a report and have a specific date range selected, the last thing you want to do when switching reports or profiles is set up the date range all over again. We know that many users switch profiles when viewing similar reports. We added a dropdown to the right of the profile and report selection that makes this extremely easy to jump from profile to profile or report to report. This saves quite a bit of time.

Click on pivot dropdowns to change account, profile, or report

8. Adaptive Account Dashboard

Every customer is different. Some have many profiles. Some have just a few. And some just have one. We wanted to make sure that each customer/user had an interface optimized for them. If a user only has one profile, then they never see the account dashboard and jump right into the profile dashboard. This eliminates unnecessary steps after login. If the user has less than 25 profiles, they see the standard view which features a single table of profiles that can be sorted by any of the available measures and embeds a sparkline of page views. If the user has more than 25 profiles available, they are presented with the compact view which features four columns and reduces the visible metric down to one. In this view, the user can choose a different metric to display by clicking on the metric dropdown at the top of the screen. They can also hover over any profile to get a multi metric and sparkline view. Interesting tip. A user can force the standard or compact view by adding a query parameter to the URL. ?mode=standard or ?mode=compact will change the views.

Account dashboard in standard mode

Account dashboard in compact mode

Inspiration

There are many more customer-inspired features in Webtrends Analytics 9 Insight. If you are a current user, we hope you enjoy Analytics 9 Insight. After all, you helped create it. If you are a customer and haven’t been an active user, we encourage you to login and give it a try. When you do, don’t be shy about sending us feedback through the Get Satisfaction widget in the product (hover over Help and click Feedback). We will also be conducting some user testing next week, August 17 – 21. If you are in the Portland area and would like to test some prototypes of what we are designing next, let me know in the comments.

In the 1981 documentary “Vernon, Florida” by Errol Morris, there is the following joke…

Two sailors are looking out at the ocean. First sailor says, “That’s a lot of water out there.” The second sailor responds, “Yeah, and that’s just the top of it.”

That is how I feel about web standards. What you see in the browser, is just the final rendering that is a combination of html, css, and javascript. So much care and detail can go into these elements to produce the final result. Often, as I browse the web and stumble across a nicely designed site, I will turn off styles and/or javascript to enjoy the simplicity of the plain html and then scan the css and javascript to see how it was constructed.

In the previous article in this series, I walked through some of the more significant design changes we made to Tag Builder. In this article, I will walk through the changes we made just below the surface, to the client-side architecture (html, css, and javascript) to create a new user experience.

1. Web Standards

Web standards is nothing new. It is usually the term used to describe a web application or web site that uses basic HTML elements for marking up content, css for presentation and layout, and javascript for interactivity and dynamic content updates. Web standards typically avoids using unnecessary browser plugins to do the heavy lifting. With advances in javascript libraries and browser performance boosts, web standards based web applications are approaching native OS level quality. To build a world class user experience with our web applications, building in web standards is key.

Tag Builder

Our goal for this revision of Tag Builder was to strip down the HTML to its bare essentials. Divs, classes, lists, paragraphs, headlines, and form elements are the basic building blocks we rebuilt it with. All of the layout, styling, and behavior is achieved using CSS and javascript. You can see it for yourself by turning off styles in your browser (use these instructions to turn off styles in Firefox, IE, and/or Safari). By taking the time to separate these layers and let the rendered html, css, and javascript to do the heavy lifting, it frees up the server side code to be much simpler. This dramatically improves performance and reduces server side complexity.

Tag Builder with styles turned off

2. Accessibility

One of the major benefits of working with web standards is accessibility. In my previous experiences with developing web applications, accessibility is often thought of as an additional task like multilanguage support. By staying true to web standards, many accessibility considerations come automatically. Our attention to detail created one of the most unusual challenges we have experienced with web standards. We wanted to ensure that the Tag Builder form could be navigated by keyboard. When the elements tabbed down into the Additional Options, we found that the browser would jump the view to each field as it was highlighted. This seems normal, but what was surprising was that the javascript or CSS was unaware that the page had moved and so we saw that fields would just show up in odd parts of the interface and destroy the multi-slide effect of moving from one section to another. We eventually found a way to trigger a call to javascript just before the field was in focus so that all things were ready when the tab action occurred. We were able to keep the javascript sliding effect and the ability to navigate the form by keyboard.

3. Javascript for Helpful Behavior

There are many javascript libraries available today to add a bit of slickness to web interfaces. These can often be overdone and to the detriment of the user experience. For Tag Builder, we had a few areas in which javascript behavior was considered to be beneficial and we used it sparingly.

Tag Builder is one long form with many options. We wanted to make sure that users could access the many options but not be overwhelmed by them nor did we want to split the form into many separate forms as many users like to hop around the options when configuring their tracking code. The solution we came up with was to collapse the options using javascript and then as the user clicks on the options they are interested in, those options slide into view. As a user fills out the form fields, light gray dots turn dark indicating how much of the form is filled out.

Indicator Dots

Another way in which we leveraged javascript for behavior was to use it to surface help topics.

4. Integrated Help System

In the previous version of Tag Builder, each form field had companion help that explained what the option entailed and exposed the details associated with each option. This was met with praise from users but left the form littered with little question marks and reduced the readability. To solve this challenge, we used javascript and css. If you turn off styles, you’ll see that the quick help is part of the html. When you turn styles and css on, you’ll see that only when you rollover a form field, will the quick help appear. This quick help provides enough information to address the basic implication of each form field. We also added a link at the end of each quick help for more info. When a user clicks that, a simple modal window pops up with the related content, explaining the option in further detail.

Rollover Help

With the focus on web standards, the redesigned Tag Builder is much cleaner, simpler, accessible, friendlier, and ready for future expansion. With the launch of the Webtrends API, we also developed a simple web standards based interface for developers to generate and test various web services.

REST URL Generator

I hope you’ve enjoyed this series but you are probably thinking, “How much can this guy write about a simple one page form web application?” This is the last article. For the 5th and final part in this series, I have something much bigger than Tag Builder or the REST URL Generator to detail. Our team has been very busy over the last couple of months. I’ve been trying to pace myself with this series on our new user experience as we wrapped up development so that I could end it with some exciting news. I’m happy to say that next week is it! Follow us on Twitter to find out as soon as we announce and stay tuned to this blog to learn more following the announcement.

Hi again everyone!  I know I’ve been slow getting back to this thread, and for that I apologize.  It’s been a busy time here at Webtrends, and I was caught up in the whirlwind.  I haven’t forgotten my promise, though, to continue this thread, so here’s my next installment.  I’m skipping over the “How to read the Report” entries to post this one first about the numbers on the scenario analysis report.

What you’ve all pointed out in comments is true:  the numbers in this report don’t add up in the ways we might expect.  There’s a reason for this, though – actually, several reasons – that I’ll walk us through in this post (settle in; this is a thick read).   See, in a perfect scenario, all our visits would enter the process at the first step, convert through the steps in order, and complete the scenario without ever going anywhere else.  Most scenarios, though, have room for improvement – information is missing for the visitor, or a step is optional, or … well, you get the picture.  In such cases, it’d be useful for us to know how users meander in and out of a scenario, so we can identify steps we could improve upon, right?  That’s what this report is designed to do – and at the risk of sounding a bit self-serving, I have to say it does it quite well.  And that’s precisely why the numbers can seem so confusing – because this report follows the user’s meanderings, focusing on their activity rather than on totals.

Let me explain with an example (with many thanks to Xavier Le Hericy, who built the example!).  Let’s say I have three people visit my site and interact in a scenario.  Here are the paths each of them take:

Visit A:
(1) Views Page 1.
(2) Enters Step 1 (Product Page View) in the scenario.
(3) Views Page 2.
(4) Returns to Step 1.
(5) Views Page 3.
(6) Enters Step 3 (Started Checkout), skipping Step 2 entirely.
(7) Goes back to Step 2 (Cart Add).

Visit B:
(1) Views Page 1.
(2) Enters Step 1 (Product Page View) in the scenario.
(3) Views Page 2.
(4) Views Page 3.

Visit C:
(1) Views Page 1.
(2) Enters Step 1 (Product Page View) in the scenario.
(3) Goes directly to Step 2(Cart Add).
(4) Goes directly to Step 3 (Started Checkout).

None of them complete the checkout process for one reason or another.

Fairly straightforward visits, which lead to the following results in the scenario analysis report.  First, with step transitions:

Okay, let’s walk through our examples so we understand what we’re seeing here.  The text above from our engineering pals helps, but let’s translate it clearly into the examples we have above.

The Product Page View we see at the top left comes from Visit A. The two visits we see on the top right come from Visit A as well, though – in that visit, the user viewed a product page, then jumped to starting checkout.  So, if we try to add up numbers, we’d be literally tripling the number of visits – this entire line refers to a single visit, but show multiple paths through the scenario.  That’s one reason the numbers don’t add up.

Okay, moving on to Step 2.  Visit C converted from Step 1 to Step 2, so that’s the single visit we see next to the green arrow leading to Step 2.  But we also have Visit A represented once more – when the user moved from Step 3 to Step 2.  See how this is affecting the numbers?

Moving to Step 3, we see again that Visit C converted directly from one step to another – hence the 1 visit by the blue down arrow. Both Visit A and Visit C saw Step 3, which is why we have two visits at this step.  Visit A also is reflected on the left, since the user viewed a product page, then came to Step 3.  Finally, Visit A is also on the right, since it’s the visit that went back to Step 2 from this step.

So, this report shows us the flow of visits through the scenario steps, but there’s no way we could add up these numbers to get an appropriate number of visits to/from the scenario itself.  That’s just not what the report was designed to do!

Let’s check out the other view – scenario entry and exit pages:

Again, thanks to the Xavier for the explanations above – now let me walk you through the visits one more time.

Visits A, B, and C all enter the scenario from viewing page 1; therefore, they’re reflected both in the three visits on the left and the three visits to the product page view.  We don’t see the second visit to this step that took place; that’s reflected in the Step Transitions view instead.  On the right, we see that Visit B has moved on to another page and then never came back to the scenario – whoever they were, they played around elsewhere on the site, then headed out.

Visit C converted from Step 1 to Step 2, so that’s our one visit we see coming down to this step.  But we have two visits at this step, and none coming in on this step, which looks confusing until we take a look back at Visit A.  Ah – this visit did not convert from Step 1 to Step 2 (it jumped from 1 to 3 and back to 2), nor did it come into the scenario at Step 2 (it saw Step 1 first).  It was simply out of order – but it was still a visit to Step 2.  Hence, the two visits on this step – and we see another reason why these numbers won’t necessarily add up.

Visit A just keeps complicating things – this is the step from which this visit exited the scenario and either idled out of the visit or left the website entirely.  That’s the visit to the right of Step 2.

Visit C is now the only visit we have left, and it’s the visit that converted from Step 2 to 3 that we see.  However, again we have two visits on this step, and again it’s good ol’ Visit A that’s being reflected.  That was view #6 in Visit A’s progress on our website.  The visit we see exiting at this step is Visit C, since it didn’t move on to Step 4.

So, once again, these numbers won’t add up because of a couple of meandering folk on our website, weaving their way in and out of this scenario.  Multiply that by 10,000 visits or more, and you can start to see why these numbers seem out of whack on even infrequently-visited scenarios.

Let me say that I agree wholeheartedly that this lack of the clean-cut ability to add up numbers and see exactly how many visits were part of this scenario makes this report confusing.  However, that’s also what makes this report so valuable – we can see exactly what’s happening at any step in the scenario, and we can tell when visits meander through and out of the scenario.  That’s the actionable information this report is designed to provide – the kind of information that helps me optimize each step along the scenario, ensuring that my visitors always have the information they need to keep moving through the scenario and complete it.

Just to make you feel better, though, there actually are a couple of places in which the numbers add up.  Check out the image below:

Isn’t Xavier great? These are his notes, which were honestly a great relief to me.  I really wanted to be able to tell you that the numbers do add up, and here’s proof – some of the numbers really do!  Just not always the ones people ask you about.

So, I hope this post is helpful.  I’ve still got a couple more of these posts in the works, so I’d love to hear more about what you’d like to know about this report!

In the previous two articles*, I introduced the newly redesigned Webtrends custom tracking-code creation tool called Tag Builder and then provided some background into the user centered design methodology, Paper Prototyping, used to construct the flow of the application. In this post, I will highlight the most significant design improvements that defined the new look of Tag Builder and influence products to come.

1. Palette

The most noticeable change with the new Tag Builder is the monochromatic color palette. It is sparse, simple, and gets right to the point. As we push the design of Webtrends applications forward, we are intent on establishing a professional, concise, and highly engineered look and feel. Think German automobile. Think professional photography equipment. Webtrends products are professional products. The palette of charcoal, magnesium, and white dominate the design while hints of litho blue and stop sign red reveal themselves on hover states and error messaging. Color is still there, just reserved for when it is effective.

Color palettes (before and after)

In an addition to Tag Builder, you may have also noticed that the brand identity for Webtrends received a facelift. The webtrends.com website reflects this and is being rolled out across all of our marketing materials. The new wordmark is modern. The new palette, is complimentary to Tag Builder. Both are heavily monochromatic but the modern blue and warm grays have a much stronger presence with the outbound marketing while the product reserves its use of color for important indicators and highlights. This sophistication in coordination is like the outfits of a well dressed Hollywood couple attending the Oscars. Tag Builder was released before the branding update was revealed and so you will see future refinements to product design to reflect alignment.

2. Grid

The grid has received a lot of attention in the web design community in the past couple of years (thanks to pioneers like Khoi Vinh at the New York Times). The grid has been used for decades to organize typographical information in print so that blocks of type define the geometry and patterns of the design. This allows for the elimination of ornamental design clutter and reduces design to its essential elements. The new Tag Builder uses a 960 based grid and this allowed us to simplify the design dramatically. It may seem a bit open at first with excess whitespace, but as soon as you interact with Tag Builder, you’ll notice that the whitespace gives way to hover help text that no longer requires a click just to get the basic concept of each fieldset.

Tag Builder and the grid

3. Language

Because the previous Tag Builder required this additional click to access any help, the field labels ended up being sentence like in places and overly descriptive. This created a wordy design that left the user with a lack of confidence and uncertainty as it required more comprehension even for basic fields. The new labels are short and conversational in tone. This is easier to comprehend and it leads to a more confident user. For instance, a certain label read, “Single first-party cookie (use one first-party cookie across the primary and each subdomain: Cookie domain attribute.” In the new interface it now reads, “The site domain you want to track,” followed by the entry field. When the user hovers over the field, hover help appears and provides the user with an opportunity to confirm their assumptions as well as providing a link if the user wishes to explore the topic in depth. In addition to improving the readability of the labels and hover help, we also improved the error messaging for improperly filled out fields. The language short, concise, and straight to the point.

4. Indicator Dots

One of the most troublesome design challenges we faced with the new Tag Builder was how to clearly communicate completed fields when only one tab was visible at a time. We solved this challenge with a unique solution that we named, “indicator dots.” We noticed in the prototyping tests that users would click through the tabs a few times just as a driver in a car trying to make a left hand turn onto a busy street swings their head back and forth. With the indicator dots, now they at least knew which tabs that had completed some information in. This challenge grew as we realized that there was no clear way to message the user if they had improperly filled out a field on one tab when clicking the “Build Tag” button. So, we also leveraged the indicator dots to turn red when there is a field error on a tab. In the end, the indicator dots communicate to the user three things; how many choices are there on a tab, how many were filled out, and which fields contain errors when submitting the form.

Indicator dots

5. Confirmation

A related challenge to the indicator dots was the lack of any confirmation before the user clicked the “Build Tag” submit button. The previous version of Tag Builder directly triggered the “download” function of the browser when this was clicked. This worked ok in Internet Explorer but in Firefox and Safari, the download function didn’t allow the user to name the file. We realized we needed a confirmation page that condensed the information related to that particular tag setup on one screen paired with the option to name the zip package.

Confirmation page

Summary

We made many additional improvements with Tag Builder and I hope if you are a user, you have noticed an improved workflow. In the next article, I’ll walk through the changes we made regarding the web standards architecture.

I’d love to hear your feedback (thoughts, comments, questions, or critiques) on this new design direction.

*When I set out to write this five part series, I didn’t intend for it to be as drawn out. A new baby and product design improvements beyond Tag Builder are keeping me quite busy.

One of the most complex reports we have available in Webtrends is the scenario analysis report.  It’s also one of our most robust, and can provide you with worlds of good information to help you optimize scenarios on your site.  But I’ve found that a lot of people aren’t exactly sure what the report tells them.  They see the information, but they don’t understand what insights are being given. 

That’s what this series of blog posts is about: demystifying the scenario analysis report and making it work for you.

Let’s start by talking about a concept that’s bandied about a lot when talking about conversions:  abandonment.  In a lot of conversion funnels, abandonment equates to visits that did not “funnel through” to the following step in the scenario.  Not so with our scenario analysis reports; we focus, instead, on fall-out.

Here’s a sample scenario analysis report (click on it for a clear image):

At first glance you may think that this scenario has a 73.51% abandonment rate on step one, since that’s the first percentage to appear on the right.  On this, you’re right, but it’s not quite what it seems. Here’s what that number tells you:  Of the 38,232 visits to the “Product Page View” step in this scenario, 28,264 (or 73.51% of) visits did not on to the next step, but also did not entirely abandon your site.

From there, we get more detail on what happened with those 28,264 visits:

• · 619 (2.19% of the 28,264) visits did actually abandon the site entirely. The product page view was the end of their visit, hence the “End of Visit” label.
• · However, a full 27,645 (28,264 – 619) did not leave your site. Instead, they went elsewhere on your site. In the case of the first number (27,082, or 95.82% of the 28,264), they went to the Video Recorders page. How do I know this? I hover my mouse over the little blue name, and voila!

So, only 619 people from step one actually abandoned your site altogether; the others got distracted and did something else on your site, so they’re not completely gone yet.

How do I know what they did?  Well, if they went elsewhere on your site, this view of the scenario analysis will tell you, and will provide you with truly actionable information.  Here, for example, I see that the vast majority of people leaving my scenario on the very first step are looking for video recorders, so why not promote those video recorders on your home page?  Or maybe you could set up a bundle:  your most popular products with a video recorder at a reduced cost.  Upsell! 

Now, let’s shift to the Step Transitions view.  I do this by clicking the “View Step Transitions” button above the report (again, click for clarity):

This view provides us with completely different information.  Instead of telling you whether a visit ended or continued someplace other than the scenario, this process shows you two things:

• · The number of visits in which the visitor did not continue directly on to the next step, yet remained within the scenario process as a whole, and
• · Where that visit went when it left that step.

So, let’s look at what the numbers on this first step tell us here:  6,733 visits did not convert to the “Cart Add” step.  However, they still interacted with the scenario:  6,731 (99.97% of the 6,733) viewed another product page (so, they were still shopping), and 2 (.03%) actually started checkout (which probably means they’d already added something to their cart and decided not to buy what was on the last product page they viewed).

So, we can say that, of the 28,264 visits that did not convert from step one to step two, 6,733 did not leave the scenario entirely.  Instead, they either skipped a step or stayed on the same step; they didn’t abandon.  That’s almost a quarter of the visits that didn’t convert to step two – and that’s a great opportunity to ensure that, now that they’re in the scenario, they stay there.  Note, for example, that 317 visits went back to the “Product Page View” after they started checkout.  Is that a result of your efforts to offer them similar items or accessories on your checkout page?  Or, if you’re not making such offerings, could you increase that number by doing so?

Of course, these opportunities may seem fairly obvious; after all, we’ve been tracking shopping carts for a long time on the web.  But imagine tracking your three-step application/registration process, or your five-step “Give me more information” process, and you can see how this information becomes useful quickly.  You might be able to reduce the number of steps and increase conversions, or note where people are getting distracted and provide them, within your scenario, the information they need to stay on track.  That’s so much more helpful than just tracking abandonment, isn’t it?

I’ll discuss the left side of this report in an upcoming post – stay tuned.

With the recent release of Tag Builder 3.0, the User Experience initiative has been made visible.  In the previous article*, I introduced the new Tag Builder with a brief overview.  In this article, I will walkthrough the user centered design approach that grounded the new design, Paper Prototyping.

There is a good chance that if you hang around me for more than an hour or so, you’ll hear me sneak Paper Prototyping into the conversation. If it were a religion, I would be one of its most devout members.  For those of you that aren’t familiar with this usability design methodology, it is defined by Carolyn Snyder in her 2003 book on the subject as ,”Paper prototyping is a variation of usability testing where representative users perform realistic tasks by interacting with a paper version of the interface that is manipulated by a person ‘playing computer,’ who doesn’t explain how the interface is intended to work.”  This might not seem so revolutionary on the surface, just one of many usability exercise/methodology options that a designer has in their toolbox.  However, when you break down the fundamentals of Paper Prototyping into its core tenets, the power of its simplicity becomes more apparent.

Paper Prototyping hardware

1. Define the Problem
As Einstein once said, ““If I had an hour to save the world I would spend 59 minutes defining the problem and one minute finding solutions.”  With Paper Prototyping, you begin by creating scenarios.  These scenarios are tasks from a user perspective that need to be completed.  An example scenario from TagBuilder was, “Ryan does a lot of testing with his site and uses the subdomains testing.acmetoys.com and staging.acmetoys.com. He wants to make sure that these subdomains do not contaminate the data for the main www.acmetoys.com website.”  We started with about 50 of these scenarios and ended up with about 20 grouped by four different user types.  What is great about this exercise is that you can include others outside your development team to help define these tasks.  This includes support, services, and even customers themselves.  Again, this isn’t defining features, this is defining the tasks that a certain type of user is trying to accomplish.

List of tasks (or scenarios)

2. Collaborate
Designing and developing software is not a naturally collaborative process.  Each contributor usually has their own computer designed for one individual.  Sure there are technologies like chat, wikis, and shared source control, but these tools help add collaboration to an individual environment.  With Paper Prototyping, you gather the same team that is tasked to build the application into a room to create the prototype.  This includes the project manager, the developer, the designer, the tester, the writer, etc.  The goal is to go through the tasks and design the solutions on paper.  No computers.  Just paper.  Additional tools are scissors, sticky notes, markers, removable tape, and removable glue sticks.  This is the original cut and paste.  As you design the paper version of the application as a team (all should be working with marker and paper in hand), each team member must bring their constraints with them.  That way, if the designer slaps a button down on a certain screen, and the developer realizes the implication of that button being there implies that they must do a massive restructure of the backend to allow the functionality that that button implies, the developer can speak up and offer an alternative to solve the task another way.  By bringing these constraints forward, the team avoids most situations where one team rejects a design late in the process due to a time and resource issue.  With Tag Builder, we completed the new design in one week with a six member cross departmental team.

The Paper Prototype

3. User Testing
When the design is ready by solving all of the tasks in the scenario list, it is good practice to user testing with each other by taking turns playing the user.  You’ll find by putting on the mindset of the user, you’ll find quirks and issues with the design you just couldn’t see when you were in design mode.  When the team is confident they have a good prototype, it is time to bring in outside users for testing.  You can also take the prototypes with you and take the tests to where the users are.  I once tested a website designed for professional truckers and conducted the testing for that project at a truck stop.  The nice thing about paper prototyping is that users seem to have a good time during the tests.  One reason is that it is paper.  Instead of sitting a user down in front of a computer where it can feel like you are testing their computer skills, you sit them down in front of a paper sketch of an interface.  Immediately this puts the users at ease and they are quite relaxed.  Their finger becomes the mouse and scraps and a pen becomes their keyboard.  Paper Prototyping also works best when you test with two users at a time. You ask them to work as one user and to agree on any action before taking it.  This allows you and the team facilitating the test to hear the dialogue between the users as they try to accomplish the task.  This avoids the problem of interrupting the user and breaking their natural flow to constantly ask them why they did this or that after the fact.  When the first test is done, the team regroups and tries to solve any problems the users ran into during the test before the next test starts.  This allows you to iterate between tests.  I usually try to allow for an hour to an hour and a half.  With Tag Builder, we tested with five groups of two people.  By the last test, the users had no challenges with the interface on any of the tasks.

Screen grab from a Paper Prototyping session

By starting off our process with Paper Prototyping, it allowed the Tag Builder team to start with a shared, collaborative design experience and to iterate the design of the application many times before we sat down in front of our computers.  The process doesn’t catch everything and a few concerns or issues have been brought up with the new design since it launched.  We are aware of these and will adjust the design/flow to correct them in upcoming releases.  However, the new design is a reflection of not only our own design sensibilities but also a direct response to the usability issues that surfaced during our design process with actual users.  We also ran a series of Paper Prototyping sessions at the Engage conference April 7th and 8th on a different and much more ambitious product. We appreciate all who participated and their feedback is influencing our design in a profound way.

If you are interested in learning more about Paper Prototyping,
the book is a great place to start or you could attend the workshop that I am conducting at WebVisions May 20th in Portland, Oregon.

Paper Prototyping Workshop at WebVisions May 20th

In the next article, I will walk through the specific design changes with the new Tag Builder and what they mean for the future of Webtrends user experience.

* Between the first article and this article, my wife and I had a new baby boy and so the frequency of updates to this series was thrown for a loop. The rest of the series should be published much more frequently.

Microsoft Office SharePoint Server 2007 (MOSS) is a great platform for an organization that needs to roll out an intranet with very little effort because MOSS offers an easy way to organize content based on a company’s organization model.

However, what many companies found was while it was easy to implement the website, trying to get accurate analytics on a MOSS portal was difficult, if not impossible.  Log file analytics yielded inaccurate results and advanced JavaScript tracking was nearly impossible for most organizations due to the complexity of the SharePoint code.  If your organization did not have a C# programmer with SharePoint Portal experience, you were out of luck.

After hearing this concern again and again, we decided there had to be a better way and we were going to find it. The current analytics experience was difficult and frustrating – this was unacceptable.  With this goal in mind, my colleague Michael Love and I researched the issue and came up with a simple solution: directly interact with the SharePoint Portal template structure.  The data is already there on the page; let’s use it.  Just as the Webtrends SmartSource Data Collector code pulls data like refers automatically, this altered code allows us to pull details about the portal experience automatically from the SharePoint templates.

So exactly how much development is required?  This is the best part; the effort involved in implementing the code is minimal.  No C# coding required.  No major template modifications are required.  Your developers should be able to apply the code and get you up and running in minutes.  Webtrends will provide you with the code you need to apply to MOSS 2007 to make this work.  Webtrends will do the rest.  We’ll set up the reporting and help you test the data output.

How rich is the data?  Using this methodology we can collect data on Content Areas, overall site traffic based on a Breadcrumb drilldown report, document tracking, Webpart views, onsite search results (including found vs. not found) and all of the standard reports you expect out of Webtrends Analytics.

The document reporting is probably my favorite functionality.  We can build a report that will track document interaction within a document library including check-outs, downloads, emails directly from SharePoint and a number of other options.  The best part is you get you pick the standard document interactions you want to track.  User level reporting is also available.  If you have an external list of departments that users belong to, we can create a report that will allow you to see activity based on departments.

How do I get it? If you are interested in this offering – touch base with your account manager for implementation details and pricing.

This is just the first step.  Webtrends is serious about getting you the data you need and giving you direct access to you.  Many of you saw our press release about integrating with WebSphere Portal.  The integration will be equally easy, giving step by step guidance on how to track your WebSphere Portal with minimal effort.

It’s time to make things easy!

Microsoft Office SharePoint Server 2007 (MOSS) is a great platform for an organization that needs to roll out an intranet with very little effort because MOSS offers an easy way to organize content based on a company’s organization model.

However, what many companies found was while it was easy to implement the website, trying to get accurate analytics on a MOSS portal was difficult, if not impossible.  Log file analytics yielded inaccurate results and advanced JavaScript tracking was nearly impossible for most organizations due to the complexity of the SharePoint code.  If your organization did not have a C# programmer with SharePoint Portal experience, you were out of luck.

After hearing this concern again and again, we decided there had to be a better way and we were going to find it. The current analytics experience was difficult and frustrating – this was unacceptable.  With this goal in mind, my colleague Michael Love and I researched the issue and came up with a simple solution: directly interact with the SharePoint Portal template structure.  The data is already there on the page; let’s use it.  Just as the Webtrends SmartSource Data Collector code pulls data like refers automatically, this altered code allows us to pull details about the portal experience automatically from the SharePoint templates.

So exactly how much development is required?  This is the best part; the effort involved in implementing the code is minimal.  No C# coding required.  No major template modifications are required.  Your developers should be able to apply the code and get you up and running in minutes.  Webtrends will provide you with the code you need to apply to MOSS 2007 to make this work.  Webtrends will do the rest.  We’ll set up the reporting and help you test the data output.

How rich is the data?  Using this methodology we can collect data on Content Areas, overall site traffic based on a Breadcrumb drilldown report, document tracking, Webpart views, onsite search results (including found vs. not found) and all of the standard reports you expect out of Webtrends Analytics.

The document reporting is probably my favorite functionality.  We can build a report that will track document interaction within a document library including check-outs, downloads, emails directly from SharePoint and a number of other options.  The best part is you get you pick the standard document interactions you want to track.  User level reporting is also available.  If you have an external list of departments that users belong to, we can create a report that will allow you to see activity based on departments.

How do I get it? If you are interested in this offering – touch base with your account manager for implementation details and pricing.

This is just the first step.  Webtrends is serious about getting you the data you need and giving you direct access to you.  Many of you saw our press release about integrating with WebSphere Portal.  The integration will be equally easy, giving step by step guidance on how to track your WebSphere Portal with minimal effort.

It’s time to make things easy!

Microsoft Office SharePoint Server 2007 (MOSS) is a great platform for an organization that needs to roll out an intranet with very little effort because MOSS offers an easy way to organize content based on a company’s organization model.

However, what many companies found was while it was easy to implement the website, trying to get accurate analytics on a MOSS portal was difficult, if not impossible.  Log file analytics yielded inaccurate results and advanced JavaScript tracking was nearly impossible for most organizations due to the complexity of the SharePoint code.  If your organization did not have a C# programmer with SharePoint Portal experience, you were out of luck.

After hearing this concern again and again, we decided there had to be a better way and we were going to find it. The current analytics experience was difficult and frustrating – this was unacceptable.  With this goal in mind, my colleague Michael Love and I researched the issue and came up with a simple solution: directly interact with the SharePoint Portal template structure.  The data is already there on the page; let’s use it.  Just as the Webtrends SmartSource Data Collector code pulls data like refers automatically, this altered code allows us to pull details about the portal experience automatically from the SharePoint templates.

So exactly how much development is required?  This is the best part; the effort involved in implementing the code is minimal.  No C# coding required.  No major template modifications are required.  Your developers should be able to apply the code and get you up and running in minutes.  Webtrends will provide you with the code you need to apply to MOSS 2007 to make this work.  Webtrends will do the rest.  We’ll set up the reporting and help you test the data output.

How rich is the data?  Using this methodology we can collect data on Content Areas, overall site traffic based on a Breadcrumb drilldown report, document tracking, Webpart views, onsite search results (including found vs. not found) and all of the standard reports you expect out of Webtrends Analytics.

The document reporting is probably my favorite functionality.  We can build a report that will track document interaction within a document library including check-outs, downloads, emails directly from SharePoint and a number of other options.  The best part is you get you pick the standard document interactions you want to track.  User level reporting is also available.  If you have an external list of departments that users belong to, we can create a report that will allow you to see activity based on departments.

How do I get it? If you are interested in this offering – touch base with your account manager for implementation details and pricing.

This is just the first step.  Webtrends is serious about getting you the data you need and giving you direct access to you.  Many of you saw our press release about integrating with WebSphere Portal.  The integration will be equally easy, giving step by step guidance on how to track your WebSphere Portal with minimal effort.

It’s time to make things easy!