Wednesday, September 16, 2020

Do you know how the stuff will be done for Checkout Customization on BigCommerce

 

It’s no surprise that the checkout page is where the magic happens on an ecommerce site. And as an ecommerce developer, you know that the requirements for the checkout design can vary widely from business to business.

At BigCommerce, we’ve put a lot of research behind our flagship checkout page, Optimized One-Page Checkout, and it’s designed to create a checkout experience that will streamline the purchase process and increase conversions for merchants across the platform. But we also recognize that there’s no one size fits all solution. Across verticals and business models, there’s a ton of variation in merchants’ design needs and the experience their shoppers expect when they proceed to checkout.

The ability to customize the appearance and functionality of the checkout page is essential, especially for developers who support enterprise businesses. Our philosophy is that merchants should be able to look to the Optimized One-Page Checkout as an example of best practices in checkout form design, but we also want to build as much openness into our checkout as possible to accommodate merchants with specific business needs who are able to take on the effort of advanced customization.

This guide will outline the breadth of checkout customization options on BigCommerce, from no-code or low-code customizations all the way to complex headless builds. We’ll begin with a technical overview of the BigCommerce checkout page and then walk through the spectrum of customization options available for the checkout page, from native settings to defining every pixel of the checkout.

Special Considerations

Let’s start by establishing the fact that customizing the checkout page is different than customizing other default templates in your theme. Although there are many good reasons for customizing the checkout page, the consequences of introducing bugs are significant. Anything that affects checkout page uptime is going to have a direct impact on a store’s sales.

Security is also a consideration. One of the big advantages of using a platform like BigCommerce is that PCI compliance is bundled into the core feature set when using the native checkout page. PCI refers to the Payment Card Industry Data Security Standard, and it governs the way companies who handle credit card information maintain a secure environment. PCI compliance reaches into many areas: infrastructure, engineering, even the practices of company employees. At BigCommerce, we go to great lengths to make sure our platform meets these security standards.

Some types of checkout customizations affect BigCommerce’s ability to assume the burden of PCI compliance and shift this responsibility to the party customizing the checkout. For example, an app that injects JavaScript into the checkout page or a headless checkout that’s hosted on an external server would be within PCI scope.

That being said, there are best practices you can follow to make sure that the custom code you apply to the checkout page is going to play nicely with the platform — today and across future updates. We’ll cover a few of those best practices in this blog post. Full guidelines on PCI compliance are out of the scope of this post, but you can read more on requirements here (Developer Portal).

Technical Overview

The Optimized One-page Checkout is a single page application whose purpose is to convert a Cart to an Order. The checkout application is made up of several layers:

  • Backend application

The Optimized One-page checkout consumes the same Storefront Checkout API and JS SDK that are available to external developers. The Storefront Checkout API surfaces the business logic of the backend ecommerce application — retrieving customer information, fetching available shipping methods, and calculating discounts and sales tax. The JS SDK is a wrapper library that provides methods for interacting with the Storefront Checkout API.

The process for converting a cart to an order follows this flow:

  1. A Cart object begins as a collection of product line items and a customer account ID. It becomes a Checkout object when it picks up additional data — a billing and shipping address — that provide enough context to calculate discounts, taxes, and shipping options.

Although there is quite a bit of flexibility in what you can customize on the checkout page, there’s one important thing to keep in mind. The application logic that backs the Checkout API has certain validations and rules in place around the checkout flow that will still need to be followed, even if you change the UI. For example, a Checkout object must always have an email address associated with it, and if the cart contains physical products, a shipping address.

In most cases, the flow for a custom checkout will still map to the customer experience outlined above, but there may be edge cases that require a different sequence. It’s possible to create a presentation layer in the UI that makes it seem as though you are bypassing required fields (for example, by masking the fields and filling them with dummy data), but you’ll need to handle that logic within your customizations to process orders successfully. Lastly, the checkout customizations detailed here do not allow you to change the underlying functionality of the checkout, for example, by integrating an unsupported payment method.

Available Customization Options

In this section, we’ll start with the lightest lift and talk about a few of the customization options that are built into the BigCommerce Control Panel. Then, we’ll talk about how you can customize the text that appears on the checkout page, and even translate it into another language. Finally, we’ll go over how to add custom styling and functionality to the checkout with CSS and JavaScript.

1. Checkout Form Fields.

BigCommerce natively supports the ability to define new fields on the checkout page address form as well as reordering fields. Custom fields will be visible to the shopper on the checkout page and the values the shopper fills in will be visible in the Order View section of the Control Panel. Custom address fields support a variety of input types: checkbox, text field, date picker, dropdown, number-only, and password.

Common uses for custom checkout form fields include things like collecting a customer’s account number or verifying a delivery preference. Because custom address fields do persist to the Order View screen, developers making advanced customizations can repurpose custom form fields to store data that needs to be carried over to the Order record.

2. Store Design Settings

Another native option for styling the checkout page is Store Design. The Store Design editor provides an interface for controlling settings like the checkout page’s header image, colors, and fonts. It’s always a good idea to check for a setting before hard-coding CSS, because it gives merchants more control over their design and ensures their choices persist through theme updates.

As a theme developer, you can control which Store Design settings are available for merchants to configure. Settings, along with their possible values, are defined in the theme’s schema.json file, and current selected values are stored in config.json, which can be referenced by custom Sass functions. For more on developing Store Design settings, visit our documentation.

3. Multi-language checkout.

Moving on to customizations that require light custom code, the text strings that display on the Optimized One-page Checkout page can be edited, or even translated into multiple languages.

The checkout page follows the same convention used by all Stencil templates to render text strings. The {{lang}} helper, custom to Stencil, pulls a text string’s value from a set of JSON files, based on the language setting detected in the shopper’s browser. A store can have multiple .json lang files, one for each language that a store supports.

To access the translation keys that are rendered on the checkout page, you’ll need to append a JSON object containing the checkout keys and their text string values to your store’s .json lang file(s). If English is the default language on your store but you wish to change the wording on some of the checkout fields, you would add the checkout JSON object to the en.json file; if your store supports English and French and you wish to show a French version of the checkout page to French-speaking shoppers, you would add the checkout JSON object to your fr.json file and translate the key values accordingly.

4. Custom CSS.

The Optimized One-page Checkout references the optimized-checkout.scss file for styling, and you can review our theme documentation for a list of CSS classes that are applied to checkout elements. It’s important to note that you don’t want to nest or alter the built in class names, because it can break compatibility with future checkout page updates. Beyond that, you have the ability to reference a custom stylesheet or add your own CSS rules to manipulate styles and layout.

5. Custom JavaScript.

BigCommerce supports checkout page script injection via the Script Manager, an interface for managing third party scripts. If you’re building an app and need to run custom JavaScript on the checkout or order confirmation page, to create a pop-up for example, you can also inject scripts programmatically using the Scripts API.

The accordion layout of the Optimized One-page checkout loads dynamically as the shopper proceeds through the steps, which is something you’ll want to consider to make sure that your JavaScript is executing at the right time. While you could poll the DOM using setInterval() to make sure the element you want to target has loaded, using Mutation Observer is a nice, clean alternative. Support for Mutation Observer is built into modern browsers, so there’s no need to bring in a dependency to use it.

As an example, let’s say we want to execute some JavaScript on the Billing Address step of the checkout process. We could do the following, which checks for an element with the ID #checkoutBillingAddress. (adapted from Ryan Morr’s blog post)

Mutation Observer listening for Billing Address step

Note: While our engineering team is mindful of keeping DOM elements and classes consistent, we cannot guarantee that element IDs will never change across future updates. The best practice for running custom scripts on the checkout page is to avoid interacting with the checkout code directly, and these instructions are provided as a consideration for developers who have weighed the risk.

Headless Checkout

Now that we’ve covered some of the standard customizations you might want to make to checkout, let’s get into the more advanced options. BigCommerce surfaces APIs that cover the full checkout process end-to-end, which means that you can build a fully custom checkout either on top of the native storefront, or on a remote platform.

First, let’s set a quick baseline for what we mean by “headless checkout.”

Headless means that the front-end presentation layer has been decoupled from the backend platform that powers it. Remember when we talked about the layers that make up the Optimized One-page checkout? When you’re building a headless checkout, you’re still leveraging the backend application logic that’s surfaced through the API, but you replace the frontend presentation layer — or “head” — with a UI that’s purpose-built to your design needs and technology preferences.

You have several options for building decoupled checkouts, and the right choice for the job will depend on the level of control that you need, your ability to take on advanced development and security compliance, and the domain on which you need to run the checkout. We’ll talk through those considerations below.

1. Checkout JS SDK.

The BigCommerce Checkout JS SDK is a wrapper library for the Storefront Checkout API, which is the same API that powers the native checkout page. You can use the Checkout SDK to call methods on the Storefront Checkout API to move the shopper through the purchase process.

The Checkout SDK is a tool for building a custom UI for the checkout page, on the BigCommerce store domain. Essentially, it allows you to build a checkout UI replacement on BigCommerce.

The frontend technology that you use to build your custom checkout page is entirely up to you — you could use React or Vue, or even vanilla JavaScript or jQuery. This gives you a great deal of freedom to build highly customized checkout experiences, including features like a local pickup or delivery step or other add-ons.

So how does the Checkout SDK relate to the concept of headless checkout? Checkout pages built with the SDK are considered headless because you’re replacing the native presentation layer with one that’s custom-built on another framework. The Checkout SDK can also provide a checkout solution for remote headless storefronts, if you redirect back to the BigCommerce domain for the checkout step. This can be a good option if you need a great deal of control over the checkout look-and-feel, but want to reduce the overhead of building a remote checkout completely from scratch.

2. Embedded Checkout.

Embedded Checkout is a version of the Optimized One-page checkout that can be iframed into an external website, like a CMS. Embedded checkout is a great solution for a remote headless storefront, because shoppers can complete their purchase in-context, without being redirected to a BigCommerce domain.

The advantage of Embedded Checkout is that it limits the PCI scope taken on by the developer. Because the checkout page is on the BigCommerce domain and isn’t modified by external code, BigCommerce PCI compliance can extend to the remote storefront’s checkout. That built-in security comes with a few trade offs when it comes to how much the checkout page can be customized. Some styling options are available, allowing you to customize things like colors and font sizes, but the ability to inject custom CSS or JavaScript is limited.

Today, embedded checkout is coupled to the BigCommerce for WordPress plugin, but soon we’ll be releasing documentation on using embedded checkout with a wider range of CMSs and external storefronts. Stay tuned!

3. Server-to-Server Checkout API.

The Server-to-Server (S2S) Checkout API allows developers to orchestrate a checkout on a remote server. This means that developers can leverage the BigCommerce backend business logic to convert a cart to an order, external to the BigCommerce storefront.

To understand how the S2S Checkout API contrasts with other headless checkout options, let’s compare it to the Checkout SDK and embedded checkout. The Checkout SDK allows you to have a high degree of control over presentation, but it must be used on the native storefront. Embedded checkout allows you to use the BigCommerce checkout on a remote storefront easily and securely, but it gives you less control over the checkout page presentation. The S2S Checkout API allows you to build your checkout on a remote storefront, and it gives you complete control over the presentation.

The S2S Checkout API provides maximum flexibility both in terms of presentation and context. You can use the S2S checkout API to build a checkout page on a remote storefront, mobile app, or other checkout experience, like a kiosk. Along with that flexibility comes a heavier development lift, and because you are building and hosting the form that will accept credit card information, responsibility for making sure the checkout is PCI compliant.

Conclusion

BigCommerce offers a wide range of options for customizing the checkout page — everything from settings that can be adjusted from within the control panel, to completely custom-built headless checkout pages. In this blog post, we’ve surveyed a number of those options, including:

  • Custom Address Form Fields
No matter which checkout customization option you choose, be sure to visit our Developer Portal for detailed documentation on the features mentioned here.

Wednesday, September 9, 2020

How To Develop Your Business’ Technology Roadmap

 Software development without a roadmap is akin to driving off a cliff — an undertaking that seriously jeopardizes your product’s life. Here’s how to develop a business technology roadmap that ensures your project safely reaches its final destination.

When people have an idea for a piece of software or an app, they tend to be pretty energized about getting it to market as quickly as possible. It’s exciting to create an app or piece of software no one’s ever imagined or built before. As software developers, we’re usually right there with them.

At some point, though, we need to sit down with clients and give them a sometimes sobering reality: software development without a business technology roadmap can be a lot like driving aimlessly from point A to point Z. Sure, you get to discover new worlds and experience unexpected adventures, but you also frequently get lost, spend more money, and can lose enthusiasm for the journey.

“Agile” And “Fast” Are Not The Same In Software Development #

Many people think an Agile approach to software development discards long-term planning. Perhaps it’s because we so often use the word “sprint” in conversation. In reality, all good software development must flow from a business technology roadmap, as it:

  • Provides context around the development team’s daily work.
  • Responds to shifts in, among other things, the competitive landscape.

So, what is a business technology roadmap, and how can one be developed to support software development? That’s what we’re here to talk about.

What Is A Business Technology Roadmap? #

Unlike detailed blueprints that lay out all tasks, deadlines, bug reports, and more along the way, technology roadmaps are high-level visual summaries highlighting a company’s vision or plans.

In an Agile approach, a technology roadmap feeds the sprint and grooming processes, providing insight into how the product will travel from start to finish. It makes it easier for development teams to:

  • Understand how the product will evolve.
  • Make near-term decisions that don’t compromise future work.
  • Gain awareness of which features are or aren’t working.

Companies can use technology roadmaps to review their internal IT, DevOps, infrastructure, architecture, software, internal system, and hardware procurement policies and procedures with innovation and efficiency in mind. The roadmap helps them define how a new IT tool, process, or technology supports their business strategy and growth and aligns projects with short and long-term goals.

There are hundreds of templates companies use for their tech roadmaps. A typical IT roadmap covers everything from requirements to testing and integrations. A dev team’s work dictates software or development roadmaps, highlighting tech initiatives, epics, and features while communicating the team’s primary goals.

For a typical client, a roadmap follows the following structure.

  • We created a list of all the features based on competition and wish list,
  • We narrowed that down based on what we wanted to be and what our beta users wanted,
  • We used that narrowed list to start technical planning and user stories,
  • As new features came up, we ran that through the roadmap to know if it fits in or how it should be prioritized,
  • We adjusted the roadmap if needed every 3-5 months.

    The Role A Technology Roadmap Plays In An Agile Approach

    In practice, a technology roadmap in Agile software development:

  • Facilitates planning activities by recognizing the journey is just as important as the destination. It forces teams to “come out of the weeds” and think more strategically.

    How this might play out: Your dev team suggests that the product needs built-in calling, meeting scheduling, and multi-layer reporting features. That forces you into planning activities like grooming meetings and getting outside feedback where you dissect each feature and come up with scenarios for setting them up. You might also discuss things like vendor selection for each feature. Conversations tend to follow an “or” pattern, as in “are we going to do this, or this, or that?”

  • Highlights key focus areas and works as a navigational tool to help the entire team succeed.

    How this might play out: Putting a spotlight on the areas the team needs to focus on forces you to decide who you want to be and what you want to become. Put another way, if you’re tailoring your product to a specific group, say inside sales reps, highlighting core features that matter to this narrower group of users helps eliminate tasks that might be used in other projects.

  • Works as a critical communication tool both within the teams and with other key stakeholders.

    How this might play out: As your project progresses and team members remind you about particular features stakeholders said they wanted, you can easily refer back to the roadmap to see if it was there in the first place. You can see where you chose to make certain development decisions, i.e., “we chose to be an inside sales rep tool,” and “we chose to be this or that.” This acts as sort of a forcing function, helping you revise the roadmap and rearrange the order and priority of tasks based on how they affect your schedule and deadline goals.

Different development companies and teams use different charts to construct their agile product roadmap, but they all tend to include:

  • A “longer-term strategic theme,” which points teams in a specific direction based on their assigned tasks.
  • A list of quarterly outcomes or objectives and key results (OKR) goals that each team will focus on to achieve the strategic theme. These goals basically answer the question, “what are the things we may build?” The answer lies in how you define success. Each team gives their best guesses as to how they’ll achieve each quarter’s goals.
  • Additional columns contain OKR goals, but with fewer and fewer “things we may build” listings. That’s because teams don’t know what they’ll be working on three or four quarters out so there are fewer best guesses. As the project moves forward and goes through testing, the boxes for the later quarters fill up.

More detailed software roadmaps cover milestones like player launch, product details like user profiles, UX/UI such as desktop icons and wireframes, and dev goals like press-to-play and performance enhancements.

Unlike traditional software development approaches, Agile focuses on the strategy, not the plan. That means outcomes, not outputs, are prioritized; tactical plans are left for backlogs. In a way, they’re designed to communicate uncertainty and provide transparency into what stops along the way are likely to remain as is and which might be in flux. For this reason, it’s crucial to update Agile roadmaps often as priorities shift and change.

How A Technology Roadmap Feeds The Agile Sprint And Grooming Processes

Sprints frequently go off track, which can have a negative effect on downstream operations. A technology roadmap helps teams run more successful sprints by setting a foundation and identifying how work should be organized so activities can be finished in a short time period.

  • A sprint goal refers to what can be delivered in the sprint.
  • A sprint backlog is the list of tasks to be completed during the sprint to achieve the goal.

To illustrate, let’s say you want to develop a new product feature. During the sprint planning meeting, team members need to “groom” the backlog and say which tasks they’ll work on. This is where many teams are led down the wrong path. They assume planning for the next two weeks is easy-peasy. They overlook or forget the work they’re planning must also satisfy the established goal.

A good backlog:

  • Lists each work item in order of importance.
  • Includes full-developed user stories the team can begin to execute on.
  • Has a current estimate for each work item.

Because it’s easy for teams to get bogged down in the details of a project, a technology roadmap helps them stay focused on high-level objectives and true customer needs.

The Role Of A Technology Roadmap In Digital Transformation

Today’s digital transformations focus on three key areas: customer experience, operational processes, and business models. Whether it’s for a small company or multi-national enterprise, a well-developed business technology roadmap helps companies reach short and long-term digital transformation goals by allowing them to:

  • Remain agile enough to accommodate course changes.
  • Build long-term value in the product.
  • Avoid roadblocks and other obstacles.
  • Because digital transformation is a relatively new concept, it’s often a journey filled with blind spots. What does it mean in terms of the scope and intensity of change? What will the repercussions be of pursuing and implementing it?

On the one hand, the digital transformation process is seen as using technologies to create new or modify existing business models. On the other hand, it’s about companies needing to embrace new cultures, structures, and processes that align with their IT architecture. One thing’s for sure: digital transformation is a fundamental change for any company.

A technology roadmap assists overall digital transformation goals by answering some key questions:

  • How is digital changing or poised to change the business and its industry?
  • What new offerings, operating models, and business models can it enable?
  • How is digital affecting the business’s competitive advantage? Where does the company remain well-positioned, and where is it disadvantaged?
  • Which digital opportunities are consistent with a company’s strategy based on value potential? In what order should the business pursue them?
  • What gaps in systems and capabilities need to be filled to succeed?
  • What are the targets, timelines, and accountabilities for individual projects and programs? What steps are needed to finance the journey?

Just about every business can benefit from developing their business technology roadmap as part of their digital transformation plan. New digital advances and the opportunity to improve traditional technologies to change customer relationships and employee experiences put businesses on a clear and rewarding path for turning technology into transformation.

Creating A Technology Roadmap To Drive Successful Innovation

Many businesses already have a technology roadmap. The question is whether that map is pointing to where they want to go, or has it only carried them to the present leg of the journey? Are they focused only on existing projects, or are they anticipating future breakthroughs?

The best technology roadmaps continually evolve, adding new destination points and aligning all resources and capabilities behind long-term goals. It’s not an easy process, but a methodical approach helps.

1. Identify Goals

Technology roadmaps must integrate long-term goals and visions. It’s often best to start at the end and work backward. For instance, in software development, milestones are often thought of as software releases or new versions of a project. But with a business roadmap, goals and initiatives also include things like hitting revenue targets or launching in a new region or market, basically anything that’s a significant result of combined efforts.

2. Seek Input From Stakeholders

For smaller businesses, this often means involving everyone. Including all pertinent stakeholders and decision-makers brings different views and priorities to the table and helps establish a clear direction for where the company’s headed. As collaboration is key to most business success, it also increases the chance of the roadmap being implemented. For specific projects, it weighs all pros and cons and ensures the new technology meets everyone’s particular needs.

3. Evaluate Current Systems And Chart A Course

All business technology roadmaps include negotiating a budget. Now’s the time to question previous decisions to see if they still align with the company’s vision. For example, a company has the goal of doubling customers, so assumes it must increase hardware capacity to meet it. That can cost significant sums of money. Another approach might be to make strategic changes to the software or combine current tools with custom software, typically a far less expensive strategy.

4. Be Open To Change

Clear vision and a revised budget in hand, it’s now possible to view the business landscape with a critical set of eyes looking. Perhaps a company previously developed a custom app because no existing product satisfied its needs — but now that software exists! The custom software could possibly be retired for the new software that will be supported by someone else.

That makes it possible to use in-house staff to develop new, potentially more profitable products. Sometimes bringing in an outside consultant to audit systems, processes, and teams help identify changes a business can make to support improvements and future initiatives.

5. Set Priorities

Up next is determining what’s critical, blocking, or simple. Items should be prioritized, and continuous feedback should be solicited from stakeholders. Project management tools can simplify the process and ensures items are linked to their dependencies and what needs to be done first is clear.

6. Build Out Timelines

Each task or initiative comes with its own level of effort. It’s critical to pull in the right technical people so to get an estimate around each effort. This should not be a long, drawn-out endeavor. Instead, it should be a quick activity that verifies how everyone’s on the same page. Often leadership has items it believes can be implemented quickly, but the team is of the mind it will take much longer to pull off.

7. Devise A Budget #

Once there’s a clear view of what can be worked on, when it can be worked on, and how long it might take to implement, there’s enough information to fashion a budget for each item. Each item’s details should be worked through fully to get an as accurate as possible estimate for what’s needed. Budget decisions can also affect how urgent or necessary an item truly is. Some businesses find they’re better off putting something on the back burner or investing in a service that solves the same problem.

8. Visualize The Roadmap

Finally! Project implementation planning can now begin. Each project should be laid out and overlaid with the resources needed for project delivery. If working in an Agile software development environment, there’s no need to write out every detail of every feature. Simply focus on high-level component delivery, marketing dates, and other top-level deadlines. While building out the software, Agile teams can pull in features on a different schedule, but they should always work towards the company’s high-level schedule.

Many businesses find that creating a steering committee or oversight committee helps to see if initiatives are following a steady path or are veering off-course. These committees can be helpful in that they’re not involved in the day-to-day delivery of a product like development teams are.

Doing What’s Best For The Journey And The Destination

Rushed software development projects don’t save time or money, and they often negatively affect quality — the greater a company’s rush to launch, the greater the risk. Before starting any software development project, a business should take the time needed to develop a technology roadmap.

Decades of experience have taught there is a lot of truth in the adage that “prior planning prevents poor performance.” Moving too fast can cause enormous problems for software development, dooming them to failure.

Creating a business technology roadmap gives enterprises the best of all worlds. It drives digital transformation while being agile enough to accommodate course changes. By the time the final destination or launch is reached, long-term value has been built into the product, roadblocks have been avoided, and other obstacles that often run other development projects into a ditch have been overcome.