The checkout prototypes are meant to provide a means of evaluating the interface & interaction design patterns that are presented in the previous chapter. However, a checkout process is not comprised of merely these elements.
Other basic functionality needs to be present to allow the task of correctly ordering the desired product(s) to be completed successfully. This also requires taking specific details like the delivery address into account. Such functional requirements are listed in the first sub section below. It also includes two optional requirements that are included in more advances checkout processes such as the bol.com checkout process: the ability to use coupons and gift wrap options.
In addition to these functional requirements there are some technical constraints to be taken into account. They provide guidance for the technologies that can be used and the limitations that are imposed on the prototypes. These constraints are listed in the last sub section.
4.1. Functional Requirements
This section provides a short overview of the functional requirements for an e-commerce checkout. It is based on the requirements given by bol.com for a basic new customer checkout and thus only includes the most basic requirements.
The cart must present the main product details
The main product details that must be presented to the customer per product are: - title;
- author/brand;
- specific item details depending on the category (format, specs, etc.); - price;
- current amount;
- total price (price x current amount).
The cart must allow the user to edit items in the cart
In addition to displaying the product details, it must be possible for the customer to change the cart details such as:
- product amount;
- move product to wish list; - remove from cart;
- product is a gift: yes/no (optional requirement); - undo cart removal (optional requirement).
The cart must present all relevant and total costs
In addition to the item costs, shipping costs and any discounts (if applicable) must be displayed. The total costs for the order (calculated by the aforementioned costs and discounts) must also be presented as accurately as possible to the customer, on the cart page.
The checkout must allow (new) users to enter their billing and shipping details
Billing and shipping details are required for placing an order. New customers will always need to enter such details, existing customers might be able to log in and use existing address information or add a new address. Given that this research focuses on new customers, there must be a way for them to enter their:
- shipping address, consisting of: title, first name, middle name (optional), last name, company name (optional), country, postcode (for NL), house number (for NL) and house number suffix (optional for NL);
- billing address (same details as shipping address); - phone number;
- email address.
Furthermore, the customer must be able to create an account. Based on the guidelines (e.g. 45b in appendix B), making it optional to create an account is preferable over forcing the user to create one. It is believed to decrease task completion (and increase checkout abandonment) when this is forced upon users. Customers wonder e.g. “Why am I forced to register when I am merely ordering a book, a regular brick-and-mortar shop does not require this.”
Making it optional prevents this problem. However, there is an alternative approach possible: have the server generate the password and email it to the customer. It has similar benefits, but it might make repeat orders more easy. On the other hand, it might also feel forced when it is created automatically, it takes away some of the user control. Given these considerations, it is listed as a pattern alternative in the previous chapter.
Furthermore, an interesting insight can be gained from [69]. By still forcing account creation, but removing the actual words “account”, they were able to reduce their checkout abandonment rate by 50% (according to the article). Given the high relevance, it is mentioned here, but it should be noted that this article was not available yet at the time this research was carried out. Therefore it is not further explored here.
The checkout must allow registered users to order without reentering any data
The prototypes should provide at least the entrance for registered users, because this could affect the overall experience of the prototypes. Given that this research only focuses on new users an actual implementation that allows existing users to place an order is not part of the prototypes.
The checkout must allow customers to pick a payment method and provide the relevant payment details for that method
The checkout must support the same payment methods as the current bol.com checkout provides to Dutch customers:
- iDEAL (the most popular Dutch online bank payment service); - credit card;
- giro card (where customers receive in an invoice they can pay within 14 days).
The iDEAL option must allow customers to select their bank so that they can be transferred to the bank environment where the transaction will be presented to them. The credit card option must allow customers to enter their credit card number, expiry date (month and year) and the cards security code (CVC or CID). The final option of giro card currently requires bol.com customers to enter their bank account number.
Optional: The checkout should allow customers to use coupons and gift cards
Bol.com uses coupon code and gift cards as promotional tool. Although not a completely basic requirement, a good comparison should allow the coupon codes or gift card codes to be entered. This is also required for evaluating one of the patterns from chapter 3.1.
Optional: The checkout should allow customers to make use of the gift wrap service
Similar to the coupons requirement, this allows for a better comparison and is required for evaluating a pattern from chapter 3.1.
When it is included, three options should be provided (which apply to the whole order): - No gift wrap for all items;
- red wrapping paper for all items (€ 0,45 per order); - blue wrapping paper for all items (€ 0,45 per order).
4.2. Technical Constraints
The common browser aspects that bol.com takes into account will also be taken into account in this research. However, it should also be noted that only prototypes will be built. These do not include the optimizations that would be present in an actual implementation, because of time constraints and different priorities. Therefore, computer and connection speeds will not be taken into account, given that no techniques will be used that have potentially high CPU utilization, etc. (e.g. Adobe Flash). The same goes for cross-browser compatibility. Functioning in at least one browser is sufficient for user testing. The aspect that should be taken into account is display resolutions. Bol.com is designed for displays with a resolution of 1024 x 600px, or a browser viewport of at least 980 x 500px.