We step in when a product that has grown over the years needs to be rethought during a replatforming, or when a scaleup is designing a new product or a new module. We work on UX/UI, design systems and front-end components to make software clearer to use, more consistent to develop and stronger to present.
UX/UI redesign of existing software
Many B2B products are solid and do important work, but they have grown through successive additions: new modules, customer requests, exceptions, permissions, integrations and specific flows. The result is often a valuable product with a layered interface that is inconsistent and hard to use.
The moment to act often coincides with a replatforming or a front-end migration. Rethinking the UX at that point turns the technology investment into a real improvement in the experience, without carrying the limits accumulated in the old system into the new one.
The interface also shapes how the product is perceived. In demos, in tenders, during onboarding or in presentations to stakeholders, software that looks dated or confusing can communicate less value than it actually holds.
We wrote about this approach in How to approach the redesign of enterprise software.
UX/UI for new products and new modules
We also work with technology scaleups designing a new product or extending an existing platform. In those cases we work alongside founders, product leads and developers while features, priorities and direction are still being defined.
We turn requirements and assumptions into concrete flows and prototypes, so that decisions can be discussed before they become code. The design system grows with the product and creates a shared foundation for what comes next.
How we make sense of complex software
The complexity of B2B software does not come from the number of screens alone. It comes from operational processes, roles, permissions, exceptions, data, integrations and business rules that have often been in place for years.
We enter the domain together with the people who know the product and the work its users do. We use co-design workshops, User Story Mapping, Jobs To Be Done and focused research to bring order to the information and identify where to act.
We move decisions into navigable prototypes early. A prototype is not a final presentation: it is a tool for understanding the problem, comparing alternatives and aligning product, development and leadership.
How we design the software
We start from the areas with the greatest impact on how the product is used or perceived: dashboards, critical flows, modules used in demos, recurring operations and shared components.
We proceed vertically and incrementally. Each part is designed in high fidelity, discussed with the team and prepared for development. This makes it possible to validate a direction on real cases before extending it to the rest of the software.
More on these patterns: how to create effective dashboards and how to design usable data tables.
Design system in Figma
While we design the interface, we build the design system in Figma: visual foundations, tokens, components, patterns and usage rules. It is not a document separate from the product, but the system that collects the decisions taken along the way.
The internal team can use that foundation to design new screens, keep modules consistent and cut down repeated decisions. The system grows with the software, without requiring everything to be defined up front.
Component library and Storybook
Where it is useful, we translate the design system into a component library and document it in Storybook. We build the base components and the example stories needed to show how the more complex ones behave.
Building the application stays with the client's team, which keeps control of the architecture, the code and the know-how. Our role is to create a solid reference between design and implementation, compatible with the stack and the constraints already in place.
How we work with the internal team
We organise the work in two-week sprints. In each cycle we show what we have designed, gather feedback and set the next priorities. How much the client is involved is calibrated on people's availability and on the moments where their contribution is genuinely needed.
The internal team brings knowledge of the domain, the architecture and the technical constraints. Moze leads the research, the UX/UI design and the construction of the design system. Decisions stay shared this way, and the output can enter the development process without an isolated handover.
We looked at this in Designers and developers: three principles to foster great teamwork.
Marco Trombetti Co-founder & CEO, Translated
Paolo Innocenti IS Director, Serioplast
The benefits for users, development and sales
- Software that is easier to use. Flows, hierarchies and information are rethought around what users actually do. The necessary complexity remains, but it becomes more readable and more manageable.
- More consistent development. Shared rules, patterns and components help the team build new features without redefining the foundations of the interface every time.
- A product that presents better. The interface goes back to representing the quality and maturity of the product, making its value and its evolution clearer in demos, tenders and presentations.
UX/UI projects for B2B software
Serioplast — A design system for a new ERP suite
Serioplast had decided to build a new ERP suite in-house and had put together a dedicated team. Moze facilitated the kick-off, co-designed the architecture of the suite and created a bespoke design system, handing the team the method and the tools to carry the work on by themselves.
CommerceClarity — UX/UI and design system for a new AI product
CommerceClarity started from a solid idea and a working proof of concept. We worked with the founders on product strategy, UX/UI and the design system, then translated that system into code. As the internal engineering team grew, the foundations we built together made it natural to carry the development and the evolution of the product forward.
Voxloud — UX/UI redesign and design system for a cloud phone system
Voxloud offers a cloud phone system through web, desktop and mobile applications. We worked with the team on the UX/UI redesign, on defining new features and on building the design system, working in sprints and as an extension of the internal team.
Leapp — UX/UI for a cloud access management app
Leapp is an open source desktop application for managing credentials to the main cloud services locally. We designed the UX/UI of the application and the web interface managers use to handle their team's permissions and access.
Who this is for
This model works best where there is an internal engineering team that knows the product and wants to keep code and skills inside the company. We can work on the whole product or start from a single module, a critical flow or an area with particular commercial weight.
We work with software companies, established organisations and technology scaleups on SaaS, enterprise platforms, vertical business systems and proprietary applications.
Frequently asked questions
Do you only work on existing software?
No. We can modernize a product that has grown over the years, or design a new product or module together with a scaleup and its engineering team.
Can you work during a replatforming?
Yes. It is one of the most common moments we are brought in. We design the new experience while the team defines or implements the new technical foundation.
Can we start from a single area of the product?
Yes. We can start from a dashboard, a critical flow, a module used in demos or a limited set of features, to validate the direction before extending it.
How do you work with our development team?
We work in sprints, share prototypes and decisions, and account for the existing stack and constraints. The client's team stays involved at the moments that call for domain knowledge or technical judgement.
Do you also build the application front-end?
We normally build the component library and its Storybook documentation, including example stories for the complex components. Building the application's screens and features stays with the internal team.
Is a design system always necessary?
How far the design system goes depends on the project. For products meant to grow, made of several modules or built by more than a few people, it often becomes a substantial part of the work.
What budget do these projects start from?
Design projects for B2B software start from around €20,000. The budget grows with complexity, the number of areas involved, how deep the redesign goes and whether front-end or design system work is included.
Let's talk about your product
If you are rethinking existing software or designing a new product or module, we can start from the problem and define a first scope of work together.