LPA · From building interfaces to growing as a Product Designer

I joined the Barcelona office of Lucht Probst Associates (LPA) while I was doing the second postgraduate program of my master’s at Elisava. The team needed a product designer who could also code interfaces: design was mostly based in Germany, and development needed close support in Barcelona.

I started by receiving designs and building them in HTML, CSS, and Sass. In the first few months, I also started working on design, first on HedgePilot and then on WebDD, now known as Capmatix. Over time, I took on complete user stories, from definition and design to front-end build and handoff, plus user research, design systems, and implementation support.

From receiving designs to understanding how they’re built

My way in was visual implementation. I received designs created by the team in Germany and built them in HTML, CSS, and Sass inside the product’s environment. The goal wasn’t yet to define the experience, but to make sure the proposals could become real interfaces.

This work let me learn from the start:

• The products’ technical structure.
• What Angular could and couldn’t do.
• How visual components related to business logic.
• The questions that come up when a design reaches development.
• The impact of browsers, frameworks, and delivery timelines.

Working closely with development built a foundation that would later shape all my design decisions.

From implementing decisions to owning complete user stories

HedgePilot was the first product where my responsibilities started to grow. It was a new application for managing financial hedging strategies. The team in Germany had defined a visual direction, guidelines, and a design system; my work started by continuing that language.

After about a month, I started getting design assignments. Over time, I worked both on proposals coming from Germany and on new requirements. I became responsible for complete user stories: analyzing the need, designing the solution, discussing it with the team, building its visual layer with HTML and Sass, and handing it off so the product logic could be completed.

Expanding the scope through frontend

My technical knowledge also let me handle pieces beyond the main screens. I designed and coded HTML notification emails so that alerts and recommendations kept HedgePilot’s language outside the app.

Learning to design with data

The product brought together dashboards, ratios, currencies, dates, exposures, transactions, states, and validations. Designing these screens meant learning to:

• Prioritize information in dense interfaces.
• Show data without losing precision.
• Tell states, warnings, and actions apart.
• Keep light and dark themes consistent.
• Design reusable flows and components.

Adapting the product to new contexts of use

HedgePilot was originally designed for larger resolutions. When it needed to work on 1024 px screens, I had to rethink the hierarchy, density, and behavior of its components to build a smaller, more adaptable version without losing critical information.

From solving features to structuring a complex product

WebDD posed a different problem. The software already existed as a desktop application, had users, and packed in many interactions typical of a specialized financial tool. Bringing it to the web meant keeping its power without carrying over all of its complexity as it was.

My responsibilities included:

• Taking part in defining the product from its first web stages.
• Designing navigation and features to bring the desktop experience to the web.
• Creating the first visual system from scratch.
• Prototyping behaviors for users and development.
• Running tree tests and testing navigation proposals with Optimal Workshop.
• Designing trees, tables, states, history, and contextual actions.

Balancing a familiar experience with a better web solution

Users knew the desktop application and expected to find similar behaviors and logic in the new version. However, the web had different limitations and also offered opportunities to improve the experience significantly.

The challenge was to identify which mental models and capabilities had to stay, which interactions couldn’t be carried over as they were, and where the new platform let us simplify the work. The solution had to feel familiar to experienced users while showing that the web version could help them work more clearly and efficiently.

Adapting the design to a new technical foundation

At one point in development, the application needed to adopt AG Grid as the technical base for trees and tables. The design had to adapt to the framework’s rules and possibilities. To do that, I reviewed its documentation, learned how it worked, and translated the existing patterns into an experience consistent with the product.

From handing off designs to designing in code too

As I gained autonomy, code stopped being just the step after design and became a tool to explore and decide. I took part in meetings, sprints, and technical conversations; created prototypes in Figma when needed; prepared HTML and Sass; and stayed available during implementation to answer questions and adjust behaviors.

On some tasks, I designed directly in HTML and CSS. When a feature didn’t need exploring in Figma first, I used the browser and code as my design space, shortening the distance between proposal and implementation.

The responsibility was clearly shared:

• My contribution: product design, UX/UI, prototypes, HTML/CSS/Sass/Less, and occasionally TypeScript for basic front-end interactions.
• Development: architecture, business logic, and more complex technical integration.
• Product and team: prioritization, requirements, and shared decisions.

This way of working carried over to IBOR and other products at the company. On IBOR, I worked on restyling an older application built with Less that had to adapt to different themes for each client.

The mix of design, collaboration, and implementation was also recognized by the people I worked with directly in engineering, technical leadership, and management.

Three complementary perspectives: engineering, Capmatix technical leadership, and management.

Full recommendations available on request.

The growth of the role shows in the widening scope of my responsibilities. During my time at LPA, I:

• Went from coding existing designs to owning complete user stories.
• Worked on new products and on the web transformation of desktop software.
• Learned to design high-density visualizations, tables, and hierarchies.
• Created WebDD’s first visual system and worked within HedgePilot’s existing system.
• Added user research through navigation testing.
• Designed directly in code when it was the most efficient path.
• Built a professional practice that sits between product, design, and frontend.

My time at LPA turned an early affinity for code into a core part of how I design: understanding the product through the experience, the business, and the implementation.

LPA (opens in a new tab) · HedgePilot (opens in a new tab) · Capmatix (opens in a new tab)