Overview

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. In order to deliver any training program, subject matter experts, also known as Instructors, are needed to present and help Learners with the contents of the program.

The Service Marketplace is a key component of this process, as it connects Buyers, interested in the training of their organizations, with the Sellers/Instructors capable of delivering it. This platform supports the entire process between these two parties, including the discovery of the available training programs, the communication and quotation/negotiation cycles, the delivery of learning materials, and, finally, payment and invoicing.

This page summarizes the redesign and expansion of some of its core functionalities - particularly focused on Instructor Negotiations.

Team

•  1 UX Analyst (yours truly)
•  1 UX/UI Designer

My Contributions

•  UX Research (primary function)
•  UX Design

Timeline

•  Q2 2019
•  ~ 6 weeks

Project Goals

Following the MVP release of this platform and the later improvement over the Product Marketplace (also summarized in this portfolio), this project had 3 main goals:

•  Update the "look & feel" to fully match the company's (updated) branding;
•  Improve the user experience, based on the various issues identified with the MVP version;
•  Support additional use cases for service discovery and quote negotiations.

Challenges

Given the context of this project (a B2B platform) and the company's structure (a Start-up), there were some important factors that, ultimately, impacted our process. These include:

•  Niche product with no established competitors;
•  Stakeholders to which the project is sold (customers) are often NOT the actual end-users;
•  Limited access to end-users;
•  An "engineering-focused" structure with a high buy-in for quantitative, but low buy-in for qualitative data;
•  An expectation to combine general B2C aspects (often seen in e-commerce) with traditional B2B constraints (e.g., highly complex processes with large volumes of information).

The Process

The process above is heavily based on the Design Thinking methodology (Empathise > Define > Ideate > Prototype > Test).

Review Previous Data

This stage is characterized by the collection and review of data from multiple research initiatives, summarized below. These initiatives are very similar to the ones I conducted for the Product Marketplace redesign, in part due to some of its similar goals, but also due to the wide range of applicability of the methods applied and/or the coincident timeline of some initiatives.
(Note: due to NDA purposes, some of the examples below are blurred out)

Stakeholder Meetings & Interviews

As with every project, these include multiple teams, including our own Customer Support. These allowed us to: clarify company requirements, identify assumptions about the existing MVP and its customers, and, perhaps more importantly, examine the long-term strategy/vision for the product.

Thematic Analysis

Complementing the aforementioned Stakeholder Meetings is a large-scale thematic analysis that I have conducted over our customer tickets. The systematic analysis of this information allowed us to, more accurately, identify the users' most common types of issues, as well as general patterns in terms of topics, language used, requests, and overall communication.

If you wish to know more about this initiative, visit this page, where I summarize its overall goals, process, and outcomes.

Web Analytics, Feedback & Behavior Tracking

Using applications like Hotjar and Google Analytics, we were also able to review and analyse the users' behavior with the platform.

On one hand, Google Analytics allowed us to inspect general platform-wide behaviors, such as seeing which were the most common search terms used to find instructors, or how long Buyers would spend on specific pages. On the other hand, Hotjar allowed us to assess the platform on a page- and/or feature-specific level, as I was able to review recordings from actual end-users interacting with the platform, interact with them via polls/surveys, to gather feedback on the quality of the current MVP, and visualize heatmaps of multiple pages of interest.

It is relevant to mention that each of these methods can help compensating the others. For example, surveys helped to provide some additional context, missing from raw (silent) recordings.

Raw Data Analysis

Despite its relatively recent MVP, by the time of this project, we already had a significant amount of configuration data, describing our customers, as well as their settings usage. This information can provide valuable insights on how often and in which ways the platform was being used (e.g., what profile capabilities are used the most? how much information do Instructors add to specific sections of their profiles?).

Comparing "Competitors" & Adjacent Platforms

As mentioned earlier, in the Challenges section, by the time of this project, there was no clear competitor in the market for this type of platform. Nevertheless, we conducted a comparative analysis on other platforms with comparable services.

This analysis was, naturally, conducted based on multiple dimensions (and, if not due to NDA purposes, it could itself be an entry in this portfolio). The table below exemplifies the platforms' concept of the user profile, alongside the role of service pricing and the general relevant information provided.

Research Insights

Through the research methods mentioned above, the most crucial conclusion reached was that the negotiation flow, provided in the MVP release, was not representative of the users' needs. In particular, we identified some significant insights, summarized as follows:

Negotiation Deadlines
Originally defined by our Product and Leadership teams, each iteration in the negotiation flow had a deadline to make negotiations more efficient. However, despite the useful features provided by the platform, there are still several (external) factors that can (and likely will) delay the negotiations. This led to various negotiations being closed due to these deadlines, which in turn, forced users to re-start multiple negotiation flows for the same request. Unsurprisingly, users ended up considering these deadlines arbitrary and punishing.

Communication
The communication between both parties was limited to the use of an offer/counter-offer system, to minimize the risks of having the parties negotiating outside of the platform - Note: a fee is applied upon every transaction on the marketplace. However, this was still not possible to avoid, since, while users did consider this a very good method to introduce and formalize their agreements, Buyers would still directly request our Support Team for the Instructors' contacts, or they would provide their contacts directly in their job/assignment requests.

Rigid Requirements
In the aforementioned offer/counter-offer system, Buyers (i.e., the party requesting quotes from Instructors) were given the most power and responsibility in the negotiation, particularly, in regards to the date selection of the delivery. Given that the MVP release of the product did not allow for the edition of these requests, this led to two main issues:
(1) Buyers were not always able to provide a precise date period at the beginning of the negotiations - since these are susceptible to changes.
(2) Even when they could, Buyers would often make mistakes - such as trying to schedule a 3-day course for only 2 days.

These types of situations would lead negotiations to be canceled and re-opened again when there was more clarity by either party.

Profile Scalability
With the MVP release of the platform, several instructors have registered and published their profiles. However, some of the older/more experienced instructors have a very large number of certifications and accreditations that allow them to deliver a very high number of courses (i.e., > 20). These cases heavily contrast with Instructors that are either less experienced or, more importantly, very specialized. This led to 2 main consequences:
(1) Navigation in profiles with a large number of courses would become tiresome, requiring users to spend a lot of time scrolling on each profile;
(2) Instructor profiles with fewer options would be seen as significantly less appealing to Buyers

Negotiation Management
My research has also shown that users considered managing the list of negotiations a very complicated task, particularly due to the aforementioned issues, that would lead to the existence of multiple negotiations around the same request/delivery. This, in turn, made finding the correct negotiation far more complex than, realistically, necessary.

Pricing and Digital Exposure
Instructors creating their profiles had to provide a profile picture and, for each course, an indicative price to help Buyers in the initial search and negotiation process. This led to some of the most interesting pieces of feedback that we got from Instructors:
(1) Some instructors were not pleased with the idea of providing pricing information upfront - even if, to their acknowledgment, the platform would mention that those were just indicative prices and that could/should be negotiated;
(2) Some instructors considered having pricing information closely associated with their image "uncomfortable". This point is, to us, particularly interesting, when considering that this feedback came from Instructors delivering "IT-Courses". However, we must also acknowledge that most of these Instructors had only been used to very manual and/or indirect hiring processes until now.

(Re/De)fining Users, Challenges, and Objectives

Combining the aforementioned new requirements for this redesign, alongside the various issues mentioned above, we worked together with Product, Engineering, and Leadership teams to define this project's objectives, summarized as follows:

Improve the Buyer<>Instructor negotiation flow
•  Simplify the offer/counter-offer system;
•  Enable direct communication between both parties;
•  Support flexible and long negotiations (i.e., that are susceptible to changes).

Improve Negotiation Management
•  Negotiations should become more akin to active communications, implying changes to how the management of these items is done on the platform;
•  Improve the search of current and previous negotiations;
•  Avoid "unintentional duplication" of negotiations.

Emphasize Services over Suppliers
•  The MVP version was intended to emphasize the "human dimension" of the hiring process - having been designed with a somewhat social focus - this, however, seems to have alienated part of our user base;

Improve Discovery of Services and Service Providers
•  As the aforementioned requirements will imply significant changes to the information being used and emphasized, our discovery pages will also need to be revised - this includes both in terms of information provided but, more importantly, the logic behind existing filters.

Support Instructor Teams
•  The MVP version focused primarily on individual instructors as the service providers;
•  The next phase of this product should also support companies representing and managing the schedules of multiple instructors.

Personas

Identifying Core User Flows

Following the aforementioned steps, we proceeded to ideating over the various flows users would be put into, when using the platform.

Note that, due to NDA purposes, we are not allowed to present the full details of these user flows; therefore, below follows a summary of the most important flows, alongside some (blurred) screenshots of our working ideas.

Prototyping: Wireframes/Low Fidelity Mocks

Following the definition of the aforementioned core user flows, we began ideating on possible solutions, using low-fidelity mocks. Naturally, this is not a linear process and several iterations had to be made. Below follows a selection of screens from one of the most recent iterations.

Prototyping: High Fidelity Mocks

Below follows a selection of some of our proposed high-fidelity mockups. Once again, it is important to emphasize the critical role that communicating, on a frequent basis, with multiple stakeholders during the research, design, and decision-making processes. Engineering stakeholders, in particular, were key to help us evaluating and prioritizing the feasibility of various proposed features.

Instructor Tile

From the original design (highlighted in red), we went through multiple design iterations, as seen below. We experimented with several ideas to bring emphasis to the services and skills provided by the individual, over the individuals themselves. For this exercise, the aforementioned "competitors" analysis was particularly important, alongside the participation of Engineering stakeholders in the various sync-up meetings.

Ultimately, we decided on the final solution shown below. Comparing to the original design, it takes the focus out of the individual, while still recognizing their importance, and instead brings it to the skills desired by Business Buyers. The more compact design improves also readability and allows showing more Instructors in the results/feed page(s).

Proposed Solution

Instructor Profile

Below you can see the comparison between the original and proposed design for the Instructor Profile page. The most significant differences include:
•  Improved guidance, to help instructors complete their profiles (e.g., actionable empty screens).
•  Improvements on content distribution & real-estate
•  Improvements on Service listings (e.g. search and basic filtering are provided, to prevent aimless scrolling)
•  Support of Media / Service Demonstrations - allowing for younger or more specialized instructors to compensate for their lack of service variety;
•  Availability Listing (calendar and service area/map).

Before

After

Instructor Feed

The Instructor Feed is where Buyers are sent when searching for an instructor. The improvements over this page are closely related to those described in the Instructor Tile section and a comparison can be seen below.

Before

After

Quote Request / Assignments

Negotiations between Buyers and Service Providers often begin with a quotation request from the Buyer. In the MVP version of this platform, this step was known as Create Assignment, where Buyers would compose a formal request for the delivery of a specific course. They could then send it to Instructors to apply. However, this had various restrictions that had a negative impact in the Buyers' experience. With this redesign, while Buyers are still required to send a formal Quote Request to Instructors, significant changes have been made, summarized as follows:

•  Fast Start - This process now begins directly when contacting an Instructor. Sellers can provide the details for their request, or use a previous request;
•  Less rigid date selection - instead of selecting the exact days for a course delivery should take place, Buyers now only need to provide an indicative period for the delivery. Specific dates are defined during the negotiation conversations (next section) and formalized by an Instructor's offer;
•  Less rigid service selection - in the MVP version, Buyers would need to associate their request to a specific course (listed in our internal taxonomies). This is now an optional feature, as Buyers can now request for a specific course listed by the instructor, or request for a custom one.

Before

After

Negotiation Management

The Negotiation Management features were the most heavily changed. Below you can see the comparison between the previous and the new version. While most issues were already mentioned, below follows a summary of the most significant changes:

•  Support of fully open messaging capabilities between all parties involved in the negotiation;
•  Complete shift from providing a list of request > offer/counter-offer entries, in favor of a more open messaging system - Direct communication is now the focus of negotiations, supported by request <> offer functionalities to finalize the agreement;
•  Looser deadline consequences - instead of canceling a negotiation, offers will now simply expire, allowing them to be updated/re-submitted - this allows users to be always informed of their negotiation history, it prevents the duplication of negotiations, while still keeping the urgent pace in the negotiation cycles, as originally required;
•  Step-by-step guidance - as seen in the Identifying Core User Flows section, these negotiations can be very complex. For that reason, users are given constant guidance on what is the status of the negotiation and what actions are expected from them.

Before

After

Miscellaneous Screens

Below follows some additional selected screens summarizing the platform and displaying other features, such as the checkout page, notification settings, instructor manager listing, as well as some examples of our responsive designs, for smaller screens and mobile.

Testing, Delivery, and Next Steps

To compensate for the limited access to multiple instructors and the short timelines for this project, we focused our test efforts with internal stakeholders (some of which also instructors), through multiple interviews and quick user testing across the key tasks of the platform.

Naturally, this also made the identification and tracking of post-release metrics all the most important. Using the tools and techniques, previously mentioned in the Review Previous Data Section, we paid close attention to:
•  Qualitative Feedback (e.g., collected via Surveys) over core features of the product, such as ease of use (checkout), perceived utility (profile), or general satisfaction (inbox/negotiations);
•  Number of Support Tickets received, with requests for help on how to use the platform;
•  Breakdown of Agreement statuses (i.e., canceled, in progress, completed);
•  Number of Agreement attempts (offers) per negotiation;
•  Number of expired offers per negotiation.

Key Takeaways

By the time of the writing of this project, there are still several important features yet to be released. Nevertheless, since the redesign, we have noticed a significant decrease in regards to customer tickets and a high ratio of positive feedback across the various features. Currently, among the most well-received features is the redesigned negotiations management functionality. as it lifted several of the MVP-imposed restrictions and greatly reduced the need to contact third-parties (i.e., our support team) to enable some of the negotiations.

To summarize, some of the key takeaways from this project are:

Involve Engineering and Customer-facing stakeholders early-on and regularly 
This is key to get a better understanding and help to prioritize domain-based and technical limitations and solutions.

Create a strategic plan to launch an MVP and schedule improvements in time 
This helps to deal with out-of-scope requests and define the basis of a proper experience even with limited features.

There is always information to be found if one makes the effort
Despite all the aforementioned challenges, it was still possible to gather valuable data through multiple sources and techniques, from traditional stakeholder interviews and surveys to more technically-driven research based on configuration data;

Track data and track it often
The definition and tracking of key metrics is extremely important. It was thanks to doing this, during the MVP phases of the project, that we were able to gather as much information as we could for this redesign. It is also because of this that we can keep tracking of the experience provided by the product and plan for further improvements.

Thank you

Recommended Next:

OR
See all related projects below: