Challenge Summary
Welcome to the "Banks API Marketplace - Developer Flow - Design Challenge". This is the first stage of a series of challenges where we are looking into designing and building a white-label product for an API marketplace solution that our client would like to offer for their financial institution clients like banks. The API marketplace would be used by the financial institutions (FI) to list their own APIs and third-party providers’ APIs as well for developers who will build applications, which will be offered to be used by the FI’s customers.
Read the challenge specification carefully and watch the forums for any questions or feedback concerning this challenge. Let us know if you have any questions in the challenge forum!
Challenge Objectives
Project Background
Our client offers IT and business process services worldwide for a large range of both leading and emerging businesses, among others for multinational banks. This time our client would like to build a white-label solution for these financial partners, which help them providing an API marketplace for their third-party API providers and developers.
With the fast growing in the number of APIs (hundreds within an organization) and their availability from different sources makes it harder for application developers to find, and use them.
Objectives of the Proposed Tool
The goal of this tool is
User Roles
The system has 5 types of users. In this challenge only one, the developer is in scope.
User Story
Donald is a developer, who works for a travel agency. They would like to develop an app for the agency that will be offered to download by our bank (the owner of the API marketplace) and it would help people to book holidays. This app would offer weather forecast, contacting the agency, payments etc. To be able to include all the functions, Donald will need APIs to handle everything the app needs. Initially, Jonathan, who is the IT manager of the travel agency creates an organization profile on the bank’s API marketplace. Then Donald also registers himself and adds the proposed application to the system. He browses the API marketplaces to find the most suitable ones, like a payment related API published by the bank itself, or APIs for messaging or acquiring weather forecast from external publishers. Once he finds the right APIs he can initiate subscribing to them. If he selects a payable plan, then he has to send a request to Jonathan to confirm the purchase.
Screen Requirements
For this challenge, we are providing wireframes for you to understand the flow. We would like you to design the following screens. Do not follow or copy the wireframes. It's just for reference. Please use your creativity to design the screens.
2. Marketplace
Branding Guidelines
Please consider the below guidelines during your design process:
Target Audience
Judging Criteria
Your submission will be judged on the following criteria:
Final Deliverables
Marvel Prototype
We need you to upload your screens to Marvelapp.
Submission & Source Files
Final Deliverables
For submission you have to upload a zip file that contains the following 4 files:
Read the challenge specification carefully and watch the forums for any questions or feedback concerning this challenge. Let us know if you have any questions in the challenge forum!
Challenge Objectives
- UI design for a responsive web app
- Understand the problem and come up with a great solution.
- Desktop screens of 1366px width.
Round 1
For Round 1 please provide at least the following screens along with hotspots on your prototype.- 01 Developer Dashboard
- 02 Marketplace
- 03.01 API Details
- 03.04 API Consumption
- 04.02 Subscription Pricing
Round 2
For Round 2 please provide all the following screens along with hotspots on your prototype.- 01 Developer Dashboard
- 02 Marketplace
- 03.01 API Details
- 03.02 API Documentation
- 03.03 API Documentation Details
- 03.04 API Consumption
- 04.01 0Subscription Details
- 04.02 Subscription Pricing
Project Background
Our client offers IT and business process services worldwide for a large range of both leading and emerging businesses, among others for multinational banks. This time our client would like to build a white-label solution for these financial partners, which help them providing an API marketplace for their third-party API providers and developers.
With the fast growing in the number of APIs (hundreds within an organization) and their availability from different sources makes it harder for application developers to find, and use them.
Objectives of the Proposed Tool
The goal of this tool is
- to provide a one-stop shop for available APIs,
- to help API providers to list their APIs, and make it possible for them to monetize them on a subscription basis
- to help developers search for, find and connect to APIs from the same place with ease along with monitoring their API consumption.
User Roles
The system has 5 types of users. In this challenge only one, the developer is in scope.
- Super Admin: Out of scope. Manages all user and organization permissions. Can see reports of all levels.
- Organization admin: Out of scope. Organizations are entities which are the employers of both the providers and the developers. The bank itself is an organization (internal) and the third party businesses are the external organizations. The Organization admin can manage the users within the organization, can manage the published and/or subscribed APIs, so as the applications they developed. He will be able to see the revenue statistics of the items.
- Provider: Out of scope. An API Provider will be able to upload his APIs to the marketplace, set the subscription term and start selling them. He will be able to see the revenue and consumption reports of only his APIs within the organization he belongs to.
- Developer: In scope. The developer will be able to search the marketplace for APIs and see the details of those. He will be able to subscribe to the APIs he’d like to use in his developed application(s). He will be able to list his applications on the marketplace for the customers to download.
- Customer: Out of scope. The customers will be the end users of the applications developed by the developers, using the APIs they subscribed for. They will be able to search for and download these applications.
User Story
Donald is a developer, who works for a travel agency. They would like to develop an app for the agency that will be offered to download by our bank (the owner of the API marketplace) and it would help people to book holidays. This app would offer weather forecast, contacting the agency, payments etc. To be able to include all the functions, Donald will need APIs to handle everything the app needs. Initially, Jonathan, who is the IT manager of the travel agency creates an organization profile on the bank’s API marketplace. Then Donald also registers himself and adds the proposed application to the system. He browses the API marketplaces to find the most suitable ones, like a payment related API published by the bank itself, or APIs for messaging or acquiring weather forecast from external publishers. Once he finds the right APIs he can initiate subscribing to them. If he selects a payable plan, then he has to send a request to Jonathan to confirm the purchase.
Screen Requirements
For this challenge, we are providing wireframes for you to understand the flow. We would like you to design the following screens. Do not follow or copy the wireframes. It's just for reference. Please use your creativity to design the screens.
1. Developer Dashboard
The user will need a landing screen where he gets after logging in to the tool. As the developer eventually can also be a publisher think of a way to be able to switch between two types of dashboards (developer and publisher). We will need the following items on the dashboard:
- Navigation: we need a global navigation for the app, where the user can navigate to the different areas of the application.
- Metrics: the user will be able to see some KPIs on his dashboard, like number of APIs subscribed, API consumption, App created or other related metrics. We are looking forward to your ideas regarding the KPIs.
- API list: On the dashboard the user will be able to see a small number of APIs in 3 categories: Top rated APIs, Recommended APIs and Most Frequently used APIs. Feel free to come up with your appropriate categories also. Each API should have its own card, with its logo, short description, free or paid tags and a link to see more details (you can explore the contents of the cards and include also the publisher, ratings, average latency, average api up time etc, that you feel useful).
- The user should be able to initiate uploading his application to the system from the dashboard.
2. Marketplace
The user will be able to browse the available APIs on the marketplace. He will be able to use keyword search and use filters (For eg. API categories) to refine his findings. We would like to see a useful presentation of the APIs available. You could also consider a grid and a list view.
3. API Details
The API Details will show all the information a developer would like to know about an API. One API might have several versions, that the user can select from. The API details consist of different screens as follows:
The API Details will show all the information a developer would like to know about an API. One API might have several versions, that the user can select from. The API details consist of different screens as follows:
a. API Details
This is the default screen of the API details pages. The user will see the API details in a plugin, like this (consider only the right side, not the code). Besides the plugin we would like you to show the following data:
This is the default screen of the API details pages. The user will see the API details in a plugin, like this (consider only the right side, not the code). Besides the plugin we would like you to show the following data:
- Name of API
- Description
- Publisher name
- Organization name (the publisher belongs to)
- Paid or free tag
- Support contacts (e-mail, phone number)
- Support forum link
- A link to initiate subscription
- A download link (Swagger and POSTMAN)
b. API Documentation
On this page the user can find the documentation of the API, which can be articles, documents or even video tutorials. The user can open or download the documentation files of the selected API.
c. API Documentation Details
Show us how the documentation file will look like when the user opens it.
d. API Consumption
This screen is only available for users who initially subscribed to the selected API. Navigating to this screen the user will be able to see the API consumption during the subscription period as API calls during a period. This period should be able to be modified/zoomed into. The user should be able to download usage reports.
On this page the user can find the documentation of the API, which can be articles, documents or even video tutorials. The user can open or download the documentation files of the selected API.
c. API Documentation Details
Show us how the documentation file will look like when the user opens it.
d. API Consumption
This screen is only available for users who initially subscribed to the selected API. Navigating to this screen the user will be able to see the API consumption during the subscription period as API calls during a period. This period should be able to be modified/zoomed into. The user should be able to download usage reports.
4. Subscription Flow
The user will initiate API subscriptions from the API Details screen.
The user will initiate API subscriptions from the API Details screen.
a. Subscription Details
The user will start by creating his application’s profile in the system (this is not in scope). He might have more than one application. When he initiates the subscription, he has to select which application(s) will need the selected API.
b. Subscription Pricing
The next step for the user is to select a pricing plan for the API, which has been offered be the API publisher, and send a request to the admin of his organization.
The user will start by creating his application’s profile in the system (this is not in scope). He might have more than one application. When he initiates the subscription, he has to select which application(s) will need the selected API.
b. Subscription Pricing
The next step for the user is to select a pricing plan for the API, which has been offered be the API publisher, and send a request to the admin of his organization.
Branding Guidelines
Please consider the below guidelines during your design process:
You have to follow our client’s branding guidelines.
Stock photos and stock icons are allowed from the approved sources.
Stock photos and stock icons are allowed from the approved sources.
Target Audience
- API and application developers and other IT professionals (as admins).
Judging Criteria
Your submission will be judged on the following criteria:
- Overall idea and execution of concepts.
- How well do the designs align with the objectives of the challenge.
- Simplicity in the overall design and user experience.
- Cleanliness of screen design and user flow.
- Out of the Box Thinking
Final Deliverables
- All original source files.
- Files should be created in Adobe Photoshop and saved as a layered PSD file, Adobe Illustrator, Sketch or Adobe XD
- Marvel prototype
Marvel Prototype
We need you to upload your screens to Marvelapp.
- Please send your marvel app request to pere.viktoria@gmail.com
- To be able to showcase your design to the client please provide hotspots on your prototype.
- You MUST include your Marvel app URL in your declarations.txt (in your marvel app prototype, click on share and then copy the link).
Submission & Source Files
Final Deliverables
For submission you have to upload a zip file that contains the following 4 files:
- Source.zip – All original source files.
All source files of all graphics created in vector format in either Adobe Illustrator or any similar software should be saved as editable files.
- Submission.zip – PNG/JPG files
Submit JPG/PNG image files based on the Challenge submission requirements stated above.
- preview.png – Your preview image
Please create your preview image as one (1) 1024x1024px JPG or PNG file in RGB color mode at 72 dpi and place a screenshot of your submission within it.
- declarations.txt – All your declarations and notes
This file must contain your notes if any, fonts used, links to the stock images and icons used and the link to your Marvel project.
Please read the challenge specification carefully and watch the forums for any questions or feedback concerning this challenge. It is important that you monitor any updates provided by the client or Studio Admins in the forums. Please post any questions you might have for the client in the forums.