We created the Design Foundation Sprint to raise the UX/UI quality of the product and give it a clearer, more consistent language. In six weeks, we redesign a representative part and turn it into a design system of components, patterns, and rules that the team and agents can reuse to extend the design across the rest of the software.
It may be the right time if
- You want to raise the UX/UI quality of a product that has grown over time
- You are replatforming and want to rethink the experience too
- You want to add new features without losing consistency
- Your team already works independently but lacks a shared direction
- You want to redesign the product from a common language
- You want to make the system agent-ready, with clear rules and patterns
What if the brand needs to come first?
Sometimes a software redesign is part of a broader change within the company. If the identity and visual language also need to evolve, it may make sense to begin with our Brand Sprint and use that new direction as the foundation for the Design Foundation Sprint.
How it works
Four phases to turn a new direction into a concrete system.
① Understand
We start from the existing product and the people who know it best. Through focused workshops, we reconstruct the product’s structure, flows, roles, patterns, and main issues, gathering the context needed to understand where to intervene. At the end of this phase, we define the area of focus together.
- The area or workflow to work on
- Problems and priorities to address
- The Sprint scope
② Redesign
We design a representative part of the product in high fidelity, working with real use cases, realistic data, states, and interface behaviours. Through the concept, we also define the software’s overall visual language: hierarchy, density, typography, colour, and interface principles. The result makes the new UX/UI direction tangible and becomes a reference for the rest of the product.
- High-fidelity prototype
- New UX/UI direction
- Reference visual language
③ Systemize
Starting from the prototype, we build a structured component library with foundations, design tokens, components, variants, states, and recurring patterns. The system grows directly from the real cases we designed, giving the team a practical, coherent base to reuse and extend across the rest of the product.
- Product language
- Foundations and design tokens
- Component library and core patterns
④ Agentify
In the final phase, we make the system agent-ready. Components and tokens describe what exists, but they do not always explain how to use it or how to make a new design decision. We make principles, rules, constraints, quality criteria, and anti-patterns explicit, organizing them in agent-ready documentation—such as a DESIGN.md or an equivalent format—that can live with the project and be used directly by agents.
- Agent-ready documentation
- Principles and rules for using the system
- Documented decisions, constraints, and criteria
Marco Trombetti Co-founder & CEO, Translated
What happens next?
Three services to continue after the Sprint, each available on its own.
Agile Design Sprint
Code Foundation
Design Review
Clear costs,
no surprises
Design Foundation Sprint
A new UX/UI direction, with components and rules to extend it across the rest of the software.
- Problems and priorities to address
- High-fidelity prototype
- Foundations and design tokens
- Product language
- Component library and core patterns
- Agent-ready documentation
Additional services
Agile Design Sprint
To deepen the redesign of new areas, flows, or features.
Code Foundation
To implement components and patterns directly in the product stack.
Design Review
To maintain quality and consistency as the team and agents evolve the product.
Claudia Vago Project Manager, Fondazione Finanza Etica
Who we have helped
Frequently asked questions
No. We work on a representative part of the product, broad enough to define a new direction that can then be applied progressively to the rest.
It depends on the product and the problems to solve. We can work across structure, navigation, and shared components, or explore a meaningful workflow from beginning to end. We make the choice together with the team at the start of the Sprint.
We do not work with a predetermined number of screens. We define a scope that fits the six weeks and is broad enough to support the decisions we need to make.
Not straight away, and that is deliberate. A complete design system covers the whole product, with every component, variant, and state, and is built to grow and be maintained over time: it does not come together in six weeks. In the Sprint we build its foundations: design tokens, core components, and patterns drawn from the part of the product we redesign. It is a base the team uses from day one, and the design system grows from there, on your own or with us.
It means making information explicit that often remains implicit: how to use components, which patterns to prefer, which constraints to respect, and how to extend the system without losing consistency. These rules can be used by the team and provided as context to agents, for example in a DESIGN.md or an equivalent format.
Yes. The prototype, Figma library, and documentation are specifically designed to give the team a base it can use and extend independently.
Yes. We can deepen the redesign with new Agile Design Sprints, implement components and patterns through the Code Foundation, or periodically review work produced in-house. The Design Foundation Sprint remains a complete engagement even without follow-on work.
Yes. With the Code Foundation, we can implement design tokens, components, and patterns directly in the product stack, adapting to React, Angular, or the technologies already used by the team.
That is where this approach applies most naturally, especially for SaaS, enterprise software, and products with complex flows, roles, and features. It can also work for other digital products that have reached a certain level of complexity.