NAP

Front End

We iterated over 3 main sections in developing the front-end.

Firstly, we planned to have the chatbot interface be very much like a messaging platform, that users are very familiar with, given the popularity of texting apps such as Facebook Messenger, WhatsApp, etc. This led to decisions such as having the feature to minimise the chat interface, refresh chat conversations and as an attachment to the NET-A-PORTER website.

Secondly, we experimented with the display of results from product recommendations. Initially, we decided to return results with a single item on view, and users can click on left and right buttons to view other items as part of the results returned. However, we thought it was not an intuitive experience. Therefore, we decided to change it and output the products all at once, and users can scroll to view the products.

Lastly, we tried different combinations of product data that would be ideal to display on the chatbot interface for each of the product results. We realised that data such as size fit and categories were not important to include and will clutter the interface. Ultimately, we went with product name, description and price as information to be attached to each product. Each product also has a large standardised image that will link to the product page.

REST API

The chatbot service is wrapped in a REST API that can be used across different platforms, and as an example we built the web app to showcase the features of the API. We did not have the initial idea to build an API, and it is only after consultation with Dr Harry Strange (Managing lecturer for NET-A-PORTER teams) and our client that an API will provide a lot of benefit to allow our work to be extended by other NET-A-PORTER teams.

For the Product Recommendation feature, our team explored the use of a to-and-fro process to gather specific information for a user query. For example, a user can ask for a dress, and the chatbot will ask for colour, so on and so forth until all filters are decided. However, upon review from our client’s upper management, we came to a consensus that we should reduce the time-to-product, meaning that users should see the products as quickly as possible. Therefore, we scrapped the filtering process and allowed the user to specify all available filters (brand, colour, size, etc) and return products upon a single query.

For the FAQ feature, the plan was to use intents to know that user is asking for such information and to extract key details using entities. However, we went with that approach and found out that it is not a viable method. These entities will be hard to maintain because the FAQ information are static on the website and there are no APIs to retrieve them. Upon further research, we discovered Watson’s Retrieve and Rank and Document Conversation service which is ideal for our purposes as it is based on using a knowledge base (FAQ information) and a question pool (FAQ questions) which can be added on and extended over time.