BOM Doctor.
Lead UX Designer
Jan - Aug 2022
Web Application
Skip ahead
if you already know what dependencies and vulnerabilities are.

What are dependencies?

A dependency is a piece of code (also known as a component), that you have imported into your project. Typically, these components are developed by companies, or communities of people collaborating together.
This means that you are bringing in code that you do not maintain yourself.
Your Project
you've imported an
Open Source Component.
You use their code in your project and are now dependent upon it.
This is called a direct dependency.
Open Source Component
you imported,
will also import:
Component ABC.
You are now dependent upon something that you did not import yourself.
This is called a transitive dependency.
It gets a bit more complicated...
We have now imported:
Component ABC.
Component XYZ
also imported
Component ABC.
This is called a circular dependency.
We now have multiple components that are dependent on each other. This will be more relevant when we look at vulnerabilities in the next section.

What are vulnerabilities?

A vulnerability is a piece of code that has the potential to effect our project in ways we didn’t intend it to. We want to avoid vulnerabilities!
A component that you import, could have a vulnerability risk associated with it.
There’s a vulnerability in
Component XYZ
Since there’s a vulnerability in
Component XYZ,
and we've imported:
Open Source Component,
which then imported:
Component XYZ,
Your Project
now also has been exposed to a vulnerability
Avoiding vulnerability risks is important, but understanding where vulnerabilities come from, can be very difficult.
If you do not know all of the dependencies in your project, then resolving these vulnerability risks is even more difficult. That's why we are trying to help developers see their projects as a wholistic picture.

What were we trying to make?

An experimental application to help developers quickly assess all of their dependencies and improve their project.
Enable developers to see how all of their dependencies are connected.
View key metrics regarding how your whole project and each component is performing.
Receive feedback on how to improve your project and each component.
Summarize and export your actions to improve your project.

Visualizing dependencies

Comparing methods of visualising dependencies and analysing how they can help developers understand the relationship between their dependencies.
We have 5 components in this example:
We also have 7 connections between these components:


Shows each component in a list.
Easy to quickly read component names
Doesn’t show any hierarchy
All dependency relations are not viewable

Tree List

Shows hierarchy between components, but circular dependencies are shown multiple times.
Great for visualizing linear dependencies
Components A, B and C exist multiple times
Hard to see duplicate items when the list is very large.

Tree Graph

Graph showing all connections and showing only one of each component.
Circular dependencies are viewable
Can see a lot of connections in a small area
Graph can be very busy
Difficult to see individual connections when there are a lot of connections

Tree Graph with Focus

Same as above, but the user can also select an individual component and only see connections related to that component.
All depenendency types are easy to view
Focus on one component to see all of its connections
Easy to see connections

Defining the Data: What do users want to see?

The user needs to be able to quickly determine which dependency needs attention. We did some exploration to determine how much data needed to be shown for them to take action.
Here are some of the designs we explored for nodes on the tree graph.

Determining what users want most.

After some testing, we created a refined list of the most important data to display on each component in the tree graph.
Full Data List
Refined List
Component Naming
Name of component
Version number
Name of component
Version number
Overall score (out of 500)
Security score
Popularity score
Licensing score
Overall score (out of 500)
Security score
Popularity score
Licensing score
Upgrade available
Vulnerabilities present
Upgrade available
Vulnerabilities present

The Full Tree View.

After the research was complete, here are some final examples of the tree graph.


Finalyzing the styling of each of the nodes in the graph.
Iconography is used to convey when:
An upgrade is avilable for a component
An upgrade is applied automatically without the need for human input
An upgrade is applied but may have issues that need human input
Components are scored on a scale out of 500.
The colour for a lower score has a higher contrast to gain the users attention.

Default Tree View

Here is an example of what the nodes look like in the context of a larger tree view.

Filtered View

The graph can be filtered based on different criteria (here we’ve highlighted scores 150 and below). This helps the user quickly determine which components to focus on.

Selected Node View

Once a component has been selected, all other components that it is not directly connected with become less visible. This helps the user focus on the context of the component that is selected and visually block out the rest of the graph.

A Full Look at our User Journey

List of the core steps to the experience of the application.


Upload a file or link that represents your project, including all of its dependencies.


You can now view all of your dependencies and see how they are connected, and filter if necessary.


Select different components to see their details.

Take action.

User can see when an upgrade is available, and quickly improve their score.

Take it home.

Export a upgraded SBOM and import it into your project.

The Full Picture.

A final example of the full UI.