Why does the case show no screens and no figures?

Because we do not publish product screens or metrics from this engagement that have not been explicitly cleared. We describe problem, approach and outcome qualitatively; details are available in conversation, as far as we are allowed to share them.

What does Beabstracto bring from this work to enterprise software vendors?

Experience with exactly the problems that heads of product and product managers at enterprise SaaS companies face: dense tables, repeated filter work, patterns drifting apart per module, and a design system that is supposed to ensure consistency without blocking evolution. Plus the practice of validating concepts in usability tests before scaling them.

How does Beabstracto work inside an existing design organization with its own design system?

Within the frame the system sets. We first learn which patterns already apply, take part in critiques and document in a way that lets other teams carry the work forward. Where the system does not cover a need, we make the case for the extension rather than introducing our own components.

Does this transfer to specialist systems in banking and industry?

Yes. Tables with many rows, saved views, readable states and decisions under time pressure are daily life in fund accounting, tax reporting and control systems just as in IT asset management. The domain changes; the UX questions stay the same: how does the person find what they need, and how do they recognize what demands attention?

How did remote collaboration with a US-based team work?

Fully remote, across time zones with product management, engineering, research and designers. That requires clean documentation and asynchronous alignment – skills we apply equally in the DACH region when business teams, IT and external consultants sit at different locations.

Enterprise SaaS · IT asset management · 2025–2026

Turning a table problem into a reusable product pattern.

For Flexera, a vendor of enterprise software for IT asset management, FinOps and software asset management, Thiago Andrade worked as Senior Product Designer to make dense, table-heavy workflows clearer and easier to use. The starting point was a specific navigation problem in one table. The outcome was a concept for saved filters and views that holds beyond that one place in the product – validated in usability tests and aligned with a design organization of more than 20 designers.

Book an intro call How we approached it

Client: Flexera
Industry: Enterprise SaaS · IT asset management (ITAM), FinOps, software asset management
Role: Senior Product Designer, embedded in the product and design organization
Period: October 2025 – July 2026 · remote, USA
Systems: ITAM platform (enterprise SaaS) · existing design system
Team: Design organization of 20+ designers, product management, engineering, research

In short

Flexera is a vendor of enterprise software for IT asset management, FinOps, software asset management and complex IT operations. Its users are technical and operational professionals who derive decisions from large data tables, save views and need to understand product states across many records. From October 2025 to July 2026, Thiago Andrade was embedded there as Senior Product Designer. He designed and refined workflows for ITAM interfaces, developed concepts for table navigation and saved filters, ran usability tests and concept validation, and aligned the results with a design organization of more than 20 designers. A local table problem became an opportunity for a reusable product pattern.

This matters to enterprise software vendors because the typical problems – overloaded tables, repeated filter work, patterns reinvented per module – do not belong to one industry. From this work Beabstracto brings the experience of getting improvements through a large product organization with an existing design system: improvements that help locally without fragmenting the overall product.

Starting point

Where did the product stand before the work began? In an environment where data volume is not a flaw but the core of the product.

Flexera builds enterprise software for IT asset management, FinOps and software asset management. Its products help organizations see and govern their software and cloud estates, licenses and costs across large, heterogeneous IT landscapes. This is a domain where completeness counts: a table that shows only part of the assets is worthless to the business team.

The users are technical and operational professionals. They navigate dense data, make decisions based on complex tables, manage saved views and need to understand the state of objects and processes at high volume. Unlike consumer software, the goal is not to hide information but to structure it so that, despite the density, the person gets to a decision quickly.

The work took place in a large product and design organization: more than 20 designers, plus product management, engineering and research, spread across several product areas. An existing design system set the frame for components and interaction patterns. Every local improvement therefore had to answer two questions: does it help users at this spot? And does it fit with what already applies in other areas of the product?

Thiago Andrade's mandate as Senior Product Designer was to design and refine workflows for ITAM-focused interfaces, with a focus on clarity, usability and decision-making – in close collaboration with product management, engineering, research and the other designers. The engagement ran remotely with a team in the USA, from October 2025 to July 2026.

The problem

What was the problem? On the surface, a navigation problem in a dense table. Underneath, a set of patterns that show up in enterprise software again and again.

Tables where you search instead of decide
Users had to find, filter, save and act in large tables – often in one pass. When navigation and interaction do not fit together, the table becomes the place where you search rather than the place where you decide. The amount of data was not the problem; the missing structure for handling it was.
The same filters, every day, from scratch
Anyone who asks recurring questions of the same data set rebuilds the same filter combinations over and over. That costs time and produces errors. Saved filters and reusable views were therefore not a convenience but a precondition for efficient work.
Product states hard to read
In high-volume workflows, users need to understand what state objects and processes are in – without opening each item individually. Density without prioritization makes exactly that hard: everything is visible, nothing stands out.
Local fix, global side effect
In an organization with more than 20 designers and several product areas, the obvious risk is that each team solves the table problem on its own. The result would be several variants of the same pattern – confusing for users, expensive for engineering.
Design system, product requirement, user need
The three forces do not always pull in the same direction. The existing design system prescribed components, product management had requirements and deadlines, and users needed something that works in their real workflows. A good solution had to take all three seriously without sacrificing any of them.

How we approached it

How did we proceed? From the specific problem to the transferable solution – with validation at every point where a decision reached beyond the one table.

1
Getting to know the product, its users and existing patterns
The work began with an as-is analysis of the product context: who works with these tables, which decisions are derived from them, which patterns already apply in the design system and in neighbouring product areas.
2
From table problem to interaction model
The starting point was a specific navigation problem in a dense table. Instead of solving it in isolation, we examined the navigation and interaction patterns for tables in which users need to find, filter, save and act on large sets of information. This produced user flows, wireframes and interaction models that describe the behaviour of the table as a whole – not just the one spot where it broke down.
3
Saved filters and reusable views
In parallel, we explored how saved filters and a concept for view management could reduce repetitive work and give users more control over their working environment. The ambition was for the same concept to work in more than one product area. An improvement for one table thus became an opportunity for a pattern that can be reused across the product.
4
Usability testing and concept validation
The design directions were tested in usability sessions with users. We wrote test plans, ran the sessions, fed feedback back in loops and synthesized the results in a structured way. The central question was not whether a design was liked, but whether the improvements held up in real workflows.
5
Alignment across teams and the design system
In an organization with more than 20 designers, alignment is part of the design work. We presented the concepts in critiques, compared them with designers from other product areas and documented them so that local improvements stayed compatible with the broader product patterns. Where the design system set limits, we worked within them or made the case for an extension, rather than building our own components.
6
High-fidelity design and handoff
The validated concepts were worked up as high-fidelity designs aligned with the design system and handed over to product management and engineering together with interaction models and cross-team design documentation. Engineering should not just receive screens but understand the behaviour – including where tables, filters and states interact.

Outcome

What came out of it? Clearer workflows in a dense enterprise product – and a pattern that holds beyond its original location. We deliberately quote no figures here, because we have no cleared metrics for this engagement.

Aspect	Before	After
Table navigation	A specific navigation problem in a dense table, viewed locally	An interaction model for tables that describes finding, filtering, saving and acting as one connected flow
Recurring filters	Filter combinations rebuilt every session	Validated concept for saved filters and reusable views, designed for several product areas
Reach of the solution	Improvement for one place in the product	Opportunity for a reusable product pattern, aligned with other teams
Product direction	Design directions based on assumptions	Directions tested in usability sessions and concept validation, findings synthesized in a structured way
Consistency	Risk of parallel variants of the same pattern across teams	Design-system-aligned patterns and cross-team documentation

Clearer workflows for dense data
Information architecture, interaction behaviour and decision-making flows were improved for users working with dense operational data. The density stayed – now with structure, clarity and prioritization.
From local problem to pattern
The original table problem grew into a broader opportunity for a reusable pattern. That is the real lever in a large product: a solution that does not end at one spot.
Validated product direction
Usability tests and concept validation checked whether the proposed improvements supported real workflows. The product direction thus rested on observation rather than assumptions.
Effective inside a large design organization
Despite strong cross-team dependencies, the work produced results that helped locally without fragmenting the product – user needs, enterprise complexity and design system consistency kept in balance.

What we learned

01
A table problem is rarely just a table problem
When users get stuck in a table, the cause usually lies in the interplay of navigation, filters, saved views and state display. Fix only the reported spot and the next ticket comes from the neighbouring module. For every local finding we therefore ask whether it is a symptom of a missing pattern – in ITAM platforms as much as in banking systems or industrial control systems.
02
Density is not a flaw – missing prioritization is
Technical and operational users need a lot of information at once. The reflex to hide things makes them distrust the tool. What they need is structure: what is the state, what needs attention, what can wait. Good enterprise design accepts the density and orders it rather than designing it away.
03
In large organizations, alignment is part of the design
With more than 20 designers and several product areas, the winner is not the best design but the design that is compatible with the rest of the product and carried by other teams. Critiques, pattern documentation and early conversations with neighbouring teams are not side work – they are the path by which a local idea becomes a product pattern.
04
Validate first, then scale
A pattern meant to apply across the whole product has to withstand more than a one-off solution. Before we proposed a saved-filter concept as reusable, it was tested in usability sessions against real workflows. The order matters: validation before scaling saves engineering effort and prevents a mistake from being copied into every module.
05
The design system is a frame, not an obstacle
It is easier to draw your own component than to understand and extend the existing one. Only the second is sustainable. When the system does not cover a need, we make the case for the extension instead of working around it – that keeps the product consistent and the handoff to engineering predictable.

What we delivered

User flows for table-heavy ITAM workflows
Wireframes and interaction models for table navigation
Concepts for saved filters and reusable views
High-fidelity designs aligned with the existing design system
Usability test plans
Research synthesis and concept validation findings
Table interaction patterns with reuse potential
Design-system-aligned patterns
Cross-team design documentation for product management and engineering

Frequently asked questions

Why does the case show no screens and no figures?: Because we do not publish product screens or metrics from this engagement that have not been explicitly cleared. We describe problem, approach and outcome qualitatively; details are available in conversation, as far as we are allowed to share them.
What does Beabstracto bring from this work to enterprise software vendors?: Experience with exactly the problems that heads of product and product managers at enterprise SaaS companies face: dense tables, repeated filter work, patterns drifting apart per module, and a design system that is supposed to ensure consistency without blocking evolution. Plus the practice of validating concepts in usability tests before scaling them.
How does Beabstracto work inside an existing design organization with its own design system?: Within the frame the system sets. We first learn which patterns already apply, take part in critiques and document in a way that lets other teams carry the work forward. Where the system does not cover a need, we make the case for the extension rather than introducing our own components.
Does this transfer to specialist systems in banking and industry?: Yes. Tables with many rows, saved views, readable states and decisions under time pressure are daily life in fund accounting, tax reporting and control systems just as in IT asset management. The domain changes; the UX questions stay the same: how does the person find what they need, and how do they recognize what demands attention?
How did remote collaboration with a US-based team work?: Fully remote, across time zones with product management, engineering, research and designers. That requires clean documentation and asynchronous alignment – skills we apply equally in the DACH region when business teams, IT and external consultants sit at different locations.