Integration & Data

Team
1 UX Analyst
1 UX/UI Designer

Timeline
Dec 2020 & Ongoing

Duration
2 weeks

Context

EdCast Marketplace is a global B2B e-commerce platform that enables corporate L&D teams to source all their training products and services from a single, integrated learning ecosystem. The EdCast Marketplace gives access to an expanding catalog of self-paced and instructor-led training programs in various areas, such as Technology, Soft Skills, Leadership, and Compliance.

The Integrations & Data Framework is one of the applications that is part of the EdCast Marketplace environment. With it, Sellers are able to connect the EdCast Marketplace APIs with their own systems, upload large amounts of data from their internal catalogs, and export various types of reports.

This page summarizes the key contributions of the Design Team's involvement in this project.

Key Features

      •    Generate API Keys - connect the EdCast Marketplace APIs with the Seller's systems

      •    Import Data Center - upload large volumes of information listing Seller Products, Course/Services, Internal Repository Materials, Pricing Models, among others...

      •    Export Data Center - generate and download custom reports, such as transaction, purchase order, and venue reports

Project Goals & Challenges

Given the context of the EdCast Marketplace set of applications, interestingly, the goals and challenges for this project are intrinsically related.

Create a new (and separated) application to support the integration of the EdCast Marketplace with other systems

Contrary to other applications, such as the Admin Panel, the Integrations and Data Framework is expected to be only used by highly technical users. Moreover, due to various technical and timeline constraints, it was not possible to include these functionalities within the Admin Panel (which was also in the process of being redesigned). As such, despite being very impactful, given the expected low number of users expected to use this, it became necessary to design this as its own separated application.

Support Highly Technical Users

As you can see with the Personas identified in the other projects, most Sellers interacting with the EdCast Marketplace applications are not required (or even expected) to have a high degree of technical knowledge. This, however, does not apply for this application, as it is expected to be only used by technical users, such as those usually found in DevOps of Integrations Teams.

Ensure Consistency with other applications and on-going designs

As mentioned in the main EdCast Marketplace project page, one of the key issues with the platform was its lack of visual and functional consistency. Despite the existence of a Design System, at this point, the creation of yet a new application brings the risk of potential inconsistencies that we must be aware of.

Moreover...

In addition to the aforementioned factors, and as, unfortunately, common with some of the other projects in this environment, we had no access to actual end-users nor a company buy-in for qualitative data research. This, once again, forced us to adapt and restrict our design process, as well as focus on the information we could acquire from internal stakeholders and users with comparable skillsets within our teams.

The Process

As this project began from a direct client request, there was really no previous data that could be used. Nevertheless, we followed a similar process to the one we have been using for the other referred projects.

Defining Users: Personas

Identifying Core User Flows

Following the gathering of the requirements from the related stakeholders as well as the aforementioned step(s), we proceeded to ideate over the various flows users would be put into, when using this application. As with other EdCast Marketplace projects we are limited in what details we can actually provide. As such, below follows a high-level summary of the most important flows.

Ideating: Information Architecture

Below follows the proposed information architecture (sitemap) for this application.

Prototyping: High Fidelity Mockups

Below follows a selection of some of our high-fidelity mockups corresponding to our final proposals. Once again, it is important to emphasize the critical role of communicating, on a frequent basis, with both Engineering and Customer Support to help in the decision-making processes. Engineering stakeholders were key to help us evaluating and prioritizing the feasibility of various proposed features. On the other hand, as mentioned before, our access to users was limited to non-existent, therefore the Customer Support Team's participation was of the utmost importance, as all decisions were heavily influenced by direct client feedback given to them over time.

Export Data Center

The Export Data Center section allows users to create custom queries to request data from our system and generate/download reports from them. This feature is similar to the Transaction Reports functionality provided with the Product Marketplace.

Integration Configuration

In the Integration Configuration section, users can generate their API keys and manage all Single Sign-On (SSO) Configurations.

Testing and Delivery

Despite the lack of (actual) end-users to work with, the main audience targeted by this application is easily comparable to members of our own Engineering Team. As such, despite all the aforementioned constraints we were still able to gather relevant feedback in time for the handling of the deliverables for development. This was primary done via quick interviews, in part, not too different from Guerilla Testing (although with a more controlled environment and population).

Unfortunately, due to technical constraints (and the small scope of this project), it was not yet possible to connect this application to some of the tracking applications we mentioned in other projects. As such, the monitorization of the quality of the experience provided by this platform is, at the moment, limited to the qualitative feedback we get from the limited number of users interacting with the tool. Nevertheless, below follow some metrics of interest related to this project:

      •    Time required to validate the uploaded CSVs - this is important since, during this time, users cannot do anything regarding the items that they wish to upload. If this process takes too long, the user experience can become compromised.
      •    Most frequent type of errors/warnings resulting from the CSV validation - this is important since users will need to solve these errors and re-upload their CSV files again, in order to proceed with the complete upload. If patterns are detected, it is possible that proper guidance is missing;
      •    Frequency of visits to item upload pages - while products/courses and other items are being created, users can view the progress of this process every time they visit the respective upload/reports page. Having an understanding of the frequency users do this can give us insights on the type of information that we may need to provide and the expectations that we may need to set up when users first begin this process;
      •    Most common types of reports and filter/conditions used - this should allow us to provide easier ways to begin building certain queries and, if applicable, decide on the priority of providing more specific report templates.

Key Takeaways

Comparatively to most EdCast Marketplace projects listed, this was a significantly smaller and less complex one (although the time and resource constraints being very similar). Nevertheless, there were some interesting takeways from this project, summarized as follows:

      •    The Importance and Results of a Design System. One of the first projects listed around the EdCast Marketplace was the creation of a Design System (and set of rules/guidelines). Moreover, the redesign of the Admin Panel (which, realistically should include these functionalities) was already in progress. Comparatively to early projects, we noticed how simple the creation and use of various components, in a way that is consistent accross the various applications, had become during this project. This, in turn, served as an internal validation of our previous efforts in creating the Design System.
      •    The Extra importance of the Engineering Team. As mentioned acorss all other projects, the involvment of the Engineering team is crucial to understand the feasibility and scope of various features. However, in this project, some of its members were comparable to the actual end-users targetted by this application, giving us, in turn, a fairly different, but no less valuable source of insights, during the various stages of this project.

Thank you