Pelt8 · Designing beyond the product

Pelt8 was a Swiss ESG reporting startup. My work on the project began in 2021, when its founder, Julian Osborne, asked me to turn an early vision into a prototype he could show to potential users and validate with them.

Julian had been my Product Owner on HedgePilot during my time at LPA. He already knew my work and came to me when he needed a designer who could help him structure the product from its first hypotheses.

After that first collaboration, Julian kept developing and validating Pelt8. I supported the project from time to time until I joined full-time in 2023 as Lead Product Designer and the team’s only designer. By then, Pelt8 was a React app with real customers, and my job had changed: bring consistency to the product, set a shared foundation for design and engineering, and keep the brand’s quality across every touchpoint.

Scope: Product UX/UI · design system · brand · website · email · communication · no-code and automation.

An invitation built on earlier trust

In early 2021, Julian was working alone on an idea called Pelt8. After our first conversation, he shared an early pitch, a concept document about the organization he wanted to build, and a map of pages and features in Figma.

The immediate goal was a prototype he could show to potential users to get feedback. He also needed a first landing page for the product. If the signals were positive, the plan was to move toward a working version and use interest from potential customers to raise funding.

The material explained Pelt8’s ambition, but there was no product experience yet that could show how it would work.

Understanding the domain before designing the interface

I didn’t know the ESG world. Before drawing screens, I needed to understand the problem Pelt8 wanted to solve, how the whole process worked, and what information the people involved needed.

The first proposal focused on helping private capital markets organizations identify the relevant KPIs and standards, request information from different organizations, track progress, and create reports for investors and other stakeholders.

The product also had to serve two connected but different perspectives:

• the organization that defined indicators, requested information, and consolidated the results;
• the entity that received the request and provided the data.

I researched the domain, reviewed references and comparable products, and used low-fi designs to make visible the relationships that weren’t resolved yet. The goal of that phase wasn’t to master all of ESG regulation. It was to learn enough to ask better questions and turn the business logic into a coherent experience.

From a feature map to a product journey

Julian’s first Figma file organized pages and features with MoSCoW: must have, enabling functions, could have, and wishlist. It was a useful base for prioritizing, but it didn’t explain how actions connected, what decisions each user had to make, or how a process ran from start to finish.

I started by building maps, user journeys, and flows. One overall journey connected sign-in, organization profiles, third-party sources, Indicators, Measures, Metrics, and Reports. Another went deeper into creating a Metric: its frequency, owner, the report it belonged to, source data, operators, and formula.

From those journeys, I sketched low-fi screens. The wireframes weren’t a visually unfinished version of the final product. They were a tool to turn abstract questions into decisions we could see. Julian could follow the logic, spot gaps, and discuss how the product should behave before investing in building it.

From prototyping a possibility to working inside a SaaS in production

When I joined full-time in 2023, Pelt8 was no longer a set of hypotheses. It was an app built in React, with customers and an engineering team that had been solving the business’s needs for some time.

That growth had also left visual inconsistencies, patterns that behaved differently, and experience decisions made without a dedicated design function. My first job was to audit the product to find recurring problems and separate three levels of work:

1. fixes that could improve the experience right away;
2. structural problems that needed shared patterns;
3. opportunities that belonged in a future evolution.

The audit wasn’t meant to produce an isolated list of bugs. It helped me build a vision of the product, understand the decisions already in place, and set priorities together with product and engineering.

Designing at the team’s pace

We worked in sprints. I worked with the people in charge of product to understand needs, define features, discuss improvements, and agree on scope. I designed new screens and reviewed existing experiences, but my job didn’t end when I handed over a Figma file.

During implementation, I stayed available to answer questions, review alternatives, and run QA. The real flow was continuous:

Need → definition with Product → exploration → design → technical conversation → trade-off → implementation → QA → documentation

My frontend knowledge helped me understand which changes could ship with less effort and which ones had bigger implications. That made it easier to talk with engineering about real constraints and protect what mattered most in the experience, without proposing solutions disconnected from what the team could deliver.

A cross-functional design function

My formal role included overseeing design from concept to delivery, making sure the app was easy to use, keeping the brand consistent, contributing to research methods, leading the website experience, and creating marketing materials.

In practice, this meant connecting product, development, communication, and operations. It wasn’t about taking on different roles at random. It was about seeing where a design decision could reduce friction, create consistency, or help the team move forward.

Metrics: a technical problem that also needed design direction

Pelt8 had to represent the relationships between Measures, Metrics, Frameworks, and Reports. A Measure was a data point the system used; a Metric could combine several Measures through a formula. That complexity was part of the domain and of the flexibility users needed, so it couldn’t simply be removed.

Before I joined, the engineering team had built formula creation with collapsible nodes. It was a pragmatic way to ship a solution to a complex technical problem quickly, at a time when there was no dedicated design direction.

The solution made it possible to build formulas, but it was hard to use. It was difficult to tell the hierarchy apart, understand which elements belonged to each level, follow the dependencies, and clearly read the result being built.

The challenge wasn’t to question the earlier decision. It was to understand why it had been made and design an evolution that fit the reality of the product.

Designing a transition, not only an ideal result

The engineering team had a heavy workload, and replacing the whole implementation wasn’t possible right away. So I organized the proposal into three levels:

1. Quick wins. Low-effort adjustments to improve spacing, grouping, hierarchy, and visual cues.
2. Structural improvements. Changes to how elements were organized, to make relationships and dependencies easier to read.
3. Target vision. A future interaction direction that showed how the system could evolve with more technical capacity.

This approach turned design into a conversation about cost, impact, and sequence. Instead of an all-or-nothing solution, it let us improve the experience in the short term while keeping a shared vision for the future.

Designing an ideal solution wasn’t enough. We also needed to design a realistic path to get there.

Metrics sums up an important part of my work at Pelt8: learning a specialized concept, separating necessary complexity from avoidable friction, and translating a UX vision into steps the team could implement.

From fixing screens to finding patterns

Pelt8 didn’t have a structured design system when I joined. As I audited and redesigned the product, the same pattern kept appearing: many inconsistencies couldn’t be fixed screen by screen, because they came from missing foundations, components, and shared criteria.

I started by building the foundations we needed for the immediate problems. The system grew with the product:

No system → our own foundations → closer alignment with Material → adapted UI kit → additional components → documentation

Aligning with Material didn’t mean adopting a library without judgment. It gave us a familiar, sustainable base, while the adapted UI kit kept Pelt8’s needs and visual language.

The goal wasn’t theoretical maturity or a huge library. It was the level of consistency a small startup could maintain and use in its day-to-day work.

Documenting to reduce dependency

The system didn’t live only in Figma. I started documenting in Notion:

• components and patterns;
• design principles;
• criteria for recurring decisions;
• handoff guidelines;
• implementation best practices.

Documentation was part of the solution. It let engineering look up existing decisions, handle more situations on their own, and ask fewer repeated questions. It also kept knowledge from living only in conversations or depending on my availability.

A more mature integration between design and code, with tools like Storybook, was part of the future vision. However, the product’s timeline and priorities didn’t allow us to build and maintain that infrastructure.

Figma plus documentation in Notion was the first realistic step: it didn’t close the whole gap between design and code, but it created a shared language and a reference the team could actually maintain.

Designing the collaboration too

The design system didn’t work in isolation. I reviewed implementations, answered questions during sprints, and adjusted proposals when constraints came up. Each solved problem could become a pattern; each documented pattern meant not starting from scratch the next time.

A business initiative without engineering capacity

For a partnership linked to the banking sector, Pelt8 needed to launch an additional experience on a tight deadline. The engineering team was focused on the core product and couldn’t take on another project.

Waiting would have blocked the initiative. Building a custom app would have used capacity the team didn’t have. Before choosing a tool, I researched different no-code options and assessed which combination could offer:

• conditional logic;
• fast building;
• integration with existing processes;
• automated communications;
• an operation the team could manage.

Tally and Make offered the most realistic combination for the scope and the time available. The decision didn’t start from wanting to use those tools. It came from assessing which option could best solve the problem under real constraints.

Building the whole journey

In Tally, I designed the experience around questions and branching logic. The answers led to different results or offers. Then I used Make to connect the journey to the actions that followed:

• generate communications based on the result;
• send emails automatically;
• move follow-up actions into the task system;
• let the team run the initiative without depending on a new app.

The solution didn’t try to replace the core product or become a parallel platform. It was a proportionate answer: solid enough to meet the goal without using up the engineering roadmap.

This work shows that solving a problem doesn’t always mean designing a screen for someone else to build. It can also mean researching options, choosing the most realistic architecture, and taking the experience all the way to a working state.

A consistent identity across every touchpoint

As the only designer, I was also responsible for how Pelt8 showed up outside the SaaS. I refreshed the identity and brought the new visual language to the website, social media, presentations, pitch decks, materials for customers and fundraising, print pieces, and events.

The existing website ran on WordPress. I proposed rebuilding it in Framer because it offered more control over the design, more autonomy to maintain the content, and a more direct path from Figma to implementation. That let us iterate faster, improve the experience, and depend less on engineering for everyday changes.

Improving communications inside the existing tool

Brevo was already the company’s platform for communications. My job was to work inside that system and improve the experience from within.

I designed templates and assets, organized the logic of different messages, and worked both on transactional emails sent by the app and on announcements telling customers about new releases. To adapt the templates to Pelt8’s visual and functional needs, I also worked directly with HTML and CSS inside Brevo.

That way, the messages after an action or a product update stayed continuous with the interface and with Pelt8’s identity. Design didn’t end at the main screen: it included the messages that came with the user before and after using it.

Designing the company’s public moments too

I created materials for social media, sales, customers, and fundraising. I also designed the visuals for the Swiss Climate Reporting Forum and supported both editions visually.

Besides producing specific pieces, I designed reusable templates for presentations and documents, available in both Canva and Figma. I prepared options in both tools because some people on the team were more comfortable in Canva and others in Figma. That gave the founders clear visual guidelines, so they could create content quickly without losing brand consistency or holding up urgent startup needs while waiting for design support.

The range of formats could look like a list of unrelated tasks, but it served one goal: keep a recognizable, professional experience while the team gained the autonomy to move fast.

My work at Pelt8 grew with the company. It started by giving visual and logical structure to an idea that still needed validation. It continued inside a real product, where designing meant understanding constraints, negotiating priorities, and supporting implementation. In the end, it became a cross-functional role that connected product, systems, brand, and operations.

The impact wasn’t only in the screens I produced:

• In the product, I turned complexity into journeys and improvement strategies that engineering could implement.
• In the team, I built references, components, and documentation to reduce dependency and make decisions more consistent.
• In the company, I extended the experience to the website, emails, presentations, events, and solutions that couldn’t wait for the roadmap.

Recommendation letter, May 2025. Full document available on request.