Archive

Posts Tagged ‘conversion funnel’

Sell More on Your Website by Understanding a Bit About Entropy

October 19, 2011 3 comments

If you listened to Monday’s podcast, you know that I’m on a bit of a kick about entropy. It has to do with this book I’m reading called The Information, by James Gleick. The book is a history of information and the rise of information theory. Really good stuff. And he spends a good bit of time going on about entropy.

Now, entropy is a bit of a scary word. It has a kind of intrinsic feel to it, like we have some intuitive sense of what it means but when it comes to spitting out a specific definition, we all turn into karaoke performers trying to sight read Snow’s song “Informer”.

Hello? 1992 called. They want their metaphor back.

Entropy, simply, is a measure of the unavailability of work inside a closed system.

At least that was its original definition. It was first purposed by Rudolf Clausius and described a specific quality of thermodynamics.

Energy as Information

James Clerk Maxwell was the first to link this quality to the idea of information.  See, he looked at it as order and disorder. Order and disorder imply knowledge. To make order you must know something about the thing you are ordering. In his mind, it involved a little demon who controlled a very tiny door between two rooms. In one room were fast moving molecules. In the other room were slow moving molecules. And he decided what molecules got through the door. While he was sitting at the door he could choose to mix the molecules or keep them separate. But, because of the laws of thermodynamics, if he were to just open the door, after a period of time of fast molecules bumping into small molecules, every molecule would more or less be moving at the same speed*.

Makes a great Halloween costume.

With the help of Maxwell’s Demon, entropy was now linked to information.

The second law of thermodynamics says that entropy is always increasing. This means that without intervention, everything moves from order to disorder. Or to put that another way, from specific to general.

If you’ve ever been to a business meeting, you’ve seen this before: Interesting, dynamic ideas often get presented at the start of a meeting and boring, mediocre ones often end them.  Sweet, sweet car designs are presented at automobile shows and then the same boring sedans are cranked out year after year. Windows XP was supplanted by Windows Vista.

Entropy is everywhere.

A case can be made that what made Steve Jobs great was his ability to fight entropy in the extreme. Before him, computers were for governments, science and business. Because of him we can talk to our phone using natural language and it can respond to our information needs.  For sure, he didn’t do this alone and in a vacuum.  But it’s hard to deny that he brought information to the masses in a way that had never been seen or experienced before.

He gave people the tools to be able to manipulate information – to create order out of disorder. He created the technological environment that we are now living in.  Would there be an Android without an iPhone?  Would Windows 7 be half the OS it is now without having to compete with OSX?

Dig a little deeper into social behavior and two themes for how people deal with entropy begin to emerge.

People’s Relationship to Entropy

  1. They want to create order from disorder
  2. Not all the time

Now let’s run those two rules through a “customer” filter and see what happens.

Customer’s Relationship to Entropy

  1. People have a finite amount of energy to spend in a day
  2. As a result, people want to conserve their energy
  3. People want to expend energy on activities of their choice
  4. People do not want to spend their energy unnecessarily

And like that we’re out of thermodynamics and into the world of web design.

Common Sense Stuff

What a customer is saying is: I’ll buy your product or service if I like it and the price but I’m not going to spend a lot of energy to do it.

Now we can state the goal of web design in scientific terms:

The goal of web design is to produce a website with low entropy.

That is to say, a web design is successful when it makes it easy for a person to do what they want to with as little effort as possible.

And this can be measured.  Right now.  In fact, you may already be measuring it.

Entropy and Efficiency

Look at the number of visitors to your site.  Look at the number of sales.  Now, do that for the past six months, or year, or two years and get an average number of visits to sales.  Whatever that percentage is, that’s how well your website has worked over that period of time.

Let’s say, for the sake of argument that you have 100 visitors to your website each month, on average, for the past year. And in that time, on average, you had 2 sales each month.  Simple math will tell you that your website has a 2% conversion rate.  That is to say, it is two-percent efficient.

The goal of user testing is to discover changes that can be made that will increase the number of sales on your website, given the same number of visitors.

If user testing is conducted and changes are made to the website in the above example and over the next several months the website averaged 4 sales per month, the website would have doubled its efficiency from 2% to 4%.

Efficiency is directly related to entropy. Entropy, remember is about order and disorder. The more order we bring to the website, the less energy the visitor has to expend to buy the product or service and the more efficient it is.

The reason we should talk as designers about entropy rather than efficiency is because efficiency is a by-product of entropy, not the other way around. Entropy is by its nature probabilistic.  The more knowledge you have about the pages of your website, the more effect you have can on reducing entropy – you become like Maxwell’s demon deciding which molecules to let through the door.

Practically Speaking

Every page on your website that somebody can find via search or a link is a potential entry point. Likewise, every page is a click away from being an exit point. It’s all very messy and random.

The job of web designers, programmers, interface designers, and SEO people do is give shape to those pages.

SEO is responsible for managing the website’s relationship with search engines. Another way to think about it is that they are responsible for getting traffic to the website. In a closed system, an SEO guy wouldn’t be necessary. But our website itself exists in the larger eco-system of the Internet and so messaging extends beyond your website. SEO, because of its connection to traffic, is the first person to set expectations for your website’s visitors.

Designers and programmers work to bring shape to the website. E-commerce sites have catalog pages, product description pages, a cart, and a checkout process – and they show up in that order.

Information sites like Google, YouTube, and Wikipedia are designed so that information can be easily found and accessed.

From disorder emerges order.

On this website we’ve spent a good bit of time talking about defining a website’s critical path. We believe that user testing should revolve around improving the efficiency of that path.  It’s important to remember that it’s a literal path. It is about energy flow.

Entropy, for a website, can be defined as the likelihood that a visitor to a website will NOT complete the critical path.

Fighting entropy on a website means giving form to and then reducing the resistance of the critical path.

This is why a conversion funnel is such a valuable web analytics tool.  It shows entry and exit points with respect to the critical path.  It points out to you places where user testing could reduce entropy.

On Friday, we’re going to take a look at the third-rail of web design: pricing.

Nothing introduces entropy into a website quite like pricing.  Money is really a physical manifestation of a person’s energy.  They know that they have to expend a certain amount of energy to accumulate money.  Money, like energy, is also finite for most people. Thus, pricing is directly related energy, and thus, entropy.

We’re going to take a look at some pricing strategies that can reduce entropy and increase the odds that your site’s visitors will respond positively to your price point.

#####

* I saw more or less because it’s not practical for the average person to know the behavior of every molecule. So what has risen in its place are laws of probability. That is to say, while a closed system tends towards maximum entropy, at the molecular level, there will be exceptions to this rule. Extremely unlikely events, however unlikely, still happen. But at the macro level, these probabilities are so low as to be practically non-existent.

Why Programmers Should Learn Web Usability (Cuz You Suck at Your Job If You Don’t)

October 14, 2011 Leave a comment

Oh Shopp plugin, how I loathe thee.

You make the checkout process an absolute sonuvabitch for both designers and the website’s eventual users.

But let me start at the beginning.

WordPress, as a CMS touts its ease of use and its extensibility. The general feeling is that WordPress makes it easy for anybody to make a website but it’s also powerful enough to satisfy real code monkeys. It can do this because of two things: themes and plugins. Themes govern the look and feel of the website and plugins extend the functionality of the website.

For example, the name of the theme of this particular website is iNove. It’s a default theme that comes with a wordpress.com account. It governs how the pages are laid out, how they look, and to some degree how they function. If we so chose, we could use a bunch of plugins to allow us to extend how the site works. We could install a Google Analytics plugin or a plugin that creates XML sitemaps, or that makes contact forms easily, or that keeps our comments spam-free.

We don’t need to know the code behind any of that. Instead we install a plugin and that plugin does the work for us. It’s not exactly magic, but for people who turn a puke-ish yellow-green at the sight of code, it might as well be.

Enter the Shopp plugin.

The Shopp plugin is an e-commerce plugin for WordPress. It came recommended to me by another designer.

Most carts – WordPress or not – look horrendous out of the box. I don’t know that anybody has ever been impressed with OSCommerce or WP e-Commerce after a fresh install. You might hear an ‘ooh’ but it’s actually spelled ‘eww’. Even with a heavyweight like Magento Commerce it’s daunting to create something impressive without dedicating yourself to getting over a learning curve.

I have a big problem with this. The job of an e-commerce solution is to provide a flexible platform by which to sell things. This part, vendors will argue, is what they do and I would agree with them. But I believe it’s also the job of the vendor to put usability best practices into use when creating their product.

When somebody buys a car, they have a chance to sit in it… to take it for a test drive and there’s an understanding that they are tested for performance and safety. Nobody would seriously look at a car today if it were manufactured without seat belts and air bags and think that was okay. It would be derided for its deficiencies.

Now imagine that a new car comes out with all of the familiar bits but they’re all in different places… The steering wheel can slide from right to left. It can detach and be used in the backseat. There’s a brake pedal and a gas pedal but the gas pedal is right next to the input for the gas tank. There are headlights but the whole thing looks rushed. You could swear that they’re just balled up lines of Christmas lights. Oh, and the hood doesn’t open but GOOD NEWS! The dashboard comes out.

Would you accept that? Would you think, “Just look at it! It’s everything you’d find in a car! Ooh, leather seats!”? Of course not. You’d be too busy wondering which village had lost their idiot.

The point of an e-commerce solution isn’t just to provide a platform to sell things, it’s to BE GOOD AT SELLING THINGS.

It’s at this point most programmers I know would raise their hand and say that they don’t know the first thing about web usability and that rather than learn it, they did one better and made their program flexible enough for designers to do whatever they want.

Okay. I’ll let you make that argument but only if you promise to leave it in the year 2005 where you found it and you don’t say that nonsense in front of Jakob Nielsen who has been writing on this topic since the days you used to watch the Power Rangers after school.

I’m saying that’s an immature point of view… get it?

The great promise of the Web 2.0 was the communal web. It was largely enabled because technology – XML and CSS – enabled us to separate content from design at the code level. And I’m not arguing against this separation.  It makes sense on a technical level because it was already happening at the human level.  It’s no surprise that websites were/are largely built by two people: the designer and the coder.  Breaking a website into content and design was perfect for both personalities.

The coder got to make sure the machine functioned as it was intended to. That is to say that if the website sold things, as is the case for an e-commerce developer, all of the steps involved in the purchase process worked. The programmer eschewed all design choices, claiming that it’s not his responsibility. His job was to make the machine work and by-God it did that. If you want to talk about why more people aren’t buying your product, you need to find the designer or the marketer or somebody whose job encompassed that responsibility.

The graphic designer meanwhile would be off satisfying the artistic whims of the client.

This is an important point.

In this duo, the graphic designer is guaranteed to have more direct contact with the client than the programmer.  Programmers, as a stereotype, are dirty, stinky, (oftentimes bearded), and always anti-social.

Graphic designers as a stereotype are all skipping work today to be one of the first to get their fashionably grubby mits on the iPhone 4S.

In practice it means that the programmers decide what they want to build and defend it to the death. Because they rarely talk to the client they are divorced in a meaningful way from satisfying the client. The quality of the code both in how its written and in how functions is left to the programmer and whoever can influence them. While this may sound backwards: employees do what the boss says or the employee gets fired, it’s not that easy when the employee is the lynchpin of a key part of the company’s product.

My point is this: programmers are known for being difficult and for defending their own interests above all else. As a group (sorry outliers) they tend to be detail oriented and myopic to their discipline. These are great traits for programming but are a hindrance when it comes to being proficient in non-programming but related fields of study.

The designer has a different problem. A designer is responsible for creating a look for the website that the client likes. All of the trouble in that last sentence lies at the end of it “that the client likes”. This is a problem because when it comes to web design WE CAN ASSUME THAT THE CLIENT DOES NOT KNOW WHAT THEY ARE TALKING ABOUT unless proven otherwise.

Why would any non-web business owner have the first clue about how a checkout should work? The simple answer is that they wouldn’t and that they don’t. It’s not their job. Not only do they not know how the checkout process should work but they don’t even know that it’s one of the most crucial aspects of an e-commerce solution.

It’s like that old quote from Donald Rumsfeld. “…as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns — the ones we don’t know we don’t know.”

When it comes to building a website – especially when it’s a ‘easy to use platform’ like WordPress, it’s safe to assume that your users are not knowledgeable about what they’re doing and thus these people are full of unknown unknowns.

Users, for the most part, don’t use WordPress like a new, shiny tool that helps them do their tasks quicker and easier. They use it like a crutch: to allow them to do things they couldn’t do on their own. Why? Because they know that their ignorance means there are tons of unknown unknowns out there.

When somebody hires a web dev firm or uses a CMS they are relying on somebody else’s expertise to accomplish a task. The problem is, both the graphic designer and the programmer have sworn off being responsible for the efficacy of the website, putting the responsibility squarely on the back of the client. “If only you had told us you wanted it like that we would have built it for you.” they’d say. And that’s a cop-out of the highest order. They’re telling you “it’s not my problem”. They’re also telling you that you’re not valued as a client.

There are at least three tiers of responsibility. They are:

  1. Programmers
  2. Graphic designers
  3. The client

If you’re using WordPress, as in the case of the Shopp plugin, that list looks very similar but appropriates the WordPress conventions:

  1. Plugins
  2. Themes
  3. The webmaster

When a website doesn’t perform up to standards, the first person on the hook is the programmer. Whether custom designed or designed as a plugin, the structural nature of the website is defined through the code.

Say Whaa?

Let’s look at an example from the Shopp plugin.

The checkout process for websites has coalesced over the years into something approaching a standard. And if the word standard is too strong for you then it’s at least been distilled into a number of best practices.

Among those best practices are obvious things like:

  1. Provide a step/progress indicator throughout the entire checkout process
  2. Provide shipping and tax cost sooner, rather than later, and
  3. Retain customers’ previously entered information

What’s going on here with these best practices is that they are reducing the friction of the checkout process.

Take Me Down to the Circuit City

Remember the electronics retailer Circuit City? Somebody made the awesome design decision at their stores to make it hard to find a manned register. The registers in their stores were often located in non-obvious places throughout their store and they were notoriously undermanned.  Ninety-nine percent of the time customers would wander up to the customer service counter to checkout. It was so unintuitive that Circuit City went out of business.  Sure, you could check out there… if you could find a register and an employee who wanted to take your money but it wasn’t easy. There was too much friction involved.

It’s the same way with websites. If the friction is too high, people will go elsewhere. That’s why Amazon came up with the 1-click checkout and then PATENTED IT. They sued Barnes & Noble for using a similar process and forced B&N to move to a 2-click checkout process.  It’s why users of Apple’s App Store can install an app in 2-clicks. It’s why there’s such a big push into NFC and Bluetooth payment mechanisms for phones. The whole game is to make it as easy as possible for people to buy what they want. It’s frictionless buying! Hooray!

Except that it’s not because the guys behind the Shopp Plugin don’t know the first thing about these best practices.  Or if they do, they go out of their way to ignore them.

In a typical checkout process, the steps are as follows:

  1. Cart
  2. Shipping
  3. Billing
  4. Review
  5. Receipt

The two most important steps are the shipping and billing pages.  Shipping comes before billing because the desire for the product comes before the desire to pay for the product.  So the first bit is to find out where the product is going and who it’s going to.

Then, after the user has done that, it’s appropriate to ask for billing information.  And, to keep things simple, there should be a way to copy the shipping info over to the billing information so the user doesn’t have to enter the same information twice.  Remember, it’s all about reducing friction.

Now, let’s see how Shopp does it.

In the Shopp universe, billing comes before shipping.

We know this because Shopp provides a bunch of hooks for designers to use when designing their site.  As stated above, we want to have the user enter shipping information first and then billing information. And if the shipping and billing information are the same, the user should easily be able to copy the shipping info into the billing info.

You cannot do this with the Shopp plugin without learning how to code it yourself. You cannot design your way out of this corner, it is the fault of the program.

See, Shopp has a hook called same-shipping-address. It’s job is to copy the billing info into the shipping info – the exact opposite of what we want to happen.

And this wouldn’t be too bad if they had also included a hook called ‘same-billing-address’ but they don’t. This leaves me two possibilities: I can learn how to code this behavior myself or I can leave it how Shopp wants it. This, simply, is unacceptable from a modern plug-in. It’s also a detail that’s likely to be missed by all but the UX obsessed.

This is the root of the issue.  Programmers are responsible for crafting a working product.  Their job is more complicated than learning a WAMP, LAMP, or MAMP environment.  Their job is to make tools that work. As part of that process they should also know WHY their programs behave the way they do. Anything less is mere translation.

The job of a graphic designer is to bring clarity and aesthetic appeal to a website. The job of a programmer/plugin is to deliver the best working machine possible.

To go back to the car anology, the programmers are responsible for how the car works and the designers are responsible for how the car looks.  If the programmer puts the gas pedal next to the input for the gas tank, all the designer can do is make it look pretty.

To look at it through the WordPress process, think of it this way: Themes can’t do anything that WordPress or its plugins can’t do (unless they are custom designed to make up for their deficiencies).  Therefore the primary responsibility for how a website should function falls first to a programmer, and then to a designer, and finally it falls to the client.

Even after nearly 2,400 words on the topic so far in the blog post this will seem like a counter-intuitive statement. It sounds like graphic designers are getting off easy. But that is not the case. Graphic designers are also responsible for the user experience. It’s just that their involvement happens at Step 2 and the programmers happen at Step 1.  It’s the difference between designing a car to have air conditioning and deciding where in the car the interface buttons should be placed.

If there’s no a/c, then there’s no need for the buttons. But just because there are buttons doesn’t mean that punching one will make it colder because that all depends on whether or not the car also has an air conditioner.

When you’re somebody like me – a jack of all trades but not highly specialized in any one thing – it feels like a last mile problem. When we use these tools: WordPress and plugins built for WordPress, they are supposed to be ways of shortcutting to a solution for a digital problem. In the case of WordPress, I don’t need to know how to program in order to write this blog. I can just sign up and start typing. And for this website, that’s largely what Newman and I did.

But when it comes to more complex issues like an e-commerce cart, we have to rely on the expertise of the plugin builders to deliver the functionality we need.

When that functionality is missing or difficult to implement it frustrates users and makes them use less successful methods that increase friction in the checkout process and overall lower sales.  In the case of the Shopp plugin, I would say that easily 25-50% of the sites I’ve seen punt on the checkout process so hard that they just send their users to PayPal to complete their transaction.

Let me say that again: Up to half of the site’s I’ve seen that use the Shopp plugin find it so hard to use that they send their customers to PayPal’s website to complete their transaction.

How can any e-commerce cart claim to even be competent when this is the case? They’re just building a digital version of Circuity City – all products with minimal attention paid to checking out.

They have plans to release version 1.2 soon. From what I have seen, none of these usability issues have been addressed.

You’ve been warned.

Questions:

  1. Have you ever seen a good e-commerce solution that paid attention to the user experience right out of the box?
  2. Is it fair to make programmers responsible for a significant portion of the web ux?
  3. Is there a minimal level of understanding that a business owner needs to have before getting a website? How does somebody with no expertise know how to find somebody who knows how to look out for the best interests from a web ux point-of-view?

Cut the Chute and Get on the Critical Path (to Profit)

September 28, 2011 4 comments

If you’ve been following the website or podcasts over the past few weeks you’ve seen Newman and I dig into the topic of web usability. We approached it, at first, from a philosophical perspective.  We talked about the web design process and where web usability fits into it.  We found various tools online to assist in doing user tests and we’ve found various models for how to conduct user tests.

And we started to realize something: these models tend to be obnoxiously vague.  Even when they make intuitive sense, they still leave the reader with more questions than answers.

I feel like they keep creating iterations of the old Sony business model:

Step 1: Bright idea
Step 2: ????
Step 3: Profit!

 


It’s Mr. Sony and he’s a naughty kitty!

WTF is Step 2? Nobody I’ve read (and I’ll readily admit that I have much more to read) has articulated a quality strategy for conducting a user test. And all the user test examples I’ve seen have bared this out.

What I’ve noticed is that somebody will develop a model.  For example:

I actually like this model. I think it does a good job of describing the steps and grouping the various considerations into each step. But what drives me crazy about it is that it doesn’t compel me to do anything specific. This is a 25,000 foot view of the web ux universe. And as you’ll see, it’s practically the only view these models will present:

Same thing with this model, except in this model, they’re using words and phrases I’m familiar with but use them in ways that are not intuitive and meaningful.

You can look at those two models or even the one we were initially so high on in Monday’s podcast at usability.gov until blood shoots out of your nose and you’ll never get to a better understanding of how to conduct a user test.

What we need to do is cut the chute.

We’re sailing along at 25,000 feet looking at our surroundings. If we were really sky diving we’d see a number of geological formations beneath us: flatland, rivers, mountains, and so on. That’s what’s amazing about being that high up – it’s possible to see how the mountains are connected to the rivers. You see how the rivers feed and nourish the surrounding area because the surrounding area is lush with vegetation and various critters. Finally you see that river find its delta where it meets the ocean. It’s a point-of-view that’s hard to visualize from ground-level.

What it doesn’t do is tell you why there are mountains and rivers; why life crops up around those rivers, or most importantly for this analogy: how to terraform.

This analogy, like life, revolves around water. In this case, a river.

There’s an idea that we’ve previously covered called the critical path.

This idea, for the uninitiated, is extremely simple.

Pictured: A critical path.

A critical path is the path a user must take through your website in order to complete the website’s primary goal.

Visualize it in its most common form: an e-commerce cart. The critical path looks something like this:

FRONT PAGE –> CATEGORY PAGE –> PRODUCT DESCRIPTION PAGE –> CART –> CHECKOUT –> RECEIPT

Now, obviously, it’s not necessary for somebody to start at the front page of a web site to buy something. Furthermore, this might not be the only way that a person could navigate the site that would result in a purchase. But what we just described is a from-the-rooter-to-the-tooter critical path. It’s got a little bit of everything.

If we look at this critical path more closely we can really divide it into two smaller sections based on what the pages do.

When a person buys something, they always go through this process:

Step 1: Find a product to buy
Step 2: Buy the product

Similarly, a website’s critical path can be divided into two sections: pages that help the user find a product and pages that help the user to buy.

I like to think of the pages that fit in Step 1 as FILTERS and the pages that fit in Step 2 as CONFIRMERS.

Let’s look at that critical path again:

Filters: FRONT PAGE –> CATEGORY PAGE –> (SUB-CATEGORY PAGE) –>

Confirmers: PRODUCT DESCRIPTION PAGE –> CART –> CHECKOUT –> RECEIPT

The Front Page, Category Page, (and sub-category pages if necessary) are all filters. Their purpose is to direct traffic to the Product Description page.

The Product Description page is really the beginning of the checkout process. Done right it will either sell the product using pictures, text, and multimedia; or it will confirm the shopper’s good sense to buy that particular product.

From the moment the shopper adds the product to the cart, the only job your website has is to get them into and through the checkout. This part of your website is so important that web analytics packages like Google Analytics include a tool that specifically measures this part of the process. It’s commonly known as a Conversion Funnel or Goal Conversion Funnel.

It looks like this:

Pictured: That part of Google Analytics that you’ve been meaning to mess with.

The action in a conversion funnel is centered around the sales process – as it should be – because we want shoppers to buy the stuff they put in their cart.

But what about those FILTER pages? Where’s their visualization tool?

Web Usability folks have the tools to do the job but they’re rarely considered as tools to measure the effectiveness of how a user filters the information on your site. The tools are the click-maps that visualize where users click on a page. If one has the resources to do an eye-tracking test, then the heat-maps are just as valid a tool but they track the user’s eyes instead of their mouse. It’s the same underlying principal that’s been taken to another level of granularity.

 

Pictured: Granularity

What does this mean for designing a web usability test?

To me, it means that we’re out of the clouds where we talk about the three tiers of goals

Tier 1: Business and User Goals
Tier 2: Site Goals
Tier 3: Page Goals

and into a place where we connect Tier 1 to Tier 3. Once you see it, it’s so obvious it’s hard to imagine that you hadn’t seen it before.

The way you do it is by drawing a path from Step 1/Tier 1 (Goals) to Step 3/Tier 3 (Profit). Because it’s such an important path, one might even call it a critical path.

So you see, now we have the ability to design a user test because now we know the goal of user testing.

 

The goal of usability testing is to determine the effectiveness of your website’s critical path.

 

This makes all the sense in the world. The website is a machine built specifically to achieve an objective. User testing needs to be focused around measuring how well the machine achieves the objective.

Now, knowing that, how does that translate into actually designing a web usability test?

Newman will have to speak to that. Fortunately that’s what he’s preparing for Friday.

On Friday, Newman is going to break down for you the basics of creating a user test and how designing a user test around the critical path forces radical deviations from the standard questions that are often found on web usability tests. It’s sure to cause some controversy because for some jacked up reason it seems to fly in the face of conventional wisdom.

 

3 Questions For You

 

1. What web ux tests have you done and what was its primary goal?
2. Have you ever done a web ux test where evaluating the efficiency of the site’s critical path?
3. Can there be valuable non-critical paths in a website?