How do we prioritize large amounts of data that is both accurate and meaningful to our users to improve their workflow without overwhelming their view?
The Ruvixx platform works by scraping the web for any piece of data that could relate to the client's product, IP, brand, and even contracts or partnerships. This means, we'd have a lot of data points- that individually may seem insignificant - but together, may reveal a larger story that could prove significant to our users.
Ex: a reseller is selling a component outside their contractual region by reselling lesser known stores. Perhaps this isn't a huge red flag, but what if that reseller was selling to 100 lesser known stores?
Companies & Entities
that have a brand or a licensed intellectual property that they want to protect against infringement by deploying their own teams to monitor via manual analysis.
Company structure is highly variable. But if there is a licensed IP that needs protecting, companies will have their own teams to manage that goal. This can be in the form of managers, data analysis, lawyers, and strategists.
UX/UI Designer (me)
VP of Product
Web Developer Team
Our company was around 10 people. I worked primarily with the VP of Product for user experience and interface needs and provided specifications and mocks though Jira tickets and GitHub threads when passing my work off to developers.
Discover & Define
When thinking of Ruvixx 2.0, the team wanted a feature that could set them apart from the competition. What could we accomplish that other platforms could not? What features were lacking in our current platform? Honestly, the core functionality of the platform was already pretty good. Like other tools, we already had the ability to data scrape and funnel relevant information to our users. But the way that it was presented and organized is what was the issue.
Using the VP of Product's analogy, data scraping is like a mining process. It takes repetition to mine the data, then refine it by organizing it into different buckets (the buckets being defined by our users on how to filter the data scrapes). We worked on this through multiple whiteboard sessions, trying to solve when to surface data scrape results within our platform. What if there was an easier or faster way users could skim the results page so they wouldn't have to waste time, shifting through all the results? How can we get our users to feel more confident in the viability of results they do see?
I started to sketch out rating systems of results - relying on color and a rating scale so users could easily identify viability (or "Signal Strength" as it was first called) without having to scroll through a bunch of lists. We started to discover more potential with the tile layout and started to define what we should display.
SIGNAL FEATURE ASSUMPTIONS
User is somewhat familiar with the processes around infringement cases
User is somewhat familiar with violation types (infringement, contract, revenue reporting, etc.)
User will want to find a specific thing on this page to create a new incident or add to a current project
User will want to convert as many relevant signals to an incident or project
WHAT INFORMATION SHOULD WE SHOW?
When thinking of the core pieces of data that could be used to define standard types of infringements, we whittled it down to a few essential pieces of information:
Product/IP (the “what” is being infringed on)
Violation (the “how” it’s being infringed on)
Entity (the “who” is responsible for this infringement)
The goal of this design was to capture relevant information about a data point and stitch it together to show our users the full context of said data point. A secondary goal was to allow our users to take actions on these data points in a quick and manageable manner.
We decided on these components of a "Signal" tile to show in our initial wireframe: Signal #, Location, Violation, Brand, Model, Entity and Entity role. I added filters in the sidebar to make it easy to find signals, so users could slim down the results of our data scrape (instead of viewing thousands at a time). I created a drop zone to bulk-capture Signal data into an incident or project so users could instantly capture which Signal tiles are important to them and would require further investigation.
But why was all this data necessary to show? Assuming we were working with users who were familiar with this workflow, all contextual data could be important. An example of this can be seen in the wireframe: "Signal #2998". We can gleam that Sony, who is the distributer of Lenovo ThinkPad Y Series in China, is showing an unusual negative trend in royalty reporting revenue by 7.5-9%. If the user just so happens to be working on an infringement case regarding Sony and that product, this signal could be a valuable addition in building a stronger case against Sony as the target entity.
After a few refinement cycles, the signal row evolved into a signal tile. We got requests to include more information - and eventually we were asked to include as much information as we could. To our users, the more information we could show, the better.
PRIORITIZING DATA FOR SIGNAL TILES
Following our general re-design for the platform, our team started to speculate further on the design for the Signal Tiles. I worked with the VP of Product and chatted with other stakeholders in our company to understand the viability of the type of data we can scrape and show our users and how to prioritize in a "tile" view. We already got feedback from our customers, that more data is better and it was our goal to make big data look good.
The hierarchy made sense to list the Signal ID, followed by the violation reference # (which would display a summary of the violation in a tooltip when clicked), with icon buttons in the right corner where users could show more information, edit filter rules for this type of signal, or hide this signal.
The shaded bar below shows the product and product owner, with more contextual information on what type of incident this signal is and what category it falls under. I felt it was necessary to have “incident” type so users could easily organize their signals into incidents based on this type, but found this repetitive when using it in conjunction with “signal category”.
I approached this second iteration by relating the signal to a book, and the signal tiles as the book cover. How could I organize the information so that users could take the least amount of time to gather the whole story? I treated the header as the book title, comprising it of the entity (“the protagonist”) and the violation type (“plot summary/hook”).
From the information below, the user could tell what product is being used in violation, the role the entity plays, and where this information was sourced from and any incidents or projects it’s currently attached to. We added a “Status” and a “Score” where status describes the whether or not the signal has been acted upon, and score describes how viable or reliable this signal is. The red bar is meant to relate to the signal score, but we found this was too subtle for users to understand.
The final iteration brought a numeric value to the scoring of the tile in addition to making the score colors bolder. The placement and abbreviation of the score made this tile easier to scan for users. I also reduced the header content to show the target entity and their role in a tag, with the status and signal ID # and a collapsed menu.
Below, a photo of the product is featured (icon images would be used in place of photos if no photos are available), with contextual information around the product, contract, violation #, source, and incident or project information. There is substantially more data here than the first iteration, partly due to what we felt was needed to make a well-informed decision.
While the type of violation isn’t as obvious (it’s now a reference #), I felt it was necessary to prioritized overall signal score to give users a dependable way to judge the viability of the tile. Since Ruvixx would ideally house contracts as well, I wanted to link contracts that might reference this signal so users had a tangible source of information within the platform that they could reference, should they take this signal through an incident or project pipeline.
Modifications & User Feedback
As with any evolving product, constant iterations happen as we gather feedback from our users. We learned how users interacted with these tiles and what information they expected to see there. After gaining feedback from our in-house clients and legacy users, we modified the tiles to better suit their needs.
For example, we added more types of actions a user could take with a signal tile – they didn’t just want to create incidents, but also needed a way to create a new project and add signals to existing projects and incidents. Since signals are created from new data scrapes, it made sense that users would want to check back to this page to see if anything relevant popped up that they could use in their current cases of IP violations.
To me, one of the more valuable modifications we added is the “Filter by Similar” filter which will take a tile and show all relevant tiles by matching the target entity, similar scores, IPs, and statuses (these rules are customizable). If I were a user going after a company and only wanted to create an incident for a certain IP from that entity, this filter allows me to find all the relevant signals in a single click.
Another piece of feedback we got from our legacy users was to make it more traditional so they wouldn’t have to stray from their original tools and methodologies. Not wanting to re-invent the wheel, I added a toggleable view so users could view the signals list as a spreadsheet or as tiles. Overall, I believe this feature was a success. We improved previous workflows of our users while introducing a product feature that has become one of Ruvixx’s main selling point.