Amazon Forecast Dataset Schema Tool
Amazon Forecast is one of many tools that exist as an AWS service. The purpose of Forecast is to generate forecasts of future values based on past values. This is accomplished using AI and Machine Learning to process large quantities of data on past behavior and make predictions based on the data.
Forecast consists of a command line interface and a console interface. Both interfaces have the same functionality. Customer research indicates that most technical users initially use the console to understand how different components relate and then move to the command line interface when deploying the service in production. Forecast is marketed as an easy to use service that does not require a large amount of technical ability. For those users, the console is their only way to access this service.
The problem has been that the console interface has several areas that still require technical skills which is discouraging for the non-technical users as it prevents them from being able to use the service.
The best example of this is that when customers upload datasets, they have been required to enter the dataset schema using JSON code. This is a blocker for most non-technical users and since this is the first step in configuring Forecast, many users get discouraged and abandon the process.
This specific project solves that problem for our users by offering an easy to use method of configuring the schema without any JSON knowledge.
The Problem
HIGH LEVEL TIMELINE
Two months to develop requirements with engineer input, create mockups, complete the UXSO and Fit n Finish process, and launch the feature.
THE TEAM
The team consisted of an engineering lead, a PM, a technical writer, and myself as the UX/UI designer.
.
KEY GOAL
To launch an alternate method of entering dataset schemas that requires no coding knowledge.
My Role
I work as the UX designer for the Amazon Forecast console. Prior to this project, I conducted a usability study with six clients to learn about their pain points when using the console interface. This specific project was created as a result of that research.
I worked with an engineer to determine what would be possible both within the Polaris design framework as well as potential options that were outside the framework. I then created mockups of a potential solution and worked directly with the engineer to ensure that the solution was both possible, and would deliver all of the functionality required. The technical writer was also part of the process and we worked together to ensure that all copy was correct and in line with AWS standards.
My responsibilities also included scheduling and completing UX sign off and Fit n Finish reviews prior to launch.
Understanding The User
The target users for this project were new technical users as well as any non-technical user.
A sample of the primary persona that was identified is shown below:
Defining the product
The existing dataset upload process was used as a starting point, with the primary emphasis on offering the user the option of using the existing method or utilizing the new tool. It was important to keep the existing method as it offers the ability to cut and paste a previously used schema.
One feature that I felt was important early on was to allow the user the ability to create a schema using the graphical tool and then switch over to see what it would look like in JSON format. Many users want to expand their technical expertise and this would allow them to generate a schema and then learn what it would look like in JSON. In addition, if the user wanted to make a change in the JSON, and then switch back to the graphical tool to easily see the effect that it had.
Below is the original process that a user would go through to upload a dataset. This process consists of multiple screens which were also consolidated as part of this project.
The experience I designed allows the user to toggle back and forth between the schema builder and JSON. In addition, I was able to consolidate selecting the format of values such as timestamp into the actual element in the schema builder.
The process allows the user to add attributes contained within their dataset and then arrange the attributes in the order they appear in the dataset by dragging and dropping the attributes.
Below are high fidelity images of the final design.
Schema builder option selected. Some attributes are required and are added by default. The name and type of required attributes cannot be modified. The timestamp format is set as part of the timestamp attribute by the user.
Schema builder option selected. User has added a location attribute with an attribute type of geolocation. Location format selection is shown by default for geolocation attribute type.
JSON option selected. Required attributes are added by default. Timestamp format is shown below.
Learnings
Consistency between options
By allowing the user to switch between schema inputs, the user has the opportunity in JSON to enter invalid values or enter values in an incorrect format. Handling this issue when switching back to the graphical schema builder presented several issues which had to be solved for.
Design system options
The Polaris design system did not have components specifically for drag and drop. This was my first opportunity to go outside of what was available in Polaris and design my own components.