Skip to the page

Interface audits and clickable prototypes at a fixed price · Porto, Portugal

Felipe IxD

Interaction design studio · Porto

Every state of the screen, drawn before anyone writes code.

Felipe IxD sells three fixed-price packages to software teams: an interface audit of one product flow, a clickable prototype of one user flow, and a component sheet your own designers can build from. Price, scope and delivery date are agreed in writing before work starts.

An open sketchbook of hand-drawn screen wireframes with a yellow note of red annotations beside a keyboard 123 1 Screens sketched in order 3 Fix list ranked by harm
Pins 1–3: where a finding starts — the sketch, the note, the ranked list.
Three fixed-price packagesAudit, prototype, component sheet. No hourly meter.
Scope and date agreed up frontWritten down before the deposit is asked for.
Every state and edge case drawnEmpty, loading, error, success, and the odd ones.
Design only — no app buildsWe hand designs to your developers, not code.

Three packages, each written up as a spec sheet

Each package has a fixed scope and a fixed price. The numbered pins on the photo match the numbered notes beside it: what you get, in the order you get it.

Close view of wireframe sketches and a sticky note covered in red handwritten notes and crossings-out123
Package A · audit

Interface audit (one product flow)

€1,200

Every screen of one flow, annotated, with a ranked fix list. Ten working days.

  1. Screens captured in the order a person meets them, start to finish.
  2. Each problem pinned on the screen where it happens, with the heuristic it breaks.
  3. One fix list, ranked by how much harm the problem does, not by how easy it is.
  4. A recorded walk-through of the findings for the whole team.
Read the audit spec →
Coloured sticky notes labelled with interface parts laid over a sheet of squared paper123
Package B · prototype

Clickable prototype (one user flow)

€2,400

One flow, clickable, with every state and edge case drawn. Three to four weeks.

  1. The happy path first, then empty, loading, error and success for each screen.
  2. Edge cases listed in writing and drawn: long names, no results, a lost connection.
  3. Two test sessions with your team, run on the prototype itself.
  4. A recorded walk-through so absent colleagues see what changed and why.
Read the prototype spec →
A yellow notepad, a numeric keypad and a phone on a plain white desk123
Package C · components

Component sheet (up to 30 components)

€3,200

Buttons, inputs, tables, states and spacing tokens, documented for your own designers. Four to five weeks.

  1. An inventory of what your product already uses, merged where two parts do one job.
  2. Each component drawn in every state: default, hover, focus, disabled, error.
  3. Spacing scale, type scale and colour tokens named so developers can map them.
  4. Usage notes beside each part, and a recorded walk-through at hand-over.
Read the component spec →
Add-on · audit only

Extra flow on an audit

A second (or third) flow in the same product, reviewed to the same standard and merged into the same ranked list.

€450

What the studio draws

Interface audits

We walk one flow screen by screen and annotate what gets in a person's way. Every finding names the screen, the state it appears in and the heuristic behind it, so nobody argues about taste.

Clickable prototypes

One user flow made clickable, from the first tap to the last confirmation. The empty state, the loading state, the error state and the success state are drawn, not left for a developer to guess.

Component sheets

Buttons, inputs, tables, menus and their states, documented with spacing tokens and usage notes. Built so your own designers keep working from it after we have gone.

Recorded walk-throughs

Every package ends with a recorded walk-through of the deliverable. It explains each decision in plain words, so the colleague who missed the meeting does not have to rebuild the reasoning.

Extra flows on an audit

If one flow is not enough, add another for €450. It is reviewed the same way and folded into the same fix list, so priorities stay comparable across the product.

How a package runs, from first e-mail to hand-over

Felipe IxD is a small interaction-design studio working from Porto, Portugal. It does one kind of work: drawing how software behaves for the people using it. Each package is sold at a fixed price, and the price only covers a scope that has been written down. That is the whole model, and everything else follows from it.

A job starts with the form on the start-a-package page. You pick a package, name the product and the flow, and tell us roughly when you need it. The answer comes back inside two working days as a written scope: which screens, which states, what is out, the delivery date, and the price. If anything in your note is unclear, the reply asks about it before anything else happens.

When you accept the scope, a payment link arrives for the deposit — half the package price — through a secure checkout page. Work begins when the deposit arrives, not before. During the job you see progress at fixed checkpoints, not as a drip of half-finished screens. Annotations are written as we go, so the reasons arrive with the drawings.

Hand-over is a set of files you own, a written summary, and the recorded walk-through. The second half of the price is due then. Two rounds of revisions are included in every package; a third round is quoted separately before it starts, never added silently.

What the studio values

Exactness about states. Most interface trouble lives in the screens nobody drew: the list with nothing in it, the form that fails halfway, the name that is longer than the box. We draw those first, because they are where people give up.

What it turns down

  • Writing the app itself. We do not develop or code anything; your developers build from our files.
  • Hosting, domains, or anything about where the software runs.
  • Marketing, advertising or campaign management of any kind.
  • Promising a conversion rate, a revenue number or any other figure we cannot control.
Paper screen sketches spread across a dark table while a hand arranges them into a sequence
A flow laid out as paper screens before anything becomes clickable.

Questions teams ask before booking

What do you need to start an audit?

Access to the flow as a real user would see it — a test account on a staging build is ideal — plus one sentence on what the flow is meant to achieve. If there are known complaints, send them; we treat them as leads to check, not as conclusions. We do not need source code, analytics access or a brief longer than a page.

Do you work with our existing design files?

Yes. If your team already has screens in a shared design file, we work inside a copy of it and keep your layer names and styles where they are sound. For an audit we annotate the shipped product rather than the files, because the files and the product have usually drifted apart.

How long does a prototype take?

Three to four weeks for one user flow, depending on how many screens and edge cases the flow has. The written scope states the exact delivery date before you pay anything. If a flow turns out to be two flows, we say so in the scope and you decide whether to split it.

Who owns the files?

You do, once the final payment is made. That covers the design files, the written fix list or documentation, and the recorded walk-through. We keep the right to show an anonymised still of the work only if you agree to it in writing; by default we show nothing.

Can we pay in two parts?

That is the standard arrangement: half as a deposit when you accept the scope, half on hand-over. Both are paid through a secure link we send by e-mail. Nothing is charged by this website, and nothing is charged before you have agreed to a written scope.

Do you build the app as well?

No. The studio is design only. We hand your developers annotated files, a component sheet or a prototype, and we answer their questions about the design during the hand-over week. Writing the code, hosting it and putting it in front of users stays with your team.

A fixed price for a drawn, annotated answer.

Tell us the flow that worries you. The reply is a written scope, a date and a price — you decide from there, and nothing is owed until you accept.

Reaching the studio

Mailbox

[email protected] is the only address the studio uses. The form on the start page goes to the same place.

When it is read

Monday to Friday, during Porto working hours (Western European Time). Replies within two working days; weekends and Portuguese public holidays are not counted.

Where the studio works

From Porto, Portugal. Work is delivered by e-mail and shared files, so teams anywhere in Europe and beyond can book a package; sessions run by video call.