Transformation Builder

In the beginning, we considered a separate view for the actions panel and the code. Meaning, the code won’t be seen as a default. After getting the feedback from stakeholders, we understood that code should always appear in the tool for Developers. So, I created a layout where the code and actions panel are always visible.

We started with the message “Start creating your transformation” and three action buttons - “Add Action”, “Add Image Overlay”, and “Add Text”. It happened because we felt we must follow the API structure (API counts actions and layers as separate things). After, a number of iterations we came to the decision to show a flattened list with all available actions and layers). We removed the extra click and got users straight to the action.

After we updated the empty state to the flat actions list. We got a suggestion about adding the filter, as our actions list is quite long. So, we added an actions filter. Also, to get the empty state more user-friendly, the filter field is selected by default. So, the user can start writing and filtering the actions after the tool was opened. It was great to see in other tests how users start typing something to filter the list in other tests.

In our API there is no such thing as a layer, we have image overlay and underlay, and the same goes for text. During the usability test, when users got a task to add a watermark - they struggled to find this overlay action. Users who found this action called it “layer”, then, we decided to rename these actions in the Transformation Builder to “Image Layer” and “Text Layer”. I validated the result as a part of another usability session and got good results.

As I mentioned earlier, we used the SDK data to understand the most popular and relevant actions used to define the action list in the Transformation Builder. However, we wanted to provide users with the ability to use more advanced features and actions that are not included in the list. To address this, we introduced the "Additional Transformations" action, which includes a text area where users can input anything they need using our syntax. We also provided a link to the documentation.

During the usability testing session, only two out of five users were successful with the task. As a result, we decided to update the placeholder text in the text area and provide a real example of what can be written there. Additionally, we included three additional examples with explanations that users can easily copy by clicking on them. We also included a link to the documentation as the last item. In a subsequent usability testing session, these updates significantly improved the user experience.

For new users, it’s very easy to think of an image editor when they see the Transformation Builder for the first time. So, we wanted to emphasize that transformation works on any amount of images. Below the preview area, we put “Preview Image Gallery” where we put five images of different types. So, the user can easily switch between the samples and see how the transformation works on the selected image. Also, we added an option for the user to select a different picture as well.

This came from our Strategic customer who used the New Transformation Builder. The customer said that it could be a huge improvement if we add an ability to show and hide actions. It could be useful when you work on complex transformations and you like to check something by hiding one or more actions. In the previous implementation, the user can do this only by deleting the action. So, the suggestion was accepted, designed, and validated with a usability session fast. Implementation took one sprint only which is considered as a quick win.

Another suggestion that came from the same Strategic customer is to add an ability to move actions up and down. The order in transformation is crucial, in the case of complex transformation that has many actions. In the previous implementation, it was possible to add an action below another action, but once it was added user didn’t have a way to move it up or down in the case of error or validation purposes. The action deletion was the only way to put the action in another place. So, we decided to add an ability to move actions up and down by adding a common drag-and-drop design pattern. In addition, we added also buttons allowing us to do the same. The design and validation with the usability session went smoothly. Also, it turned out, that this task was very cheap for R&D to implement, so, it was implemented also in one sprint and was also considered as a quick win.

A minor change but pretty valuable. In the beginning, we had only the “Apply” button on the Action Details panel. Meaning, the user must close this panel either by clicking “X” on the top of the panel (a different place than the “Apply” button) or click on “Add New” on the Action Panel. Very soon we realized, it will be a great addition to add an “Apply and Close” button. So, when the user is working on an action, changes values, and wants to see the result, he or she will use the “Apply” button. Once the user is done working on the action - clicking on “Apply and Close” will apply the latest change and will close the panel. It was great to see in other tests how users use “Apply and Close” without thinking.

Another small but useful change. Sometimes, the transformation code could be long and cause both horizontal and vertical scroll. We got complaints about the scrolling issue and decided to add a dragger that allows users to resize the code snippet height as needed.