Let's talk
Sector
Enterprise software for IT operations that technical users actually understand.
UX for cloud management, IT asset management and licence management: dense data tables, states, permissions and configuration that overwhelm even experienced admins. We design interfaces in which technical users derive decisions from data instead of piecing them together. The experience comes from product work on an IT asset management platform and on a workflow designer for document management.
In short
Beabstracto is a UX studio in Munich for complex expert systems. In cloud and IT we work on enterprise SaaS for IT operations: cloud management, IT asset management, software asset and licence management, ITSM. The users are administrators, licence managers and FinOps teams who have to derive decisions from large data tables and understand states across many transactions. We bring experience from product work on an IT asset management platform and in configuration-heavy workflow tools, and we are informed by the Nielsen Norman Group's work on complex applications as a benchmark, not as a certificate.
Where it breaks down in practice
Enterprise software for IT operations is powerful, and that is exactly what makes it hard. These are the places where product teams see tickets, workarounds and modules nobody opens.
Configuration that becomes a discipline of its own
A module can be set up in a hundred ways, and every option has side effects on others. Customers configure only with the help of consultants and then do not dare to change anything. What was meant to be flexible becomes a barrier to use.
Tables nobody can read
Thirty columns, thousands of rows, every column important to someone. Users rebuild the same filter combinations again and again, export to Excel and continue there. The decision is made outside the product, and the product never finds out.
States and permissions that confuse
An asset is discovered, assigned, licensed, expired, under review. An instance is running, paused, flagged, scheduled for shutdown. Who sees what, who may do what, and why is the button grey? When the state model and permissions are not made visible, support cases and wrong decisions follow.
Onboarding technical users
Admins and licence managers do not want a tour, they want to get the task done. At the same time, the product's data model differs from the one in their heads. Without clear terms, entry paths and examples, the product remains a foreign body even after training.
New modules that are not adopted
The product grows, and every module invents its own patterns for tables, filters and detail views. To the customer it looks like several products. Adoption lags behind sales, and the team does not know whether the module or the interface is to blame.
UX quality without a measure
In mature products nobody knows for sure whether the interface is getting better or worse. There are tickets and gut feeling, but no benchmarks that show where tasks break down. Decisions about roadmap and design remain a matter of opinion.
How we work
We work inside existing product organisations, with a design system, release cycles and a roadmap that does not wait for us.
- 1
Understand usage, not just requirements
We talk to administrators, licence managers and operations teams at the customer and look at how they actually work: which views they build, what they export, where they call support. From that comes a picture of tasks and decisions, not just a feature list.
- 2
Make the data model and states visible
With product management and development we define which objects, states and permissions the product knows, and we design what they are called and how they look in the interface. A consistent state model resolves more support tickets than any tooltip.
- 3
Patterns instead of individual screens
We design table navigation, saved views, filters, detail panels and configuration flows as reusable patterns within the existing design system. That way the solution helps locally without fragmenting the overall product.
- 4
Usability tests with technical users
We test prototypes with admins and domain experts using realistic tasks and real data, not placeholders. We capture abandonments, detours and misinterpretations before development starts, and we repeat the tests after release as a benchmark.
- 5
Handover, adoption, further development
We hand over specified components and flows to development, accompany release and customer onboarding, and on request stay in the product as UX support: quality rituals, benchmarks and the small improvements that would otherwise be left undone.
Services
Four clearly cut services for professional systems
Each with a fixed team, a fixed point of contact and no onboarding time in your domain.
UX Team as a Service
A well-rehearsed UX team in three sizes, working inside your professional system from day one. Research, UI and design-to-code from one source.
S: 1 UX lead + 1 senior
M: 1 UX lead + 2 UX professionals
L: 1 UX lead + 3 to 4 UX professionals
Guaranteed cover
Design system and production-ready components
Implementation support
UX designers and coaches accompany the rollout of a new professional system on the client side, so it is actually used at go-live.
Process mapping in the business unit
Configuration from the user perspective
Key-user training
Acceptance and hypercare
UX Support
A retainer for products in operation: further development, user testing, accessibility and design-system maintenance.
Fixed allocation
Fixed point of contact
User tests in the release rhythm
WCAG 2.2 AA as the standard
Training
Training for product, engineering and business teams that want to carry UX in complex systems themselves.
Methods from real projects
Transferred to your domain
Remote or on site
Materials to keep working with
Where we know this from
IT asset management platform of an enterprise software vendor
The founder was embedded as a Senior Product Designer with a vendor of enterprise software for IT asset management, FinOps and software asset management. He designed workflows for ITAM interfaces, conceived table navigation and saved filters, ran usability tests and aligned the results with a design organisation of more than 20 designers. A local table problem became a reusable product pattern.
Workflow designer of a B2B SaaS platform for document management
In permanent employment as a UX/UI designer, the founder worked on the usability of a workflow designer and on configuration-heavy enterprise flows, as well as on design system foundations with tokens, Figma migration and documentation. UX benchmarks, quality rituals and OKRs made UX quality measurable in a mature product.
A studio with experience in ITSM and cloud management
Today the studio works with clients from areas such as ITSM and cloud management, document management, and banking and tax software. The domain changes, the UX questions stay the same: dense data, many states, decisions under time pressure.
Frequently asked questions
- You come from banking and industry. Why cloud and IT?
- Because the UX questions are the same: large data tables, many states, permissions, decisions under time pressure, and users who are experts in their domain and have no patience for interfaces that get in their way. The founder worked on exactly these questions in an IT asset management platform and in a workflow designer for document management.
- We have a design system and a large design organisation. How do you fit in?
- As part of the organisation, not alongside it. We work in your design system, use your rituals and contribute proposals as patterns that can be reused in other modules. That was precisely the work on the IT asset management platform: helping locally without fragmenting the overall product.
- Can you organise usability tests with admins? They have no time.
- Yes. Recruiting expert users is the bottleneck in any research on complex applications, as the Nielsen Norman Group also describes. We work with short sessions, real data and tasks from the participants' everyday work, often with customers who are already in contact with Customer Success.
- What exactly do you do with our tables?
- We find out which questions users ask of the data and build the table around those questions: sensible default columns, saved views, filters that can be remembered, states that are explained in context. Then we test whether the decision is made in the product or still in Excel.
- Do you also help with introducing new modules at the customer?
- Yes. For us, introduction support means identifying key users, designing onboarding paths and examples, creating training material for technical users and collecting feedback systematically after release. That is how a module that was sold becomes a module that is used.
- How does UX quality become measurable?
- With benchmarks that compare selected tasks before and after a release, with questionnaires on pragmatic and hedonic quality, and with usage data on adoption and abandonment. We built such rituals in a mature B2B product and bring the templates with us.
Let's talk about your product.
Show us the module that generates the most tickets. We will look at where UX brings the most.