Portfolio ·

Get in touch for my next availability Part time to full time  ·  remote across the EU

The studio

I build the product with your team, not a deck about it.

Salsedine is an independent product studio and I run it. What people hire me for is someone who joins a team that already exists, takes an AI idea from requirement analysis through to a working interface, and stays through delivery instead of handing over a folder and leaving.

That means your sprints, your tools, your constraints. Requirement analysis, information architecture, wireframes, interactive prototypes, the design system your developers build against, and the reviews that keep what ships matching what was agreed.

Over ten years across insurance, telecom, public administration and virtual events, three AI native products of my own, and a psychology degree underneath all of it. Fully remote, working in English, Italian and Spanish.

Selected work

Three products of my own, and four I was hired to fix.

All seven case studies  →
Health  ·  live alpha

Routina - Small enough to repeat.

Most health apps are built for the week you feel motivated. This one is built for the other fifty one. Training, sleep, food, body and medical screening in one structure, and it gets quieter as it learns what actually matters to you.

Read the case study  →
Adaptive display, resolved from your objective
Answering UrgentWithin 8 kmThu 14:30 Incominganswered in 2s
Operations  ·  live

ParrotB - Answers when you can't.

Front desk, CRM, forms and e-sign for trades who cannot answer the phone, including the conversation architecture for the voice agent that does.

Read the case study  →
Reading the receipt
items8 total24.71 date08 Aug 2 lines unsureconfirm
Finance  ·  live, invite-only

Saveri - Snap a receipt. See where it goes.

Paper receipts become structured line items. Only the lines the model is genuinely unsure about ever come back to you, and every correction is remembered.

Read the case study  →

AI features, designed to survive real users

The model is not your risk. The journey around it is.

An AI feature reaches your backlog as a capability. It reaches your customer as a journey: a moment where they ask for something, a state where the system is not certain, an error they did not expect, and a way back to a person. Almost every AI feature that fails in production fails in one of those four states, and none of them are model problems.

I design those states, write the acceptance criteria for them, and test them with real users inside your delivery cycle. You get stories your team can estimate and a definition of done that someone can actually verify.

How an AI engagement runs  →
01  Discovery

Which journey, and is it worth it

Journey mapping and user research across the flows you are considering, so the backlog reflects where a model genuinely removes effort for a user rather than where it demos well. Includes the ones I recommend you drop.

02  Interaction design

The four states nobody specifies

What the system asks, what it shows when confidence is low, what a wrong answer looks like and how it is corrected, and the route back to a human. Wireframes, prototypes and specifications your developers can build from.

03  Validation

Acceptance criteria and usability testing

Measurable thresholds agreed before the sprint, then moderated testing on the built feature. Go or no go becomes an observation rather than an opinion, and EU AI Act obligations are mapped alongside.

Verizon Connect Customer facing agent, sole designer, problem definition to production ParrotB Voice receptionist, triage and booking against real operational constraints Saveri Document extraction with confidence routing and a correction memory

How I work

Four habits that survived eight companies and over ten years.

01

Decide before you draw

The screens are the last thing that happens. Most of the value is in naming the real problem, weighing two or three ways out of it, and being able to explain afterwards why you chose the one you chose.

02

Test inside the sprint, not after it

Research that lands after the build has committed is a report, not a decision. Testing the previous sprint's designs before handoff caught around 70% of usability issues at Ericsson while they were still cheap to fix.

03

Design the constraint, not the happy path

Travel time between jobs. A model that is confidently wrong. A user who skipped the field you wanted. The interesting design work is almost always in what the system does when reality does not cooperate.

04

Sit inside the delivery team

Not beside it. I work through the full cycle with developers and product, maintain the design system and component library they build against, and review the built interface against the specification every sprint. A design handed over and never looked at again is a document, not a product.

Services

Six ways to work together.

Every engagement starts with a call and a written scope. No fixed packages, because the useful shape of the work is rarely the same twice.

Product design, end to end

From requirement analysis and information architecture through to the shipped interface. The full engagement, usually two to six months.

UX audit

An expert review of your product against usability heuristics and accessibility standards, with findings prioritised by what they cost you.

Conversation design

Intents, call flows, escalation paths and the rules for where the model should stop. For voice agents and chat.

Design system and front end

A component library the developers actually build against, plus the HTML and CSS review that keeps the built product matching it.

Research and usability testing

Interviews, moderated sessions, personas and user flows. Run inside your delivery cycle so the findings arrive while they can still change something.

Fractional product design

A standing day or two a week for teams that need senior design judgment without a full time hire.

WireframingInteractive prototypingInformation architecture User interface specificationsWorkflow diagramsPersonas and user flows Card sortingJourney mappingAccessibility and WCAG 2.2 Design workshopsStakeholder interviewsData visualisation Responsive and cross browserDeveloper handoffAgile and Scrum delivery

What people said

From the people who had to work with the output.

"The role of a UX designer is not to simply produce pretty wireframes and usability concepts, but to gain an in depth understanding of the purpose of the product, how it fits into the workflows of users, and to make sure the end result acts as an enabler and not a hindrance. Luis achieved this."

Michael Reid Product Owner, LexisNexis Map View Global →

"His designs, user journeys, UX research reports and usability tests are always done with a focus on end users, dedication and high quality, and they were always clear and well reported at any stage, so that everyone in the team was on the same page."

Lorenzo Martino Backend engineer, Ericsson Digital Services Portal →

"His designs are excellent, and well presented in the sense that a non UX person was able to grasp the benefits and reasoning for doing things a certain way."

Oshi Kavadia DevOps, Ericsson Digital Services Portal →

"A passionate designer who was quick to offer compelling design solutions, often under pressure and to tight deadlines. Great with detail, open to new ideas, and fun to work with."

Marlon Bunday UX Designer, Ericsson Digital Services Portal →

"An excellent UI and UX designer with a broad range of experience. All feedback has been excellent from management and he has been a dream to work with."

Arron Conroy Recruiter, LexisNexis Map View Global →

Get in touch

Tell me what is not working.

The most useful first message is a sentence about the problem and a sentence about the constraint. I read everything and reply within two working days.

Based in
Guimarães, Portugal. Remote across the EU.
Languages
English, Italian, Spanish. Intermediate German and Portuguese.
Elsewhere
LinkedIn  ·  CV (PDF)