Business-driven design— A UX/UI case study

Premise

I hope I can assist you in visualizing different design processes since not all projects start with the exploration of a problem, some of them start at the business end. For better or worse, this case study is an actual project ongoing at Lucy, and I believe you can gain some new insights from reading it.

Brief

A month ago, the opening whistle to my new project at LucyPlatforms was heard. As part of the company’s strategy and vision, we will introduce a new tool in our arsenal, a Diamond Price Calculator.

Plan, Design and manage a diamond price calculator application, dedicated for mobile, with future plans to reach web as well.

The team:

• Me — UX planning, First product roadmap, UI design (no brand design)
• 1 developer
• 4 board members (managers, stakeholders)

Back Story: What is a diamond price calculator?

I will explain this shortly since the main objective is the case study, and not the industry’s phrases and tools.

A Price Calculator for diamonds is a tool very similar to a regular number’s calculator, only the user inputs a few parameters (that describe a diamond’s quality) and the application outputs a price according to a large database of similar diamonds. The user then uses the shown price and makes decisions such as: should I buy these diamonds, for how much should I sell it, or where can I find this type of diamond.

Problem

Diamond companies need a combining, easy to use, application to receive diamond prices that they can rely on, finds these diamonds, share, and save results.

From user research (that we will discuss further) the tool is used on a daily base. Since the project was brought to life from the business side, the competitor analysis was half of the research effort, while user interviews were the other half.

Goals

1. Creating a price search and information visualization that is easy to understand.
2. Creating a feeling of confidence regarding the details and numbers that are shown.
3. Building an infrastructure for more supporting new features in the next stage.
4. Creating a “habit” app (A product that is used on a regular basis, with little to no effort from the user end).

How to reach these goals

1. Design the App as a “one mission” app, even when other supporting features are built — meaning the main task the app was created for will lead, and the rest is next in the hierarchy level.
2. Explaining and showcasing the partners, the technology, and the database behind the calculated prices (Social affirmation bias) in a bold but non-intrusive way.
3. Creating a design system that is aware of the next developments, menus, subheaders, etc.
4. “Habit” apps are created in a similar pattern — reward first (help the user achieve the main task as fast and as easy as possible), investment next (users will personalize, save or share results) and an external trigger (new prices, more diamonds, etc. are now available in the app notification)

My Role

This project was first introduced while I was going through a training process to become a Product Manager, but I was still in charge of User Experience and visual work. An interesting situation accrued because I was designing, but each step was also planned and documented by me, and after researching and planning I was also able to write the first Roadmap and the schedule for reviews, release, and updates with the developers.

(The full team included me, one developer, and 4 managers/stakeholders)

Design process

Our work process was as follows:

1. Introduction: since the product was first introduced from a business opportunity side, the overview of the subject and the market were all on the business side, and the User Experience side was researched later in the competitor analysis.
2. Brand, visual guide, language, and infrastructure planning: The management, alongside some major partners for this project, dictated the visual vision, the goals for the “look and feel”.
3. Prototyping: Since competitors already introduced the basic flows to the market, we could attach the selected look and feel to a basic prototype, in order to gain early-on insights from users interacting with the product. We were also fortunate enough to have management members that are diamond industry members themselves (we did not rely on them for major decisions, but we could move a bit faster on simple user experience and information structure questions)
4. Iterations: After conducting user interviews (via Zoom, since the Covid-19), we received some important feedback, and implemented it on the new prototype.
5. Development: In this stage, the design met code, adaptations to smaller and wider screens were made, and a closed beta was released for testing.
6. Beta: (A currently ongoing process) The team is currently testing the app flow by flow, a few links were given to a handful of users, and we are gathering further insights before a public launch.

User research

Who is this for?

The Calculator app is made for our regular company target market — Diamond industry members, but more specifically- diamond stock owners and brokers. Both of these user types have the constant need to be on top of the price to each of their diamonds in stock.

Both the broker and store owner have the same 2 main pain points to be solved, and although it accrues on a different journey and daily work, the same usage was detected from interviews, therefor both are treated the same at the MVP point of time.

User flows

I mapped out the features the stakeholders and project partners discussed as the most important business-wise and added some features that early user interviews helped discover.

Ideation + low fidelity ideas and wireframes

Once we gained a clearer picture of our users, we began bouncing off ideas from the business side and from the technological side, in order to make the experience for the user far supreme from what they currently know.

Since we had the competitor’s work to start from, we were able to start with mid-high fidelity mockups quickly, so we can show them to potential customers and get fast insights.

Designing with Data and other cookies

Working in a startup usually means that designers face a very fast work pace. Giving this fact I recently gave “VisualEyes”, a smart attention and clarity test plugin a chance. (read a really interesting case study using VisualEyes here)

My very first test with this plugin was simple: Which of the following navigation options drives more attention? here’s what VisualEyes found.

Thanks, VisualEyes!

As you can see, this is where design meets business — on one hand, the clarity level is higher on the left version, but the right version has other features way more visible.

Prototyping and testing

Since the visual guide was already closed, all that was left is to prototype the basic flows and test it on users.

User testing in the COVID era

The potential user interviews were amazing, when you give the users a positive feeling and make sure they understand that they are not being tested, it is the app that is tested, they immediately want to help.

Quickly into the interview, I gained more perspective on the importance of the process- what happens after the user finished using the main feature of the app? what is the importance of staying up to date with prices?

Iterations

After discussing the interviews internally, we iterated to a more visual version on some features, after realizing the users did not see clearly enough the diamond search feature.

Once we tested all the functionality and the flows, approved the iteration with the team and stakeholders, it was time to ship to development.

Next phases are:

• Rebrand application with the web version (DPL).
• Receive user feedback from the soft launch and research iterations.

Conclusions on designing from the business side first

Learnings

1. Progressive disclosure — Originally researched by Jakob Nielsen (in this article), Progressive disclosure is a very efficient way of letting your users get the most of their 2 main desires when firstly interacting with a product: simplicity and power. Putting it simply, PD is the act of simplifying flows, and gradually adding more functions, edit options and functionality to those flows.

Progressive disclosure

1. “Compromising” for the user is not compromising — Initially in this project, I was confused with why diamond industry users do not prefer identifying diamonds with a number (just like an item number in clothes stores). After speaking with some industry members I realized that diamonds have less of an individual value, but more of quality value. As long as the values are as needed, they do not need anything else (plus there are so many similar diamonds, that there is no value in identifying them). The point is that you should take advantage of users' habits and culture uses, and improve and educate with time, not straight away.

I tried to help out, they didn’t need it.

1. Always understand the capabilities and limits of the technology used to develop your products — Native or web, ios or android, react native, swift UI, etc etc. Please take time to understand limitations regarding development technology because they might concern you. For example, we had some micro animations limitations while developing, and since the development method was chosen by our CTO, I couldn’t change this fact and had to adapt and get the most of what I have.
2. Handoff during Covid-19 — All I can help you here is this: Be patient. Be patient with developers, stakeholders, and users. It’s harder to convince and research and share ideas. We all go through this and we all need patience in order to keep building great products.

Stay safe!

SH