In today’s digital-first world, customers expect to be able to interact and transact with a brand digitally. Expectations are ever-changing and brands must figure out how to remain relevant or risk becoming obsolete in customers’ minds. Although there are a variety of distinct types of online customers, there is one thing they all have in common: the overall lack of time and willingness to endure experiences that do not immediately meet their needs. No one has time for a bad experience.
As Bridget van Kranlingen, Senior Vice President of IBM Global Markets, has said: “The last best experience that anyone has anywhere becomes the minimum expectation for the experience they want everywhere.”
But what makes for a bad experience? Honestly today, it does not take much. Our expectations have been set by the likes of Apple, Netflix, and Uber, and many other superior experiences in the market today. One too many screens in a mobile checkout flow could be all it takes for a customer to begin buying products somewhere else. A bad experience for the customer equals bad business. It is not like any brand sets out to build or create a bad mobile/web experience on purpose. The problems can often stem from somewhere below the surface of the mobile/web application. If everything on the surface that is needed to ensure a positive experience is there, there is a problem enabling the experience. Enablement is one of the main responsibilities of client-facing APIs. If API consumers — the mobile developers in this case, but also pretty much all the stakeholders in any business — are not enabled to produce the mobile experience as desired, the end customer experience will often fall short of expectations. Digital product owners and developers need the APIs to support the overall end customer experience — and not just any APIs. Let us talk about Experience APIs.
The Experience API Difference
At a surface level, an Experience API will look like any other API. The technology employed, specification format used and the presentation in general will all be familiar to any seasoned developer. Instead, an Experience API is a philosophy. It is a philosophy that calls for APIs to be intentionally designed with a focus on the experience a developer or stakeholder will have when using them. Converting a SOAP API to REST or migrating to session-less authentication are both notable examples of things that make API consumers (again, referring to developers in this instance) happy. However, those examples are merely table stakes for an API powering a customer-facing experience. The experience flavor of API should not exist by happenstance nor because some tool generated it as a, simple, project formality. Experience APIs should be carefully designed to ensure support of the customer experience which only happens by making the API a priority and not just another thing to be done. From a technical perspective, the API should be responsive (150–300ms response times are a respectable goal) and the request/response schemas should be tailored for maximum intuitiveness. From a hierarchical perspective, an Experience API will reside at the top of the API stack. It should be considered the tip of the spear in an organization’s API attack plan on customer experience friendly APIs.
Compound Effects of Experience APIs
An API that works is not enough, at least not for an Experience API. It must work the way developers need or want it to work. Developers should not have to perform miracles when it comes to making API calls just to represent a complete entity that an average customer would understand. For example, a product in a customer’s mind is not split between product information in a PIM (Product Information Management) system, image assets in a CMS (Content Management System) or metadata from some key-value store. The product is the whole enchilada, visuals included. Developers will have a much more enjoyable experience integrating an API into a customer experience if they do not have to make multiple API calls for every single resource. If a developer is finding their experience consuming an API to be delightful, they will have an easier time mapping design concepts to API resources. Experience Design (XD) can come to fruition a lot quicker if a developer knows what they need and where to find it. A well-designed Experience API will foster trust with developers and allow them to speak with their own level of confidence about what is/is not possible to downstream stakeholders. As much as an API is a representation of underlying entities, a mobile or web experience is a representation of the underlying API. In general, an Experience API should be designed with simplicity, consistency, and ease of use in mind. Furthermore, and more importantly, Experience APIs should be designed to support the client’s workflows. This can be achieved more consistently by designing an API early in the project, a process known as API Design-First.
The Road to Experience APIs with API Design-First
The API Design-First process is simple from a theoretical perspective. Briefly, the process simply calls for the API design process to happen before implementation of the respective API. It is easy to talk about designing an API first, but oftentimes hard to do in practice. Committing to the API Design-First process can be challenging for some teams because it requires ongoing communication between developers and stakeholders to ensure the best API is built for the job. This is especially challenging for teams that are not used to communicating with stakeholders outside their development silos. Stakeholders can include anybody that has a personal stake in the success of the overall experience; however, it will usually include the following roles: customer (internal and end-user), design, and platform developer. Out of the roles mentioned specifically, API developers should get comfortable communicating with designers as they are the people visualizing the experience imagined by/for customers and eventually, built by platform developers. In other words, an API that closely matches application design is more likely to make the customer happy because developers were enabled to do so. There is no definitive guide on the API Design-First process, but it can be broken down into two high-level project phases: design and implementation. These phases can further be broken down as such:
Design Phase
1. Discovery and Requirements Gathering
2. Assess Self-Understanding and Validate with Strategists and XD
3. API Design
4. Validate with XD and Stakeholders
5. Repeat steps 3 and 4 as necessary
Implementation Phase
1. Receive (Positive) Feedback on API Design
2. Implement
3. Validate
4. Design (design never ends)
5. Repeat steps 2–4 as necessary
Repeatedly getting validation is a direct sign of the constant dialogue that must be happening between the API implementation team and stakeholders. It is easy to scoff at this and consider it a waste of time, but the alternative result might be vastly different from what the customer is wanting. Take the time early to get buy-in from stakeholders before moving further down design and/or implementation paths with an inadequate product. Locking down on a solid API contract allows for the use of API mocking tools as well. Mocked APIs will allow front-end developers to be unchained from the back-end’s software development lifecycle (SDLC). Give your client-facing APIs priority, make it one of the first things worked on, and keep an open dialogue with stakeholders. Do this and you are more likely to create something that customers will enjoy.
Experience APIs are Important…
With all the emphasis about APIs and the priority thereof, it’s important to remember that APIs are not the most important thing in a digital endeavor. Developers and stakeholders are clamoring for access to a business’ all-important data; It is what they seek to fill the screens of their respective experiences. Data is king; data is the most important thing. The argument can be made that the behaviors and functions APIs expose are of equal importance, but what an unsatisfactory feeling it would be to not see the results of your work — the data on the other side. This detour down data lane does not diminish the role of an API yet solidifies its rank amongst other priorities. Data needs its digital ambassador and that is the perfect role for an Experience API. Practitioners of the API Design-First process should take considerable pride in implementing Experience APIs as this could be the decision point between a long-standing customer or a customer lost. Customers see the data through the experience that has been crafted for them to see it in. The experience does not stop in the customer’s hand or on their desktop; experience carries down to the API. The API must embrace the challenge of representing and serving the data in a simpler manner, so that consumers can easily meld the data into the customer’s experience.
Moving Forward with Experience APIs in the Fold
Information is what customers and developers seek in the end. Experience APIs exist to expose this information in a way that is easier to understand and consume. The Experience API journey should be a concerted effort to ensure that the pathways between the customer and the business are straight-forward and pleasurable to navigate. Communication, like for many other things in life that are done as a team, is key to implementing an Experience API. There is no possible way a single person or siloed group will know what is best for the customer and what they need. Experience APIs may not be the only priority, but they should take their rightful place as one of the main priorities in the pathway to superior customer experiences.
