Beta — We’re reformatting our articles to work with the new site, but this is one hasn’t been done yet; it may contain formatting issues. No need to report this. We’re working on it.

Web Apps: Where Business Needs and User Needs Collide

by Jared M. Spool
on January 27, 2010

Editor’s note: Thanks to Marco Dini, you can now read this article in Italian.

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

    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

    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.

    United Airlines

    On, Mileage Plus members
    can purchase more points while using the site’s flight check-in

    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

    United Airlines

    The defaults are to make the purchase, with the only button labeled “Add option.”

    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

    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

    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.

    Best Buy

    Retailers, like, are prohibited from showing prices lower than the
    manufacturer’s recommended price.

    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.

    Best Buy created a special dialog to handle MAP’s pricing
    display rules.

    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.

    Share Your Thoughts with Us

    Have you bumped into business constraints in your web app designs? Have you come up with a creative way to work around them? We’d love to hear your experiences. Leave your thoughts at the UIE Brain Sparks Blog.

    About the Author

    Jared M. Spool is the founder of User Interface Engineering. He spends his time working with the research teams at the company and helps clients understand how to solve their design problems. You can follow Jared on Twitter at @jmspool.