Design Thinking and API Design

An Experimental API Strategy from the Capital One DevExchange

An important part of the Capital One DevExchange strategy has been a commitment to giving devs early access to what we’re working on. From invite-only APIs to beta APIs we’re firm believers that early access equals early feedback equals stronger and better APIs. Building on this train of thought, we’d like to introduce a new type of API to our repertoire –the Experimental API.

What Are Experimental APIs?

Experimental APIs are mock services that use simulated data to mimic API functions. They are designed with the goal of getting early feedback from the community around API desirability and design before the product release. Some defining features of an experimental API are:

• A mock service that does not use real data.
• Additional features and capabilities are expected to be added based on feedback.

These APIs are intended to be nimble and iterative in nature. They allow us to have conversations with the community about the future of banking products and to build APIs based on those conversations. With these APIs, we’re extending a more intimate relationship to developers and potential partners with two specific benefits:

• The ability to provide early feedback and help influence the product before it is released.
• The ability to get ahead of development by testing potential integrations without the need to sign contracts.

How Does This Strategy Align with Design Thinking Principles?

Design thinking is a practice in product development that centers the needs of users in the products you’re trying to build. How do the steps of Design Thinking align with the development lifecycle of our new Experimental APIs?

• Discovery — Experimental APIs begin their lifecycle in a multi-disciplinary brainstorming session. These sessions focus on mapping user needs to business objectives. Through discussing needs, problems, and perspectives surrounding a category of tech or financial issue, we can focus in on potentially underserved areas.
• Define — After these perspectives are collected, we refine our discoveries to pinpoint a specific user need that can be solved for via an API. We then form a problem statement based upon our understanding of the users’ needs.
• Ideate — In the ideate stage, solutions to this problem statement are explored to determine how best to design the API.
• Prototype — In this stage, the experimental API is built as a lightweight prototype that can be expanded in small, iterative versions based on user feedback. It’s placed on the DevExchange portal and made available for the next step in the process.
• Test — We introduce the prototype — now officially an Experimental API — to users via a variety of conversation-intensive measures such as hackathons, code days, empathy interviews, and surveys. This allows us to collect feedback and fold it back into the product. We can then make informed decisions on next steps; including necessary pivots, small changes and optimizations, and recommendations.

Design thinking allows us to work through a series of “flaring” and “focusing”, making tighter and tighter iterations as we move from “What could be”to “What should be.”By using developer and partner feedback to guide these iterations, we’re collaboratively identifying the features, functionalities, and documentation needed for the final product. Our goal is to use these principles to help reduce the timeline to market for our APIs, as well as to more precisely pinpoint their value.

Putting This Strategy into Practice

To date, we’ve released two experimental APIs — Money Movement and Virtual Card Numbers.

Money Movement

Released in March, the Money Movement experimental API allows potential integration partners to simulate the ability to transfer money between Capital One accounts, and between Capital One accounts and those held at other financial institutions. In the current iteration, the experimental API can retrieve a list of eligible accounts, request transfers, retrieve transfer information, and update transfer requests.

An experimental API is an API in the discovery phase. Banks already have the ability to move money from Point A to B. Money Movement is designed to give consumers and partners the ability to do the same. By releasing this as an experimental API, we’re hoping to better define the opportunities to serve the space. What functionalities would different types of partners like to see? What features would best serve their users and use cases? How could this be paired with our existing Bank Account StarterAPI?

The Money Movement team discusses their experimental API with participants at our Seattle Hackathon

Debuted at our Seattle hackathon in March, this API has gone through two rounds of feedback from developers building with its current set of capabilities. While the roadmap for future iterations is still being developed, the feedback received so far will definitely be folded into it.

“In my product management world, we love to geek out about Lean Startup techniques. That book preaches a method of building lightweight, small iterations to get customer validation. The experimental API is a flavor of that mindset.” — Dan Kovach, Product Manager, Money Movement

Want to contribute feedback on Money Movement? Check out the product page and click on the Feedback tab to let us know what you think.

Virtual Card Numbers

Released in April, the Virtual Card Numbers experimental API allows potential integration partners to simulate the ability to request virtual card numbers for customers with a Capital One credit card. In the current iteration, the experimental API can create a mock virtual card number for new customers, replace a card number on-file with a virtual card number for existing customers, retrieve additional information about the virtual card number, and report status changes on stored or deleted virtual card numbers back to Capital One.

Tokenization and virtual cards represent an important new tool in securing customer financial information while avoiding consumer payment disruptions. In March, Capital One launched virtual card numbers with Eno– our intelligent assistant app. This experimental API is a foray into extending those capabilities to additional use cases beyond Eno and associated Capital One digital properties. By partnering with merchants and payment providers via this experimental API, we hope to protect customer card numbers in a wider variety of online purchasing experiences.

*Merchant Benefit: Cards reissuance — whether due to loss, theft, or account compromise — can cause declined payment transactions and friction in web or mobile shopping experiences. This API is designed to eliminate such disruptions to the payment process, helping merchants realize increased payment authorization rates.

*Customer Benefit: The potential customer benefits of the Virtual Card Numbers API are twofold:

• The API helps safely store customer credit card information online by using merchant-specific virtual numbers instead of physical card numbers for online purchases.
• If a new 16 digit physical card is issued due to fraud or theft, the customer won’t have to manually update their information with individual merchants because their virtual numbers won’t have been compromised.

Want to contribute feedback on Virtual Card Numbers? Check out the product page and click on the Feedback tab to let us know what you think.

Why We Believe This Strategy Matters

“Building an experimental API was described as the perfect combination of a low resource, low risk way to gather feedback and market validation for our idea. It was exactly what our team was looking for.” — Dan Kovach, Product Manager, Money Movement API

Since our founding in 2016, Capital One DevExchange has been committed to helping internal teams refine, build, and externalize their APIs; as well as helping external devs and integration partners access the products they’ve built. In that time period, we’ve put a lot of thought into how APIs are designed as products, built as software, and made available to potential users.

An experimental API is both an early preview into what we’re building and a direct line into the product and tech teams building it. It’s a chance for developers and potential partners to have their voices heard as we make changes and additions to an early stage API product. By building in a way that maximizes for an efficient development cycle, we hope to identify value and build out capabilities in a way that gets the best products out in the quickest way possible.

Related

• What Hosting Hackathons Taught Us About Our APIs
• Developer Engagement: Braving the Wilds
• The Role of Product Management in API Design
• Developing a Great API Requires Great Technical Writing

DISCLOSURE STATEMENT: These opinions are those of the author. Unless noted otherwise in this post, Capital One is not affiliated with, nor is it endorsed by, any of the companies mentioned. All trademarks and other intellectual property used or displayed are the ownership of their respective owners. This article is © Capital One 2018.