Correspondence & Cluster Analysis

After about 15 hours of interviews across our stakeholders, developers, designers, leadership and account managers, we were able to define our problem statement.
‍

As Correspondence and Clusters is two features in one, I am going to have us focus on the first part of the goal. "Users need to be able to create unique groupings of people". This is where Cluster comes in.

Cluster takes items and separates them based on characteristic that are similar to each other. In our example below, each object has an attribute such as shape, size, and color.

Group 1: Shape

Group 2: Size

Group 3: Color

There are better and worse ways to group these. Cluster analysis is about showing the most variety with the fewest groupings. As you can see above, Group 3 shows the most amount of variety in the set with the fewest groups.

When you apply the cluster to people, you are able to get groups based on common characteristics. Group 1 loves hikes, identifies as male, loves camping. Group 2 on the other hand dislikes the outdoors, identifies as females and invests in computers.

With that in mind, we can see that Clusters grouping ability addresses the first part of the challenge, but that then leaves the second part. Lets take a look at our problem statement again.

Correspondence needed to address the second part of the statement. "[Users need to] chart those relationships against their brand". With that in mind, lets take a look at Correspondence mapping.  

Correspondence takes items places them in a space based on their common or distinct traits in relations to each other. 
This can be demonstrated if you think about a cube.

This cube’s shape will be defined by how different or similar an item is to another item.

If we take two pearls and place them in the space, the cube would be created based on their different characteristics. Pearl 1 is a white pearl, it has a lot more shine, it tends to be much more common. Pearl 2 is a onyx pearl on the other hand are much more rare, they are more expensive. As they are different in everyway, they are placed on opposite sides of the cube.

This same concept can be applied to the groups we defined earlier in cluster.  

When we plot them inside the cube based on the different characteristics that they have, they get placed on opposite sides of the cube.

Next we can place brands in the cube and see how those brands relate to each other in the space.

We will add Patagonia, REI, Apple, and Microsoft.



Items that are more similar to each other are plotted together while items that are different, are placed further away.

When you start to plot this kind of thing in real life, the shape is not always so simple. It tends to be more of a galaxy shape as the space is created based on how each point added relates to each other. This means if we have 100 different data points, all with unique characteristic, this will create a unique shape based on these relationships.

Now that I understood he principles, it was time to talk to the users again, I wanted to make sure I understood what the product currently did and then iterate based on user feedback.

Next up, as this was an existing product, I needed to be able to see how people were currently using the product and what their pain points were. To get started, I planned out interviews with current users which task observation to see where new and existing users would get stuck or had trouble understanding. I also ran a Heuristic evaluation to see where things were going wrong (or right).  

The first part of the application was actually getting the data into the module. This piece was known as Composer.

Version One of Composer had a lot of known issues, but luckily, we had a Version Two component built before the start of this project initiation. The only pain point we needed to address was being able to set items as "passive" when adding the items and the requirement that they must run the application with 6 data points when only 3 were required.

Next part of the rework was Cluster. Noted by the users interviews and in evaluations, a big pain point was the amount of information on the page. There was the left control panel which housed tools for both correspondence and cluster, the segment summary, which housed a bit of information about the group selected, and then the segment comparison which showed all data that had been added.

While reviewing I also took a look at the Laws of UX. A few stood out right away, Millers Law, Hick's Law, and Von Restorff effect. Millers Law states that "The average person can only keep 7 (plus or minus 2) items in their working memory." which raised the question, how many elements are on the page? At a quick glance we had 13 separate sections displayed BEFORE we scroll down on the left control panel. Combing this with Hicks law, we needed to "break complex tasks into smaller steps in order to decrease cognitive load" it became clear that we needed to address this in structure review. Lastly there was the Von Restorff effect which distilled is to "Make important information or key actions visually distinctive." On our page, the heaviest use of color was the segment comparison, report which was actually the least important item on the page. I noted that this needed to be addressed in the design phase of the rework.

Last but not least, we have Correspondence mapping. Users identified challenges with using the left control panel holding tools for both cluster and correspondence, labels only being able to be dragged vertically, the Axes Display, Performance model, and chart settings being confusing.

With the list of pain points compiled it was time to look at the flows of the modules. First up was Composer (getting the data into the module). The main pain point addressed here was that a minimum of 6 total data points were needed to run the module.

In Version 1, the decision was made to require the user to run a minimum of 6 items. By doing this, it generated both a Correspondence map AND a Cluster Grouping. Correspondence mapping requires 6 data points to run while cluster only needs 3. But what if Alex only wanted to run Cluster? As Cluster requires 3 data points, users tended to be very confused as to why they would need to add 6 if Cluster only required 3.

To solve this pain point, my hypothesis was to get rid of the requirement that users must have a minimum of 6 data points and allowed them to have 3 minimum. If the users wanted to also see a correspondence map, all they needed to do was add more data. They no longer were restricted. After testing my theory of this solution with users, we found this was a success!

Next part to tackle was Cluster. As noted by "Alex" and our UX laws: Millers Law, Hick's, we needed to needed to reduce the amount of information on the page at one time, focus the user on the most important information and allow them to make course corrections as needed.

My first hypothesis was that this could be solved by splitting the Left control panel into Cluster vs Correspondence tools, showing only tools that were needed for the module and to break the module into Data View vs Cluster View.  This produced round 1 of structure flow.

After some testing, users made it clear that it needed to be split further into "Cluster Solutions" and then "Solution Breakdowns", which would further reduce the load on "Alex". Users could focus first their first task choosing the group and then focus on analyzing the breakdown of solution, rather than trying to solve everything at once. This lined up perfectly with what we know about the UX laws: Selective Attention and Von Restorff. Both effects in essence limits the amount of information presented to guide users’ attention, prevent them from being overwhelmed or distracted, and help them find relevant information or action. As we knew that's what users were facing, we went with the following structure solution.

Last part of the structure broke into two parts, Correspondence map and Data view.

Keeping the pain points in mind from the our first rounds, we added a 3d map view, tinkered with what was shown on the left control bar and how the axes were displayed.

While the users loved the idea of a 3d map and it fit perfectly with their needs, ultimately timelines and useability concerns from our stakeholders meant we needed to cut the 3d map.

With the structure of the modules and a few initial pain points addressed for "Alex", it was time to get to sketching. These rounds involved sketching, A/B testing, reviewing with the design teams, and testing with users.

First round of design and refine was on Composer. We knew most of what we wanted to address from the research performed which we were able to then apply here. As a reminder, composer looked like this before.

As we had addressed some of the pain points in the flow and structure of the module, in this pass, I addressed how a user might know what is required for the application to run. If a user was a power user who knew exactly what they wanted, they could proceed without any additional information being displayed to them.

However if it was a new user and they ran the report without the required data, indicating that they did not know what they needed to run the module, users would see an error indicating what was wrong and an information icon. They could hover on the information icon, they could see additional information about the requirements. This decreased the overall unease that people felt about their lack of knowledge and empowered them to use the module with less fear.

As an additional quality of life additional, inside the module, if a user didn't have enough information on the page, they would have a small note indicating what was required to get started.

Next up in the rounds of Design and Refine was on Cluster. Similar to Composer, I was able to address some of the pain points such as too much information on the page in the structure. The next pain point to address was the visual breakdown of each clusters.

In my first design pass, really took to heart the need of visually seeing the cluster and how each group made up the overall view of cluster. I also played around with the idea of having the solution breakdown as a pull up window from the bottom so users could easily swap modes. This pass also kept the "save solution" as a option in the breakdown.

After testing, I found that users were confused with the breakdown being at the bottom of the page and that that was were they needed to save the solution for use. However, they loved the visual breakdown of the groups and wanted to keep with that theme. After several more rounds of testing and validating the results I landed on the final solution.

This solution leaned more into the Millers and Hicks laws of UX, allowed for a visual breakdown of the groups, and allowed users to easily save their solution. Solution breakdown was placed on its own page which didn't end up needing much rework. While they did go through several rounds, it ended up being minor.  

Last part of Cluster was the Segment Comparison, renamed to data view. This part of the module got a UI update which consisted of color changes, size enlargement, and text updates to fit with the style of the platform.

Last but not least was on Correspondence. Similar to all other parts to the module, I was able to address some of the pain points in the flow and structure. Last pain points to address for the user were the ability to move the data points in any direction, performance model design, and left control panel adjustments.  

Keeping in mind the pain points, I staggered the labels based on the quadrants they were in, allowed users to have easier access to the chart settings, and adjusted Axes display to include the "Model Performance" into the solution itself. After several rounds of testing, we ended up with the solution you can see below.

I broke each feature down, building a list of questions to answer with the stakeholders. I would come each week with a new part of the feature I had broken down. I would discuss with various groups (from developers, to data scientists, to account managers) the questions I had and would get feedback and make changes as we went. Once those questions had been answered, I would write up developer tickets to be planned for future sprints, ending in over 300+ tickets. Next step on the list was planning out each sprint to ensure we were able to make our deadlines. I broke each section down into manageable sprint cycles, collaborating with developers to get an accurate read of the project.

After the planning, came scrums and development which came with collaborating with developers and overcoming many challenges. Finally after months of work, lots of collaboration and just a few tears, we were able to launch the new V2 version of Correspondence and Cluster!

Post project, I continued to iterate and update based on feedback we got from clients but as a whole, the project was a huge success. We had a massive increase in usage of the feature, new users signing up, and a ton more traffic through the feature. I learned so much throughout this project but here are some of the key takeaways:

♡ UX Laws can make a huge difference as to whether an application is useable or not.

♡ In some applications, Tesler's Law will come into play. This law states that "for any system, there is a certain amount of complexity which cannot be reduced."

♡ Talk with your stakeholders frequently throughout the project. It will save a ton of time in the long run if you make good relationships with them. You will learn more by asking rather than assuming.
‍
♡ Take notes. They save lives.
‍
♡ You and your team got this.



‍