IAN FARRELL
SD-squarespace-front.jpg

UX: Stella & Dot's Engravable Redesign

STELLA & DOT’S ENGRAVING REDESIGN

The purpose of this project was to optimize the workflow for how engraving templates were made and then assigned. Engravables makes up a substantial amount of revenue for both Stella & Dot and Keep, which is a sister company that focuses mostly on customizable jewelry pieces.

Current state of creating a new template

Current state of assigning a template to a product

One of the main reasons this project came into the scene is because the company recently acquired a new machine for engraving that would allow different materials to be used (leather bands, semiprecious gems, wood, etc.). Knowing that engravables would be expanding as a process and as a revenue source for the company, it became pretty apparent that something had to be done with the current setup. 

The engravables product layout on the B2C site once templates are created and assigned.

MY ROLE

I conducted the research required and led the design for the new workflow to be put in place. While working through the project, I collaborated with the UX team (a Product Designer, a Senior Designer, and the Director of UX) for important feedback. I also conducted a large portion of my interviews with a member of the Site Ops team who would primarily be using the new workflow design.

In all, the project consisted of:

  • interviews with the Site Ops team to gain a clearer understanding of the flow currently in place

  • constructing a job map to dissect each step of the current flow

  • deciphering the MVP's that would have primary focus in the redesign

  • wireframes to build the skeleton of the new layout

  • a clickable prototype to see the potential workflow in real time

  • a usability test on Site Ops to gain final feedback

EARLY INSIGHTS

Once I began prepping for my initial research, I approached my potential findings with the Jobs To Be Done (JTBD) theory. The theory essentially states that any job can be deconstructed into specific process steps in order to gain clearer insight on the overall job. It also provides a structure to capture all of a user's needs and to identify opportunities of growth. I constructed my first interview with Miriam on this basis and formulated my findings into a job map. 

The job map broken down into 5 specific process steps.

As you can see, there was a lot of information gained from the JTBD approach, and a lot of pain points found along the way. When I sat down with Site Ops, she voiced a lot of issues with her process in general, but there were some key pain points that kept resurfacing.

In its current state, any template on the back end site can't be deleted, and the only edits you can make on templates are on the display name and the engraving method. If there's some template with a mistake on it, the only work around she has is to write DO NOT USE in the name field, which clutters the page with a bunch of useless templates mixed in with working ones.  

The current editing state. The display name and engraving method columns have editing capabilities while all other columns are greyed out.

An example of a "DNU" template sitting above the correct template to be used.

There are a lot of repeats in here since I can’t delete anything. I can tell what templates I should be using, but it’s pretty annoying to see all these templates that I can’t do anything with.

To sum up my findings from Site Ops’s current workflow with engravables, I found that the actual creation and assigning of templates is fairly straight forward. The problems more so lie in what happens after those two jobs are completed. From this I was able to establish my 3 top MVP's:

  • editing all template fields post creation

  • deleting templates with a follow up confirmation message

  • adding multiple swatch images to selectively choose a swatch to represent on the product level

Outcome findings of the Site Op's job map.

DESIGN TIME

Since engravables exists within a larger backend site for admin, the framework in itself lives in an already cohesive layout, so it wasn't an enormous change. 

The proposed first page of creating a template on the backend site.

The proposed first page of assigning templates to specific products.

To address the limited editing capabilities, I changed the format to show that all sections have the same coloring, illustrating that all text fields can be changed. 

The proposed state of editing a template. All fields are white to show that everything can be changed.

The proposed state of editing a template. All fields are white to show that everything can be changed.

To revise the deleting aspect, I added a delete button under the action column in order to hopefully clean up the template library of "DNU" templates. Earlier on in my user interviews, Site Ops also requested a confirmation that a template would be deleted in the case that the team accidentally deleted a template they meant to keep. I employed a second popup to ascertain whether a Site Ops user truly would want to delete the template in order to resolve that issue. 

The proposed template change with the delete button added to the right.

The proposed template change with the delete button added to the right.

The proposed template change with the 2nd delete confirmation in place.

The proposed template change with the 2nd delete confirmation in place.

The Site Ops team also made it a point that some templates they would want to delete might possibly be already tied to existing products and therefore should be examined prior to deleting them. The reasoning behind this was that if a customer had an engravable item in their cart with a template that Site Ops was trying to delete, deleting the template without investigating its usage on the B2C site could mess up a customer's order. To alleviate this, I added an error popup modal to indicate that a particular template might already be attached to a product, and in order to fully delete the template, Site Ops must first detach the template on the product level and then return to the template to delete it permanently. 

The error modal for the case that a template is attached to a current product. Clicking the product link would take you to the product site page allowing the user to investigate/detach the template.

The error modal for the case that a template is attached to a current product. Clicking the product link would take you to the product site page allowing the user to investigate/detach the template.

To fix how swatch images were chosen, I decided to allow multiple images to be picked at the same time when searching for template images. Once they were added to a template, I created a way to toggle through the images to let a user verify how many images they chose and to see visually that they chose the right images as well. 

The search popup for when a user adds images from the editing state.

Once a user finishes editing/creating a template, they have the option to toggle through the swatches chosen to see what they have just uploaded.

In addition, once a user saves their swatch images on a template, they can go into the product page and selectively choose which image to be represented by that template on the B2C site. 

Once a user assigns a template to a certain product, they can toggle through the different image options to save which one they want best represented on the B2C site.

FUTURE STEPS

While I integrated all of my MVP's into my final work, there was a bit more I would've liked to finish given if I had no time constraint. There were two major issues I would've liked to tackle:

  1. Implement a way to detach templates from products on the error modal - there will be times when the Site Ops team is aware a template they're trying to delete is tied to an existing product. Rather than having them click on a link to open a new tab to the product specific page, I think it would make more sense to add a detach button from the modal itself to decrease bouncing back and forth between pages and to save time.

  2. Add different languages to store specific columns - you might've noticed a blueish green header on some of the columns within the redesign, which is an indicator of copy that should show up in a particular language given what country the site is catering to. Stella & Dot reaches a number of countries, most notably Canada who has an obviously high population of French speaking customers. While the Canada site is in French, the backend site currently only has store specific language in English. This means that if a Canadian were trying to buy an engravable product on the French site, they would also see the display name of templates and their respective hint fields in English. While this remains a pretty big oversight, it was only discovered by the team and I after my 2nd round of wireframes had been created and ultimately didn't fit in with the timeline I had.