WHAT IS SCHALINS?

Schalins Ringar AB is a company that sells engagement- and wedding rings via resellers all over Sweden. Each one of these resellers has Schalins app on an iPad where customers can with help from an employee build a custom ring. Our job as UX-Designers has been to update the look for this app to make it user friendly for completely new users without the help from an employee or ring expert.

The Problem & Goal

The problem we aimed to investigate was how to make Schalin's 3D configurator easily understandable for individuals with no prior experience of rings. At the time the app was designed for store personnel who already had previous experience.

The goal of the project was to enable new users to quickly and easily understand how to navigate through the app and build their ring exactly as they desired. We wanted to simplify the process for customers to visualize how their ring would look. Customers should also have been able to easily view the price estimation calculated by the app based on the ring's contents. Furthermore, we focused on building for the end user and assisting them through the product using simple concepts and explanations.

Target audience

The primary target audience were couples who were planning to get engaged/married. The secondary target audience was anyone interested in building their own customised ring. An important aspect was ensuring that all target audiences could understand the purpose of each part of a ring within the app.

UX Review

We began our project by conducting a UX review to gain an initial impression of the app. Seeing the app with fresh eyes shed light on many pain points users encountered. We documented all our thoughts and discussed the problems we had encountered. We identified various parts of the app that needed improvement. Some of the issues we encountered were that the 3D mode was not prominent, the icons in the header were oddly placed, and the filter menu in the 3D mode was confusing as it gave a sense of constantly creating new problems.

Competitor analysis

At the beginning of the project, we decided to conduct a competitor analysis. Since both my colleague and I weren't particularly familiar with how a site/app like this is structured, we felt that a competitor analysis would help us reach an understanding of best practises. What do the sites have in common, and what is good and not good?We informed the product owner that we would undertake a competitor analysis and received a dozen pages with similar themes to review and analyze. We took screenshots to highlight certain parts of their site about what we thought were good as well as bad design decisions. We also wrote overarching texts about the feel of the website and what guidelines we could consider following that align with practically all competitors. What we gained from the competitor analysis was a strong overview of how the theme is structured. The mega menu was important to develop, and "luxury" was a feeling that was prominent many times. We noticed similar features such as "hybrid function," "share," delivery times, and booking for personal advice at retailers. This became very useful during the project as we could always go back and see how the competitor had done it to then try to make improvements.

Impact map

Creating an impact map was necessary since we needed to visualize our target audiences and understand their needs and user goals. The behavioural types and personas had already been established by the product owner, which allowed us to focus on their needs and goals.

Interviews

This method was, to say the least, a significant part throughout the project. When we were about to start our qualitative research, we decided to use open interviews as well as questions with more detailed answers from the user. Open interviews were a good way to find out what the user knew about the area itself and what they thought about the idea of ordering their wedding ring online, general thoughts, and considerations. To get a better view of how to build through the website, we felt that questions were the right way to go. We developed the questions that could benefit this project the most. We came up with 30 different questions that gave us answers on what was needed in the app and on the website. What was most important for the user? And what were the potential obstacles the user might encounter during the journey? We set up the questions in an Excel sheet and wrote down the users' answers in the same Excel. We interviewed a total of 11 users who were in the target audience we focused on. This resulted in an overview of the most important aspects of what features were needed on the website and how to navigate through it best. They gave us answers on what to avoid and what to focus more on. In this case, security was very important to the user as well as receiving personal advice and clarity on how the process worked.

Affinity diagram

In the affinity diagram we gathered all thoughts and ideas on how the website should function and what is needed to fulfill the user's needs. Various features that could create a good user experience. This gave us insight into which features were important and more general choices regarding UI and UX and what it should be based on.

User story mapping

We used this method to gain insight into the user's journey through the product. We stepped into the user's shoes and segmented different moments for each step through the product. How is it used? What is the next step the user takes? What feeling does the user have during each sub-step? We identified various pain points during the journey that may potentially cause irritation and frustration. We documented various solutions to these areas that we can consider improving during the user's journey through the product. This provided us with a greater understanding of how the user's journey can be enhanced and what needs to be improved, as well as how.

Prototype

We began by individually sketching a low-fidelity wireframe on the sketch pad we had received from the product owner. We started by drawing wireframes to generate as many potential solutions as possible. After we felt done with our sketches, we discussed our thoughts on which parts to incorporate into the mid-fidelity prototype as the next step. We concluded that the best approach was to transfer a majority of the ideas into Figma to then test how different parts would work together.

What didn't go as planned?

Sadly due to time constraints there’s wasn’t enough time to conduct user tests on the prototype. I believe this could give us more insight of things we might have overlooked during the first research phase of the project. I also believe in spending more time on workshops and structuring the whole project more. Sticking to the planned time was probably the hardest part of the project but the product owner was happy with the result in the end!