Redesigning My Resources

The problem: having the information isn't always enough

Imagine you're responsible for managing your organisation's Internet number resources.

You open the LIR Portal and find your IPv4 and IPv6 resources and Autonomous System Numbers (ASNs). The information is available, but how do you know whether everything is correctly registered?

Are all the assignments registered? Do the parent and child resources reflect how the address space is being used? Are the prefixes announced as expected? Is there anything that needs updating in the RIPE Database?

Answering these questions can require technical knowledge, navigating between different tools and knowing exactly what to look for.

This was the starting point for our redesign of the My Resources page. We wanted to go beyond displaying information and help members understand the current state of their resources, identify situations that deserve attention and know what to do next.

From a list of resources to a clearer picture

One of our first challenges was finding a better way to represent resources.

IP resources are not always independent entries in a list. An allocation can contain sub-allocations and assignments, each with its own registration information. The problem is, a flat list doesn't always make these relationships easy to understand. So, we introduced a tree view to make the resource hierarchy visible.

In this view, members can expand allocations, explore more specific prefixes and understand how resources relate to one another. Selecting a resource opens a side panel containing its registration details, utilisation information, RIPE Database objects and routing information. Basically, the tree provides the bigger picture, while the side panel offers the details needed to review an individual resource.

The design also needed to support organisations of very different sizes, from those managing just a few resources to members with extensive hierarchies. Supporting large resource hierarchies introduces its own technical challenges, as running automated checks across every parent and child resource can require a significant number of API calls.

Working out how to solve this has meant thinking about how to balance performance with transparency, especially when some child resources have not yet been checked. Indeed, this raises an important UX question: how do we avoid giving members the impression that everything is fine when the system hasn't checked everything yet?

It's a challenge we are continuing to explore as the design develops.

Helping users understand what needs attention

Making the hierarchy clearer was only part of the work. We also wanted to reduce the effort members spend manually checking whether their resources are correctly registered and whether any information might need updating.

To support this, we introduced automated resource checks that highlight situations requiring attention. Depending on the resource, these checks can identify situations like the following:

• IPv6 allocations that are announced but have no registered usage
• IPv6 assignments that are smaller than the expected assignment size
• Allocations with registered assignments that are not announced
• ASNs that are not visible in the BGP routing table
• Address space in use that may require additional assignment registration

Instead of leaving members to discover these situations themselves, the interface brings the relevant information together and highlights what may need reviewing.

But identifying something is only the first step. A message saying that something needs attention is not particularly helpful if users don't understand what it means or what they should do about it.

We therefore designed the notifications to explain what was detected, why it matters and what action may be needed. The aim isn't just to display more warnings, but to make it easier for members to understand the information and take the appropriate next step.

Not everything unusual is an error

One of the most interesting UX challenges came from routing information. Initially, it seemed reasonable to show whether a route object was present or missing - but routing isn't always that straightforward. A route object doesn't necessarily correspond exactly to an allocation or assignment, but can exist for more specific prefixes, covering prefixes, or different routing configurations.

Therefore, displaying a warning simply because an exact route object was not found could be misleading. A member might interpret the message as a problem requiring immediate action, while in fact the configuration could be perfectly intentional. This forced us to rethink an important part of the design.

The interface should distinguish between a condition that the system has detected and a problem that has actually been established.

We started separating actionable review items from information that requires interpretation. Rather than automatically labelling every missing exact match as an issue, the interface can show a neutral message such as "No exact match found", accompanied by information explaining the possible reasons.

Related route objects can be displayed in a hierarchy, allowing members to understand how prefixes and origin ASNs relate to their resources. This makes the page more transparent without creating unnecessary alarm.

It is also an example of how UX design and technical domain knowledge need to work together. A visually clear notification is not necessarily a good notification if its meaning is inaccurate.

Designing guidance without overwhelming users

Another challenge was organising all this information without making the page overwhelming. A single resource can have multiple registration details, routing information, automated checks, recommended actions, and so on. So displaying everything with the same visual weight would make it difficult for members to quickly understand what matters.

With this in mind, we organised the side panel into distinct sections, including an overview, RIPE Database objects and routing information. We also developed a visual language to distinguish different types of information.

Items requiring attention are highlighted in orange, while positive results are communicated using green indicators. Neutral states are used for informational content or situations where the system cannot determine whether something is incorrect.

We also moved away from describing every detected condition as an "issue", choosing the more neutral language "to review".

This better reflects what the system is doing: helping members identify what deserves a closer look, without assuming that every detected condition is necessarily an error.

For longer explanations, we explored expandable notifications so users can first see what needs attention and then access additional guidance and actions when needed.

These may seem like small details, but they influence how members interpret the information and how much confidence they place in the system.

What comes next: learning from members

The new My Resources experience is still evolving, and there are several assumptions we need to validate.

During next week's RIPE Meeting in Sofia, we plan to test the new page with members, including people who participated in earlier Registry Check research and others who will be seeing the design for the first time.

We want to understand whether they can navigate the hierarchy, identify resources that need attention, interpret the automated checks and understand the suggested actions.

We'll also test how the page connects with Registry Check, including whether the transition between the two experiences feels clear and natural.

The findings will help us identify what works, what's still confusing, and what we should improve next.

A clearer way to manage resources

As we hope will be clear by now, the redesign isn't just about improving the layout, but rather, it's about helping members to understand their resources and make more informed decisions about what needs reviewing or updating.

The tree view makes relationships easier to explore. Automated checks highlight situations that might otherwise be overlooked. And contextual explanations and links to relevant actions help members understand what those findings mean.

At the same time, the design needs to recognise the limits of automation. Not every unusual condition is an error, and sometimes the right approach is to provide information rather than a warning.

Our goal is to create an experience that supports members in keeping their resource registrations accurate and aligned with RIPE policies, while reducing the effort required to understand what needs attention.

The next step is to see how well it works for the people who will use it.