UX Designer Contract (2026): Source Files + Research IP

A freelance UX designer who has just delivered a $12,000 research-and-prototype engagement, and whose client is now demanding every Figma file, all the interview transcripts, and the journey maps, learns that "the design" was never one thing. A UX project produces at least three different kinds of intellectual property, and a contract that assigns "the work" without separating them either gives away too much or starts a fight at handoff. The fix is to treat the engagement as three IP buckets, each with its own clause, plus a carve-out for the reusable components the designer carries between clients.

This is the UX counterpart to the graphic designer contract, which covers source files and stock licensing for graphic work. The general IP framework is in the freelancer IP ownership guide, the project value is anchored in the UX salary vs freelance rate report, and the billing is in the UX designer invoice guide.

The three IP buckets · UI deliverables · Figma source files · User-research IP · Design-system components

The Three IP Buckets

The reason generic design contracts fail UX work is that they treat the output as a single deliverable to be assigned wholesale. A UX engagement actually produces three categories of IP with three different default owners and three different appropriate clauses:

1. The UI design: wireframes, prototypes, and final screens, the visible output.
2. The editable source files: the working Figma file, which is a separate and more valuable asset than a flattened export.
3. The user-research artifacts: personas, journey maps, usability findings, and the raw interview data behind them.

Naming the three buckets in the contract is what lets the designer assign the UI to the client, decide deliberately about the source files and research, and keep the reusable components. The rest of this post is the clause for each.

UI Deliverables and the Assignment Clause

The visible design is what the client is primarily buying, and assigning it is straightforward, with two conditions. First, copyright does not move on payment alone. Per Ludwig IP Law, "paying for creative work typically grants you the permission to use it, not ownership of the copyright." Second, the transfer must be in writing. Per 17 U.S. Code § 204, "a transfer of copyright ownership, other than by operation of law, is not valid unless an instrument of conveyance, or a note or memorandum of the transfer, is in writing and signed by the owner of the rights conveyed."

This is true of UX deliverables specifically. Per Perkins Thompson, "copyright remains with the person or company that created the deliverables until there is a written agreement that assigns (transfers) the copyright to another party," and as a result "you cannot use, store, or modify the UX design deliverables until you have secured the I.P. rights to do so." The clause should assign the UI deliverables to the client and vest that assignment on cleared final payment, which keeps the leverage of nonpayment with the designer.

Figma Source Files

The editable Figma file is the bucket most contracts ignore, and it is where the $12,000-project dispute usually starts. Two facts shape the clause.

First, the platform default favors the designer. Per Figma's help documentation, "when you create a file, Figma will make you the owner of that file," and transferring ownership to someone else requires a deliberate transfer action, separate from granting view or edit access. A client invited to view or even edit a file is not its owner.

Second, handing over working files is a negotiated right, not an automatic one. Per AIGA San Francisco, "clients do not automatically own everything you create for their project," and "only usage rights that allow the client to create derivative works, or re-use your work for other projects, should include delivery of your working files." The same source recommends a provision "making it clear that no usage rights are granted, and no digital files will be delivered, until full and final payment has been received."

So the contract should state explicitly whether the deliverable is a view-only handoff or a full transfer of the editable Figma file, and if it is a transfer, price it as the more valuable asset it is and release it only on final payment. This is the same source-versus-output distinction a photographer draws between delivered JPEGs and RAW files, covered in the photographer contract guide.

User-Research IP

Research is the bucket unique to UX, and it has two layers: the artifacts and the raw participant data.

The artifacts are protected IP like any other deliverable. Per Perkins Thompson, the protected deliverables include "research reports, descriptions of personas, sitemaps, user journeys and flows." Treat them the same way as the UI: assigned to the client on final payment if the engagement covered research delivery, or retained if it did not.

The raw data is different, because it involves third parties. Raw interview recordings and transcripts capture identifiable people, and under GDPR those people have rights independent of any designer-client IP arrangement. Per ParticipantKit, "user researchers must obtain explicit consent from participants before collecting their personal data," and participants retain the right to access their data, to have it rectified, and to have it erased. The contract should state what happens to raw recordings and transcripts at handoff: whether they transfer at all, whether they are anonymized first, and how participant consent constrains reuse. Handing a client a folder of raw recordings can create a data-protection obligation, not just an IP transfer. (This GDPR layer applies to engagements involving EU or UK participants; US-only engagements turn on the contract and applicable state law.)

Design-System Component Licensing

The last bucket protects the designer, not the client. A UX designer who builds design systems carries reusable components, patterns, and tokens between projects. A broad "all work product is assigned" clause can sweep those reusable assets into one client's ownership.

The default starts in the designer's favor: per Flag Red, "in many cases, the freelancer retains ownership unless the contract explicitly assigns rights to the client." The background-IP carve-out makes that explicit. The structure most industry agreements use, including the AIGA Standard Form of Agreement for Design Services, is to keep the designer's reusable tools as the designer's property and grant the client a license to use them within the delivered product:

• The client receives a license to use the reusable components as part of the specific product they were built into.
• The designer retains ownership of the component library, patterns, and tokens, and may reuse them on other projects.
• The bespoke, client-specific design assignments to the client; the generic, reusable infrastructure stays with the designer.

Without the carve-out, a designer can accidentally assign their entire reusable toolkit to a single client. The general assignment-versus-license framework is in the freelancer IP ownership guide.

Copy-Paste Clause Checklist

Build the full contract with these clauses in the free FreelanceDesk contract generator, or start from the best free contract templates roundup and add the source-file and research-IP language.

References

• Transfer Ownership of Files or Projects, Figma Help Center
• Do You Have to Give Your Freelance Client Your Digital Files?, AIGA San Francisco
• UX Design Agreements: 4 Essential Clauses to Include, Perkins Thompson
• Why Paying for Creative Work Doesn't Give You Copyright Ownership, Ludwig IP Law
• 17 U.S. Code § 204: Execution of Transfers of Copyright Ownership, Legal Information Institute
• IP Ownership in Freelance Agreements, Flag Red
• GDPR for User Research, ParticipantKit