UX Designer & Researcher
UX Project- Web
Redis

Project Overview
While completing my academic degree, I interned at Redis, a company that developed an open source, in-memory data base.
The purpose of the internship was to examine two flows and develop a possible method to score each development process. Afterwards, we chose one flow and redesigned it according to our research.
Research And Conclusion
3 Goals:
Examine 2 main flows
Creating grading system
Propose improvemnts
Types Of research
Exploratory
In order to get to know the process and understand it in depth, we have experimented extensively with both flows from start to end.
When we identified what we understood about the processes, along with what we didn't know about them, we asked for lots of data. This was to get a better understanding of the flows.
​
Explanatory
Identifying potential pain points was the next step. We wanted to know their scope, where they come from, and what can be done. Our research aimed to answer the following questions:
Flow 1: New DB:
-
Why do senior users have a significantly shorter time to complete the process than new users?
Flow 2: Upgrade Plan:
-
What is the more common reason for upgrading a program - the need for additional DBs or the need for additional storage space?
-
Why don't users use the system's recommendation for an upgrade plan?
-
Why do many users tend not to finish the upgrade process?
​
For both flows, we performed:
-
Analytical research using quantitative data
-
Evaluation with heuristics- We combined the SUS scoring method and Nielsen's 10 heuristics and created 9 questions with the usability principle (The "flexibility of the system and its efficiency" heuristic was irrelevant to the processes, so we did not create a question for it).
New DB: Usability Test
The research question is: "What kinds of problems can arise during the process of creating an existing DB, assuming there is a subscription?"
Preliminary assumptions:
-
Users will look for the "Activate" button at the end of the process at the bottom of the page, according to their existing conventions.
-
Users may have difficulty finding the "Connect" button due to missing secondary buttons.
-
Users will need additional and more in-depth explanations of concepts from Redis content worlds (modules), compared to common concepts in the field.
​
Upgrade Plan: In-app survey
​A survey that popped up for users immediately upon upgrading the plan, included 3 questions aimed at "talking" with users in a broad way and learning in this way about the user experience and problems that we may not have identified ourselves. 27 users answered the survey.​
In-App Survey Results:

Did the recommended program
help you choose?
No, I didn't saw
the recommeneded program
Yes, it helped me

How easy was it to complete the process
Other
I ran out of storage space
I used up the DB allwed in my existing plan
How easy was it to complete the process?
The average grade is 4.07

Very hard
Very easy
Conclusion From The Research
-
The more a user moves between programs, the less likely he will upgrade the program.
-
There is a problem with the system orientation.
-
There is a problem with the amount of information on the upgrade page.
-
It is possible to "upgrade" the existing program, which may cause confusion among users.
-
There is no satisfactory indication regarding the program upgrade.
Findings - 4 Principles:
Frequncy
We gave a non-numerical grade to better reflect each process' frequency in clicks. We created our own order scale, based on the Likert scale, which describes in words the frequency of use of each process. As you can see here:

0-10 = almost never
11-100 = very rarely
101-500 = rarely
501-1500 = occasionaly
1501+ = frequently
Usability
Each heuristic is given a score with expert evaluation and finally an overall average score. For instance:
-
The flow provides clear and timely feedback about its status and any changes happening.
-
The flow uses language, concepts, and workflows that are familiar and consistent with what I expect.
-
I felt in control while using the flow and had the freedom to navigate and easily undo any actions.
-
The flow follows established design patterns and industry conventions, making it easy for me to understand and use.
Criticality
For both flows the criticality is defined as high. This was given as a fact at the beginning of work.
Similar to frequency, we realized that the most effective way to reflect the degree of criticality of a process is through an order scale rather than a numerical score.
Represented by shape

Dicoverbility
For both flows, in the expert evaluation, there was no difference in this principle.
We decided to represent this parameter using a color shade. The darker the shade, the better the ability to locate the starting point.
Represented by color

Summary of the principles:
Flow 1: New DB
-
Frequency: Almost never
-
Usability: 3.4/5
-
Criticality: High
-
Discoverability: 5/5
Flow 2: Upgrade plan
-
Frequency: Rarely
-
Usability: 3.3/5
-
Criticality: High
-
Discoverability: 5/5


Hence, before proposing solutions, we defined the problems for which we will implement characteristic solutions. For this purpose, we divided the problems into three categories:
-
The accessibility of the information
-
System status indicator
-
Error prevention
Solving the Chosen Flow
The flow chosen was the plan upgrade flow.
In the solutions phase, we made several small changes to make the user more confident. In addition, on the upgrade page we made a significant change.
​
From this:
To this:
To this:


Comparison:
We separated the "current plan" part into a window separate from the table of plans proposed for change so that they appear side-by-side. This way, the ability to compare the current plan with the potential plan will improve. The need to switch between proposed plans will decrease. As a result, an upgrade to the same plan will not be possible.
​
Info:
The information displayed on both screens maintains a uniform pattern. This is so that the order in which the information appears is preserved. This makes scanning the items easier and faster.
Following this, we have added the amount of DBs allowed in each plan to the tabs appearing in the table. This is so that the user can get the information in a quick scan without switching between the offered plans.
According to the mental model of a button, we changed the function of 'availability settings' to a toggle in order to have more click visibility.

The Next Steps:
Analytics:
-
Check how long it takes for a new user and an experienced one to upgrade their plan.
-
Finding how many users perform “shopping” after the UI change and compare that to the statistics of the old UI.
-
How many users picked the recommended plan without pressing on it.
Usability Test:
-
The user will identify a problem in one of the subscriptions and upgrade to a different plan.
Eye Tracking
-
How many users look at the part of the page where the current plan and plan usage are presented