Back
“Network Service Analytics & Enabling AIOps in the service organisation”
Background
VisiMetrix offers a novel approach to monitoring and analyzing network service performance for the telecom industry, unifying data from disparate multi-vendor systems to enable customer impact assessment, early intervention, and trending.
This case study provides an analysis of a currently available product as well as the work that has been done towards developing a more modular and systemic approach offering a stronger, scalable and professional product.
Process
Mapping the UX/UI design process enables teams to clearly understand task sequencing, visualize dependencies, coordinate workflows, and establish a shared roadmap that guides project execution and informed decision-making.
<·· scroll··>
Research and discoveries
We conducted several interviews with different engineers and stakeholders to understand the complexity of the product covering the whole process from advertising it to deployment.
These findings were critical for understanding the complexity of the processes, decisions and customer onboarding. VisiMetrix is a complex product that tackles a very sharp and narrow market.
Client's internal decision making flow
Time Summary
Based on previous experiences with existing customers,I conducted several interviews with different engineers and stakeholders to understand the complexity of the product covering the whole process from advertising it to deployment.
These findings were critical for understanding the complexity of the processes, decisions and customer onboarding. VisiMetrix is a complex product that tackles a very sharp and narrow market.
From Customer first touchpoint to go live
I conducted a comprehensive analysis of the entire product lifecycle, from initial customer engagement through iterative refinement to deployment and launch, systematically mapping each stage, connection, and process complexity
Problems/solutions statement
The purpose of this exercise was to map different values and solutions for the given points. In this exploration participated engineers, designers, business analytics and main stakeholders. We covered objective and subjective results.
Features prioritisation
A list of features that will shape the purpose, power, and capabilities of the product, based on the findings from the discovery phase.
<·· scroll··>
Market analysis
A market study is essential to comprehending the true standing of a product when clients are searching for and selecting the best option. This exercise frames the product appropriately and provides a perspective on what we can add or modify to make it stronger are more interesting.
<·· scroll··>
Automatisation, logic, and structure
Automatization of process to visualize data.
In the current product version, engineers process the data and turn it into screens with fixed panels and visualizations per customer.
One of the most complex parts of this project was probably figuring out this logic and updating it to make it more systemic, modular, and user-friendly so that the user could manage, prioritize, and show the data based on their needs and goals.
Completing this process required multiple interactions with engineers, consumers, stakeholders, and a designer, leading to updated versions.
Data logic and structure v1
We started talking with the different team members of VisiMetrix to understand the logic, how we manage the data, and the general flows and tasks. Based on the first exploration meetings and the information we gathered, we could start designing a basic logic structure:
"Entities provide data to VisiMetrix. Visimetrix processes, organise, and translate* the data into KPIs* to feed the visualisation options available in the UI."
Notes:
Translate: Managing the different data sources and types and unifying them so it makes sense and can be handled and understood within the VisiMetrix environment.
KPIs: In this context, we used the KPIs concept for the lack of a better one. The idea behind it was to explain the data resulting after the management VisiMetrix did of the data coming from the entities.
<·· scroll··>
Data logic and structure v2
In this stage, we discovered that to access the entities, we must get access to different Management systems and/or monitoring tools. Get permissions and ways how to pull the needed data.
Also, we learned that the data we display in VisiMetrix, is processed by Us, but it can also come almost directly and without any treatment from the entities.
VisiMetrix "loaders" could treat the data from the entities, or the data could feed the panels almost without any treatment.
This difference was significant to understanding the logic and helping define the business model. It could expand the possibilities of offering more precise services to our customers.
e.g. Design specific loaders to treat the data in a custom way to particular customers and charge for it as an extra service/package.
<·· scroll··>
Data logic and structure v3
This stage revealed new information, existing structures within VisiMetrix and different understanding among the team members. We learned that Entities could be grouped due to their nature and type, and these groups could be grouped again into bigger ones.
We identified four data types: Time series data, descriptive data, events data, and loader.
Time series data: Dynamic data generated by entities.
Descriptive data: Fixed data coming from entities.
Events data: Time series data + threshold
Loader: Time/Value, Where value is computed under a condition from one or more Time series data + one or more descriptive data
Lastly, we understood that different data types could feed the same visualisation, offering many options, restrictions and new rules.
Note: KPi: In this context, we used the KPI concept for the lack of a better one. Until this point, the concept of KPI and loader is used to express really similar concepts.
<·· scroll··>
Data logic and structure v4
This concept is the latest one. After testing it and aligning with the team members, we can ensure that this logic can create visualisations of 95% of the existing data that VisiMetrix handles for our current customers in panels. This logic does not include the creation of architectural and technical diagrams (5%)
In this stage, we found out that domains, subdomains, entity groups, and entities can have loaders directly working at their levels and producing data to visualise it.
Domain: Usually a technology area, e.g. RAN domain, Fixed domain, Enterprise domain.
Subdomain and entity groups: Groups and subgroups of entities based on their typology, nature, and data streams.
We designed a logic structure capable of covering the need to visualise data streams independently of the origin and level of the data.
It is possible to mix different data streams and loaders, if data allows it, either if they come from a domain, subdomain, entity group and/or entity.
<·· scroll··>
Visualising data
Based on the most recent logic and structure of data, I came up with a way to search, connect, and show any related data in different ways depending on the type of data chosen.
By using a node connection approach, the user can connect multiple data streams with multiple locations and multiple visualization types (line chart, bar chart, area chart, summary, table, heat table, map, etc).
Once the panel with the data visualization is done, the user will have the chance to add it to their dashboard and share it with the Team's library. This approach also allows drill-downs or sub panels to dive deeper into the selected data and get a better understanding of it.
<·· scroll··>
Design library
A design system is comprised of a sequence of components that are regularly repurposed in different configurations. A design system allows you to effectively manage all of your designs at scale. Design systems are organic and continually evolving and adapting to new requirements, while maintaining a simple and modular approach to usage.
<·· scroll··>
Interface design / Anatomy
The interface combines layout, navigation, typography, and interactive elements into a balanced system, delivering clarity, consistency, and ease of use.
<·· scroll··>
Interface
Dashboards for tables, statuses, and networks present all essential information in an intuitive, clear, and intelligent manner, empowering effective management, control, and decision-making across the network.
This approach emphasizes clarity, user empowerment, and a smart take to presenting data, which aligns with principles of effective dashboard design found in industry standards.
Table sites, status, and networks dashboard
Table sites, status, and networks dashboard
Let’s collaborate.
Have a complex product challenge or a project that needs a senior eye? I’m always open to discussing new opportunities, design systems, or the future of UX.
linkedin.com/in/rodolfobiglie
rodolfo.biglie@protonmail.com
Some of the teams and companies from around the world I’ve collaborated with:
Thank you for your time!
Home
About Me & Contacts
Back
“Network Service Analytics & Enabling AIOps in the service organisation”
Background
VisiMetrix offers a novel approach to monitoring and analyzing network service performance for the telecom industry, unifying data from disparate multi-vendor systems to enable customer impact assessment, early intervention, and trending.
This case study provides an analysis of a currently available product as well as the work that has been done towards developing a more modular and systemic approach offering a stronger, scalable and professional product.
Process
Mapping the UX/UI design process enables teams to clearly understand task sequencing, visualize dependencies, coordinate workflows, and establish a shared roadmap that guides project execution and informed decision-making.
<·· scroll··>
Research and discoveries
We conducted several interviews with different engineers and stakeholders to understand the complexity of the product covering the whole process from advertising it to deployment.
These findings were critical for understanding the complexity of the processes, decisions and customer onboarding. VisiMetrix is a complex product that tackles a very sharp and narrow market.
Client's internal decision making flow
Time Summary
Based on previous experiences with existing customers,I conducted several interviews with different engineers and stakeholders to understand the complexity of the product covering the whole process from advertising it to deployment.
These findings were critical for understanding the complexity of the processes, decisions and customer onboarding. VisiMetrix is a complex product that tackles a very sharp and narrow market.
From Customer first touchpoint to go live
I conducted a comprehensive analysis of the entire product lifecycle, from initial customer engagement through iterative refinement to deployment and launch, systematically mapping each stage, connection, and process complexity
<·· scroll··>
Problems/solutions statement
The purpose of this exercise was to map different values and solutions for the given points. In this exploration participated engineers, designers, business analytics and main stakeholders. We covered objective and subjective results.
Features prioritisation
A list of features that will shape the purpose, power, and capabilities of the product, based on the findings from the discovery phase.
<·· scroll··>
Market analysis
A market study is essential to comprehending the true standing of a product when clients are searching for and selecting the best option. This exercise frames the product appropriately and provides a perspective on what we can add or modify to make it stronger are more interesting.
<·· scroll··>
Automatisation, logic, and structure
Automatization of process to visualize data.
In the current product version, engineers process the data and turn it into screens with fixed panels and visualizations per customer.
One of the most complex parts of this project was probably figuring out this logic and updating it to make it more systemic, modular, and user-friendly so that the user could manage, prioritize, and show the data based on their needs and goals.
Completing this process required multiple interactions with engineers, consumers, stakeholders, and a designer, leading to updated versions.
Data logic and structure v1
We started talking with the different team members of VisiMetrix to understand the logic, how we manage the data, and the general flows and tasks. Based on the first exploration meetings and the information we gathered, we could start designing a basic logic structure:
"Entities provide data to VisiMetrix. Visimetrix processes, organise, and translate* the data into KPIs* to feed the visualisation options available in the UI."
Notes:
Translate: Managing the different data sources and types and unifying them so it makes sense and can be handled and understood within the VisiMetrix environment.
KPIs: In this context, we used the KPIs concept for the lack of a better one. The idea behind it was to explain the data resulting after the management VisiMetrix did of the data coming from the entities.
<·· scroll··>
Data logic and structure v2
In this stage, we discovered that to access the entities, we must get access to different Management systems and/or monitoring tools. Get permissions and ways how to pull the needed data.
Also, we learned that the data we display in VisiMetrix, is processed by Us, but it can also come almost directly and without any treatment from the entities.
VisiMetrix "loaders" could treat the data from the entities, or the data could feed the panels almost without any treatment.
This difference was significant to understanding the logic and helping define the business model. It could expand the possibilities of offering more precise services to our customers.
e.g. Design specific loaders to treat the data in a custom way to particular customers and charge for it as an extra service/package.
<·· scroll··>
Data logic and structure v3
This stage revealed new information, existing structures within VisiMetrix and different understanding among the team members. We learned that Entities could be grouped due to their nature and type, and these groups could be grouped again into bigger ones.
We identified four data types: Time series data, descriptive data, events data, and loader.
Time series data: Dynamic data generated by entities.
Descriptive data: Fixed data coming from entities.
Events data: Time series data + threshold
Loader: Time/Value, Where value is computed under a condition from one or more Time series data + one or more descriptive data
Lastly, we understood that different data types could feed the same visualisation, offering many options, restrictions and new rules.
Note: KPi: In this context, we used the KPI concept for the lack of a better one. Until this point, the concept of KPI and loader is used to express really similar concepts.
<·· scroll··>
Data logic and structure v4
This concept is the latest one. After testing it and aligning with the team members, we can ensure that this logic can create visualisations of 95% of the existing data that VisiMetrix handles for our current customers in panels. This logic does not include the creation of architectural and technical diagrams (5%)
In this stage, we found out that domains, subdomains, entity groups, and entities can have loaders directly working at their levels and producing data to visualise it.
Domain: Usually a technology area, e.g. RAN domain, Fixed domain, Enterprise domain.
Subdomain and entity groups: Groups and subgroups of entities based on their typology, nature, and data streams.
We designed a logic structure capable of covering the need to visualise data streams independently of the origin and level of the data.
It is possible to mix different data streams and loaders, if data allows it, either if they come from a domain, subdomain, entity group and/or entity.
<·· scroll··>
Visualising data
Based on the most recent logic and structure of data, I came up with a way to search, connect, and show any related data in different ways depending on the type of data chosen.
By using a node connection approach, the user can connect multiple data streams with multiple locations and multiple visualization types (line chart, bar chart, area chart, summary, table, heat table, map, etc).
Once the panel with the data visualization is done, the user will have the chance to add it to their dashboard and share it with the Team's library. This approach also allows drill-downs or sub panels to dive deeper into the selected data and get a better understanding of it.
Design library
A design system is comprised of a sequence of components that are regularly repurposed in different configurations. A design system allows you to effectively manage all of your designs at scale. Design systems are organic and continually evolving and adapting to new requirements, while maintaining a simple and modular approach to usage.
Interface design / Anatomy
The interface combines layout, navigation, typography, and interactive elements into a balanced system, delivering clarity, consistency, and ease of use.
Interface
Dashboards for tables, statuses, and networks present all essential information in an intuitive, clear, and intelligent manner, empowering effective management, control, and decision-making across the network.
This approach emphasizes clarity, user empowerment, and a smart take to presenting data, which aligns with principles of effective dashboard design found in industry standards.
Table sites, status, and networks dashboard
Table sites, status, and networks dashboard
Let’s collaborate.
Have a complex product challenge or a project that needs a senior eye? I’m always open to discussing new opportunities, design systems, or the future of UX.
linkedin.com/in/rodolfobiglie
rodolfo.biglie@protonmail.com
Some of the teams and companies from around the world I’ve collaborated with:
Thank you for your time!
VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX ·
VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX ·
Home
About Me & Contacts
Back
“Network Service Analytics & Enabling AIOps in the service organisation”
Background
VisiMetrix offers a novel approach to monitoring and analyzing network service performance for the telecom industry, unifying data from disparate multi-vendor systems to enable customer impact assessment, early intervention, and trending.
This case study provides an analysis of a currently available product as well as the work that has been done towards developing a more modular and systemic approach offering a stronger, scalable and professional product.
Process
Mapping the UX/UI design process enables teams to clearly understand task sequencing, visualize dependencies, coordinate workflows, and establish a shared roadmap that guides project execution and informed decision-making.
Research and discoveries
We conducted several interviews with different engineers and stakeholders to understand the complexity of the product covering the whole process from advertising it to deployment.
These findings were critical for understanding the complexity of the processes, decisions and customer onboarding. VisiMetrix is a complex product that tackles a very sharp and narrow market.
Client's internal decision making flow
Time Summary
Based on previous experiences with existing customers,I conducted several interviews with different engineers and stakeholders to understand the complexity of the product covering the whole process from advertising it to deployment.
These findings were critical for understanding the complexity of the processes, decisions and customer onboarding. VisiMetrix is a complex product that tackles a very sharp and narrow market.
From Customer first touchpoint to go live
I conducted a comprehensive analysis of the entire product lifecycle, from initial customer engagement through iterative refinement to deployment and launch, systematically mapping each stage, connection, and process complexity
Problems/solutions statement
The purpose of this exercise was to map different values and solutions for the given points. In this exploration participated engineers, designers, business analytics and main stakeholders. We covered objective and subjective results.
Features prioritisation
A list of features that will shape the purpose, power, and capabilities of the product, based on the findings from the discovery phase.
Market analysis
A market study is essential to comprehending the true standing of a product when clients are searching for and selecting the best option. This exercise frames the product appropriately and provides a perspective on what we can add or modify to make it stronger are more interesting.
Automatisation, logic, and structure
Automatization of process to visualize data.
In the current product version, engineers process the data and turn it into screens with fixed panels and visualizations per customer.
One of the most complex parts of this project was probably figuring out this logic and updating it to make it more systemic, modular, and user-friendly so that the user could manage, prioritize, and show the data based on their needs and goals.
Completing this process required multiple interactions with engineers, consumers, stakeholders, and a designer, leading to updated versions.
Data logic and structure v1
We started talking with the different team members of VisiMetrix to understand the logic, how we manage the data, and the general flows and tasks. Based on the first exploration meetings and the information we gathered, we could start designing a basic logic structure:
"Entities provide data to VisiMetrix. Visimetrix processes, organise, and translate* the data into KPIs* to feed the visualisation options available in the UI."
Notes:
Translate: Managing the different data sources and types and unifying them so it makes sense and can be handled and understood within the VisiMetrix environment.
KPIs: In this context, we used the KPIs concept for the lack of a better one. The idea behind it was to explain the data resulting after the management VisiMetrix did of the data coming from the entities.
Data logic and structure v2
In this stage, we discovered that to access the entities, we must get access to different Management systems and/or monitoring tools. Get permissions and ways how to pull the needed data.
Also, we learned that the data we display in VisiMetrix, is processed by Us, but it can also come almost directly and without any treatment from the entities.
VisiMetrix "loaders" could treat the data from the entities, or the data could feed the panels almost without any treatment.
This difference was significant to understanding the logic and helping define the business model. It could expand the possibilities of offering more precise services to our customers.
e.g. Design specific loaders to treat the data in a custom way to particular customers and charge for it as an extra service/package.
Data logic and structure v3
This stage revealed new information, existing structures within VisiMetrix and different understanding among the team members. We learned that Entities could be grouped due to their nature and type, and these groups could be grouped again into bigger ones.
We identified four data types: Time series data, descriptive data, events data, and loader.
Time series data: Dynamic data generated by entities.
Descriptive data: Fixed data coming from entities.
Events data: Time series data + threshold
Loader: Time/Value, Where value is computed under a condition from one or more Time series data + one or more descriptive data
Lastly, we understood that different data types could feed the same visualisation, offering many options, restrictions and new rules.
Note: KPi: In this context, we used the KPI concept for the lack of a better one. Until this point, the concept of KPI and loader is used to express really similar concepts.
Data logic and structure v4
This concept is the latest one. After testing it and aligning with the team members, we can ensure that this logic can create visualisations of 95% of the existing data that VisiMetrix handles for our current customers in panels. This logic does not include the creation of architectural and technical diagrams (5%)
In this stage, we found out that domains, subdomains, entity groups, and entities can have loaders directly working at their levels and producing data to visualise it.
Domain: Usually a technology area, e.g. RAN domain, Fixed domain, Enterprise domain.
Subdomain and entity groups: Groups and subgroups of entities based on their typology, nature, and data streams.
We designed a logic structure capable of covering the need to visualise data streams independently of the origin and level of the data.
It is possible to mix different data streams and loaders, if data allows it, either if they come from a domain, subdomain, entity group and/or entity.
Visualising data
Based on the most recent logic and structure of data, I came up with a way to search, connect, and show any related data in different ways depending on the type of data chosen.
By using a node connection approach, the user can connect multiple data streams with multiple locations and multiple visualization types (line chart, bar chart, area chart, summary, table, heat table, map, etc).
Once the panel with the data visualization is done, the user will have the chance to add it to their dashboard and share it with the Team's library. This approach also allows drill-downs or sub panels to dive deeper into the selected data and get a better understanding of it.
Design library
A design system is comprised of a sequence of components that are regularly repurposed in different configurations. A design system allows you to effectively manage all of your designs at scale. Design systems are organic and continually evolving and adapting to new requirements, while maintaining a simple and modular approach to usage.
Interface design / Anatomy
The interface combines layout, navigation, typography, and interactive elements into a balanced system, delivering clarity, consistency, and ease of use.
Interface
Dashboards for tables, statuses, and networks present all essential information in an intuitive, clear, and intelligent manner, empowering effective management, control, and decision-making across the network.
This approach emphasizes clarity, user empowerment, and a smart take to presenting data, which aligns with principles of effective dashboard design found in industry standards.
Table sites, status, and networks dashboard
Table sites, status, and networks dashboard
Let’s collaborate.
Have a complex product challenge or a project that needs a senior eye? I’m always open to discussing new opportunities, design systems, or the future of UX.
linkedin.com/in/rodolfobiglie
rodolfo.biglie@protonmail.com
Some of the teams and companies from around the world I’ve collaborated with:
Thank you for your time!
VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX ·
VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX · VISIMETRIX ·