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

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.

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.

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:

Programmers

Graphic designers

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:

Plugins

Themes

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:

Provide a step/progress indicator throughout the entire checkout process

Provide shipping and tax cost sooner, rather than later, and

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:

Cart

Shipping

Billing

Review

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:

Have you ever seen a good e-commerce solution that paid attention to the user experience right out of the box?

Is it fair to make programmers responsible for a significant portion of the web ux?

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?