Web Apps: Where Business Needs and User Needs Collide

Thanks to Marco Dini for the Italian translation to this article.

Right now, in a far off cubicle, someone is designing an e-commerce checkout application. It’s not unusual. There are thousands of existing e-commerce sites with their own checkout applications. And I can bet in the future there will be thousands more.

A checkout application usually has the following elements:

1. A shopping cart displaying the products to purchase
2. A request for shipping information
3. A request for billing information
4. A request for the payment instrument information
5. A confirmation before executing the transaction
6. A receipt after executing the transaction

That’s it. Six easy steps to executing a purchase—that’s all there is to a checkout application. If it’s always that simple, why do we have to continually design new ones? Why can’t someone just make an off-the-shelf checkout application that we can plug into any e-commerce site?

We Are All Individuals. Just Like Everyone Else.

Off-the-shelf won’t work for a simple reason: every e-commerce business is unique. While the steps will likely be the same, the devil is in the details. More accurately, the devil is in the specific business rules and the customer needs.

Businesses must be unique, even if they are in the same industry, selling similar products. Let me restate that: especially when selling similar products in the same industry. The uniqueness of the business helps customers choose where to buy. Do they want the low cost provider? Or are they the best at delivering service, even at a higher price?

What makes a business unique bleeds into their checkout application. It happens at every step:

• Does the business offer special “buy two, get one free” deals? If so, the shopping cart needs to support that.
• Does the business offer gift delivery options, such as including a nice card? If so, you need to add that to the shipping information.
• Does the business offer corporate accounts? That’ll affect the billing information screen.
• Does the business accept pre-paid gift cards? That’ll influence the payment instrument functionality.
• Does the business schedule delivery and installation times? That may need to show up on the confirmation page.
• Does the business offer digital downloads for some products? You’ll need to have a follow-up page, after the transaction, to tell them how to get their purchase.

These are just a few examples. Organizational initiatives, such as product upsells, loyalty programs, repeat customer accounts, saved payment information, purchase-order handling, supply-chain management, and lead generation all work their way into the application. A team might start with an off-the-shelf application, but the customizations would quickly outnumber the original features.

The rules, policies, and practices of the business have a strong influence on any web-based application. The best designers seek out these business requirements and create a solution that makes the requirements seem natural. Most important, they balance the business requirements against the users’ needs.

Preventing A Business Takeover of the Experience

It’s not news that airlines are looking for new ways to increase their revenues. As expected, these creative moneymaking opportunities are seeping into their own web-based applications.

Like most other airlines, United Airlines’ passengers can check in to their flights using a web application on the airline’s site. In this application, the folks of United have inserted several upsell opportunities.

One of these is their Award Accelerator. United’s loyalty program members can spend a little more money to earn additional miles, thus getting closer to the program’s benefit of free flights.

In our research, many customers found this addition to be a nice benefit, stating that they could imagine using it at some point. However, many of those customers were frustrated by the feature’s design.

The site automatically defaults the choice to making the purchase and only presents a single button on the page: “Add option”. If the passenger wants to pass on the program, they have to either change the setting to “None” or press a small-type, non-underlined link labeled “Skip and continue”.

Passengers checking in told us they felt United was trying to trick them into purchasing something they didn’t want at that moment. The design choices the team made left a bad taste in the mouth of their customers.

It’s possible United isn’t trying to trick customers into purchasing. It could easily be the result of a strict adherence to style guidelines, such as “Accept is always a button while Cancel/Decline is always a link.” However, it’s clear to us that their customers see this as deceptive.

The best design teams work hard to ensure they are balancing the users needs alongside the business needs, to prevent this type of customer reaction—a feeling that the business is projecting its agenda ahead of what the users want.

Designing Around Business Constraints

Like United Airlines, Best Buy also needs a design that accommodates its business. However, unlike United’s designers, the designers at Best Buy turned a complex business constraint into a pleasant user experience.

Some products on Best Buy and other retailers’ sites require the shopper to put the product into their shopping cart to reveal the price. Shoppers, encountering this anomalous behavior, often complain that the retailer is trying to “trick” them into making an accidental purchase and resent the requirement.

Yet it’s not a trick of the retailer to get people to accidentally buy a $2,000 refrigerator—it’s a contractual decision put into place by the manufacturers to comply with fair trade rules—an agreement called Minimum Advertised Pricing (MAP). Large retailers get better prices, because they can purchase in larger volumes. To give the smaller stores a chance, the big guys won’t publish their prices on the site where search crawlers can find them. Instead, they agree to only reveal the price when it shows up in the cart.

The rule states the product needs to be in the cart before displaying the price. But the rule doesn’t say how it’s displayed.

Best Buy’s design team came up with a clever solution. When the user clicks, they display a dialog showing the item and its price. Behind the scenes, the system has officially added the product to the cart, but the user is unaware. They only see two buttons, one that says they are checking the price and the other that says they want to buy. Pressing the former automatically removes it from the cart, while the latter keeps it there.

The resulting design avoids the feeling of trickery that other MAP implementations leave, while complying with the retailer’s business constraints. This kind of clever design approach makes web applications both challenging and fun.