Background:

I own a jewelery software consulting firm that I use to take on new and interesting projects when I am in-between jobs. I currently have about 10 contractors that I work with off and on.

This was contract work for an upcoming jewelry consulting company Envvia. The core mission of this company is to partner with small to midsize jewelry brands/designers in Asia to promote and sell their products for commission in the US.

Problem:

Envvia is composed of approximately 20 jewelry sales consultants. These consultants are very experienced, with many years in retail. They also have a long list of high-value clients with whom they have developed relationships over the years.

Envvia also has two administrators who source jewelry and precious stones for the consultants to present to their clients.

The problem they were facing was one of scale. Most communication was done through email, texts, WhatsApp, and WeChat. This communication style worked fine when they were small, but as they grew, it became overwhelming quite fast.

They reached out to us to build an admin portal that would help them manage their inventory, share products with consultants, and streamline their workflows.

"Basically we augment our jewelry partner's sales teams. To do that, we need to manage the products of many brands. We need to find things fast. We need to stay organized.”
Sophia - Founding Partner

To manage this global sales team, Envvia needed a product inventory solution that allows their consultants to quickly find jewelry based on the specific tastes of their clients. A bonus goal was that this solution would also help consultants conduct personalized outreach.

Team Building:

At this time, my usual go-to designers were busy with other project work, so I had to build a whole new team.

One major factor in this project was that the company is based in Hong Kong and worked with jewelry companies there but sells mainly to the US. These US customers were often Chinese Americans or immigrants from China. This meant that I’d have to hire someone who really understands the buying habits of Chinese luxury consumers as well as the behaviors of non-Chinese consumers.

The candidate I eventually settled on had a good deal of experience leading small teams, as well as a strong background in user research. Research was important because Envvia’s approach was unique and aimed to be disruptive in the jewelry industry.

We would hire the other three designers later, after the discovery phase. For now, my new hire and I needed to develop a research strategy to learn more about this particular use case.

Discovery:

The target jewelry designers that Envvia works with are based in Hong Kong, one of the most active cities in the international jewelry trade. We started our research by going to Hong Kong and visiting two of the biggest jewelry shows in Asia; The Jewelry and Gem World Exhiition and The Hong Kong International Jewelry Show.

Here we had a chance to talk to many jewelry designers (There were 500+ exhibitors for each show) as well as talk with Envvia founders about their goals, history, and motivations. From this, we created very representative personas of all participants in this concept.

The two personas I will address in this case-study are the Envvia Admin and the Jewelry Consultant. The end consumer is also a persona but the scope of this case study will be about the admin side of the application and their interactions with consultants.

Persona #1: Consultant

The Consultant will browse the inventory and share items of interest with their client. They are the front line of Envvia. Their clients are high touch with high expectations. They often need to find unique, expensive inspirations quickly.

Persona #2: Admin

The Jewelry Admin's jobs is to be constantly be adding to inventory as well as supporitng consultant's requests. They will have a large network of sources for stones and jewelry. Searching through products efficiently is paramount.

Competitive Analysis:

Envvia's model is very different from the traditional way jewelry is sold. There is on retail store and much of the initial conversations happen online. We reviewed all the major online only jewelry retail companies to find out what they did well and where they were lacking.

At this point, we had a good understanding of our users goals, their pain points, and the domain that we’d be working in. We were confident that we could get started on the architecture.

Information Architecture:

To make sure we captured all the required functionality for this project, we created a product requirements document and used that to make the high level information architecture. Throughout this, we met regularly with the stakeholders at Envvia to ensure we were on the right track.

The complexity of the project grew, but we knew we would trim the fat by the end. Just as I suspected, this would actually be two apps that communicate with each other via an API. The reason being that the consultant side would also function as an online store for their clients. This meant it could not have the utility style of the admin portion.

As we were desigining, the dynamics of Envia's operations were changing due to them being a fast moving startup. Our flexible, agile approach allowed us to keep up. During this phase, we hired 3 (1 in Malaysia, two in India) more designers to do the actual design work. One would be assigned to the consultant side while the other two designed the admin side.

Design:

Over the next few weeks, we designed, tested, and iterated repeatedly. We really leaned heavily on prototyping because Envvia was adamant about getting the experience right before we sought out developers. I wholeheartedly agreed with this approach, as it is much more cost-effective than designing as you build.

At this point, I had returned to the US, while the designers remained in Asia. This meant many late nights for me, as I scheduled all meetings to be convenient for them. Communication was essential as we were working across several different time zones.

Technical Architecture:

As Envvia’s business model continues to adapt, I knew that developing the project would mean we’d have to pick a tech stack that is easy to set up, quick to change, and capable of scaling.

For this, I chose to use NextJS on the frontend, which is a React-based, server-side framwork. Styling is done with Tailwind CSS. It talks to the backend using a REST API. The backend is built on top of Strapi using a Postgres database. Strapi is a CMS built for quick prototyping, allowing us to tweak product info and user flows without having to hire developers each time.

This cut the development costs by 35% from the original estimate.

Conclusion:

As of this writing, development is currently underway on the Admin side. I’ve built a simplified version of the consultant side that doesn’t have all the features we designed, but it is enough for Envvia to at least conduct business until the development team has completed the admin side.

Though the project is still ongoing, it’s been a very successful and is used daily by Envvia.

Next Case Study - XiongMao Language Learning App >