File Governance, Ethics, and Professional Practice

Introduction

A Figma file is more than a collection of frames, components, and prototypes. It is an organisational asset that may contain intellectual property, personal data, commercial strategy, research evidence, accessibility decisions, and records of stakeholder approval. Poor governance can cause accidental disclosure, conflicting versions, lost work, unlawful use of content, or the release of interfaces that manipulate or exclude users.

File governance is the system of policies, roles, controls, and practices used to manage design assets throughout their life cycle. In UI/UX work, governance connects design craft with professional accountability. It addresses who may access a file, who owns the work, how changes are recorded, when a prototype may be published, how confidential information is protected, and how ethical risks are identified before implementation.

This chapter presents a practical governance model for certificate-level UI/UX practice. It focuses on ownership, access, publishing, version control, privacy, security, licensing, consent, dark-pattern risks, accessibility, and organisational standards. The central principle is that designers are not merely makers of screens: they are custodians of decisions that affect people.

Learning Objectives

By the end of this chapter, you should be able to:

1. Explain ownership, authorship, stewardship, and accountability in collaborative design files.
2. Apply role-based access, naming, publishing, and version-control practices.
3. Identify privacy, security, licensing, and consent risks in Figma projects.
4. Recognise dark patterns and evaluate design decisions against user autonomy.
5. Integrate accessibility responsibilities into design governance.
6. Establish a practical file-governance standard for a design team.
7. Evaluate a design workflow using ethical, legal, and professional criteria.

1. The Governance Life Cycle of a Design Asset

A design asset passes through stages: creation, collaboration, review, publication, implementation, maintenance, archiving, and disposal. Governance should operate across all stages rather than being added at the end.

A useful distinction is made among four related concepts:

These concepts may belong to different parties. A designer can be the author while an employer owns the deliverable. A product manager may approve a release while a design-system lead stewards the component library. A client may own commissioned work, but the design team remains accountable for documenting accessibility and ethical concerns.

Governance is therefore not equivalent to restricting access. Good governance enables safe collaboration by making authority, expectations, and decision history visible.

2. Ownership, Intellectual Property, and Attribution

2.1 Ownership in employment and freelance work

Ownership is normally determined by applicable law and contract, not by the fact that a file was created in Figma. Employment agreements may assign copyright in work created within the scope of employment to an organisation. Freelance agreements may assign rights upon payment, retain rights with the creator, or grant a limited licence. Jurisdiction matters, and verbal assumptions are unreliable.

Before beginning a project, clarify:

• who owns source files, exported assets, prototypes, research outputs, and design-system contributions;
• whether the designer may display work in a portfolio;
• whether third-party fonts, photographs, icons, or plugins may be transferred;
• how pre-existing templates or components are treated;
• who may modify the work after handover; and
• what happens if the project is cancelled.

A design file can contain several rights layers. For example, a frame may be owned by the client, a font may be licensed only to the agency, a stock photograph may prohibit redistribution, and an open-source icon may require attribution or impose licence conditions. Ownership of the Figma file does not automatically transfer ownership of every embedded asset.

2.2 Authorship and contribution records

Collaborative design can make contribution difficult to see. Teams should record meaningful contributions in project documentation, decision logs, design-system records, or delivery notes. Attribution is particularly important for research, content design, illustration, photography, and externally supplied components.

Attribution should not be confused with granting access. A person can be credited without retaining edit permission, and a person can be given temporary access without becoming an owner.

2.3 Stewardship and handover

A handover should identify the file owner, workspace or project location, status, final approved version, linked libraries, fonts, external assets, known limitations, and archival date. It should also state whether the file is a source of truth or merely exploratory work. Without this information, teams may implement an outdated or unauthorised prototype.

3. Access Management and Workspace Structure

Access should follow the principle of least privilege: each person receives the minimum permission required to perform an authorised task. This principle reduces accidental changes and limits the impact of a compromised account.

Typical permission levels include viewing, commenting, editing, sharing, and administrative control. Exact labels vary by product plan and organisational configuration, but the governance logic remains consistent.

A practical workspace structure may contain:

• Working files: active exploration and iteration.
• Review files: controlled material prepared for stakeholder feedback.
• Approved or handoff files: material cleared for implementation.
• Libraries: shared components, styles, variables, and patterns.
• Archive: read-only historical material retained for reference or audit.

Use groups rather than individual invitations where possible. Group-based access improves consistency when people join, change roles, or leave. Review external collaborators periodically and remove access when the engagement ends. Shared links should be configured deliberately; a link that allows anyone to edit is not an appropriate default for confidential work.

A simple access register can include the following fields:

Multi-factor authentication, strong unique passwords, managed devices, and timely account deprovisioning are security controls rather than optional conveniences. Designers should not paste confidential screens into public plugins or upload sensitive research to unapproved services.

4. Naming, Metadata, and Organisational Standards

A governance standard should make a file understandable to someone who did not create it. Names should communicate product, platform, feature, status, and version without relying on personal memory.

For example:

Product_Feature_Platform_Status_YYYY-MM-DD

might produce:

TransitApp_Payment_iOS_Review_2025-03-08

Avoid ambiguous labels such as Final, Final2, or New version. If a file is superseded, mark it as archived and link to the approved replacement. Page names should describe their contents, such as 00 Read Me, 01 User Flows, 02 Components, and 03 Handoff, rather than Page 1 and Page 2.

A project read-me page should state:

• purpose and audience;
• owner and contributors;
• status and last review date;
• source-of-truth location;
• prototype limitations;
• linked libraries and external assets;
• known accessibility or content issues; and
• approval and handoff information.

Organisational standards should define naming conventions, file locations, component publication rules, review gates, archival periods, and responsibility for maintenance. Standards should be proportionate: a small student project does not need the same controls as a banking or healthcare product, but both need clear ownership and safe handling of sensitive information.

5. Version Control, Review, and Publishing

Version control is the practice of preserving a reliable history of change. Figma’s version history, named versions, comments, branching or duplication practices, and changelogs can support this purpose, but only when the team uses them consistently.

A useful version record contains:

• version identifier;
• date and time;
• author or responsible team;
• summary of changes;
• reason for change;
• review status;
• unresolved risks; and
• approval or rejection decision.

A version is not automatically approved because it is the most recent. Separate the states draft, in review, approved, implemented, and retired. Publishing a component library or sharing a prototype externally should be treated as a release event. Before release, check visual consistency, interaction states, content, accessibility, privacy, permissions, and links.

A lightweight review gate can ask:

1. Is the file in the correct workspace and folder?
2. Are confidential data and test credentials removed?
3. Are all assets properly licensed?
4. Is the intended audience authorised to view the prototype?
5. Has the appropriate design, product, accessibility, and legal review occurred?
6. Is the version clearly labelled and recoverable?

Branching and parallel work

When several designers work simultaneously, establish a primary source of truth and define how changes return to it. Parallel exploration is useful, but uncontrolled duplication produces conflicting components and contradictory decisions. Before merging work, compare interactions, tokens, content, and accessibility states rather than relying only on visual similarity.

Publishing libraries

A shared library is a production dependency. A poorly governed component update can affect many screens. Use change notes, semantic labels such as Added, Changed, or Deprecated, and a defined owner. Breaking changes should be communicated before publication, and deprecated components should remain documented long enough for teams to migrate safely.

6. Privacy, Confidentiality, and Security

Privacy concerns the appropriate collection, use, storage, sharing, and deletion of information about identifiable or potentially identifiable people. Security concerns protection against unauthorised access, alteration, loss, or disclosure. They overlap but are not identical.

Design files may contain names, email addresses, photographs, health information, financial details, interview recordings, support tickets, or screenshots of real accounts. Even a combination of seemingly harmless data can identify a person. Use fictional or synthetic data in prototypes whenever possible. If real data is necessary, minimise it, restrict access, document the purpose, and remove it when no longer required.

Important practices include:

• classify files by sensitivity;
• use placeholders instead of production records;
• redact or mask personal information;
• avoid storing passwords, API keys, or access tokens in layers or comments;
• use approved storage and plugins;
• check public sharing links; and
• report accidental disclosure promptly.

Privacy laws differ by jurisdiction, but common principles include purpose limitation, data minimisation, accuracy, security, retention limitation, and respect for individual rights. A design team should involve the organisation’s privacy or legal specialist when processing sensitive or large-scale personal data. Designers should not claim that a prototype is compliant merely because it looks professional.

Consent in research and testing

Consent is meaningful only when people understand what participation involves, what data will be collected, how it will be used, who may see it, and whether participation is voluntary. Consent should not be hidden in confusing language or obtained through pressure. Participants should be able to withdraw where practicable, and teams should distinguish consent to participate from consent to use a photograph, quotation, or recording publicly.

7. Licensing and Ethical Use of Design Materials

Licensing determines what a person may do with a font, icon, image, illustration, plugin, template, or code resource. “Found online” does not mean “free to use.” A licence may permit personal use but prohibit commercial use, require attribution, restrict modification, or prohibit redistribution as part of another product.

Maintain an asset register containing the asset name, creator, source, licence, permitted uses, attribution requirement, acquisition date, and renewal or expiry condition. Check whether an asset licence covers the intended territory, audience, platform, and duration.

Common categories include proprietary licences, commercial licences, public-domain material, and open licences. Open licences are not all equivalent. Some require attribution; some require derivative works to use the same licence; some limit use of trademarks or impose notice requirements. The exact licence text should be consulted rather than inferred from a label.

AI-generated or AI-assisted assets introduce additional questions: what data was used to train a system, whether outputs resemble protected work, whether the tool grants commercial rights, whether confidential prompts are retained, and whether the output contains personal data. Organisational policy should specify approved tools, disclosure expectations, human review, and prohibited inputs. AI assistance does not remove the designer’s responsibility to verify originality, accuracy, accessibility, and suitability.

8. Ethical Design and Dark Patterns

Ethical design respects user agency, supports informed choice, and avoids unnecessary harm. A dark pattern is an interface practice that steers, deceives, or pressures people into actions they would not freely choose. Examples include:

• making “accept all” prominent while hiding refusal;
• preselecting paid add-ons;
• using confusing wording to obtain consent;
• disguising advertising as ordinary content;
• making cancellation substantially harder than subscription;
• showing false urgency or scarcity; and
• using shame or ridicule when a user declines.

Not every persuasive design is unethical. Clear reminders, helpful defaults, and recommendations can benefit users when they are transparent, reversible, and aligned with user interests. The key questions are whether the choice is understandable, whether alternatives are genuinely available, whether consequences are visible, and whether the user can change their decision without unreasonable effort.

A practical ethical review can score a proposed pattern against four questions:

1. Transparency: Can users understand what will happen?
2. Freedom: Can users refuse or exit without undue pressure?
3. Proportionality: Is the requested action necessary for the stated purpose?
4. Reversibility: Can users undo the decision easily?

A “no” should trigger redesign or escalation. Ethical review should include people outside the immediate design team because teams can normalise manipulative conventions through repeated exposure.

9. Accessibility as a Governance Responsibility

Accessibility is not a final visual inspection. It is a governance responsibility embedded in requirements, components, content, testing, and release decisions. Designers should consider users with visual, auditory, motor, cognitive, speech, and temporary or situational disabilities.

Practical responsibilities include:

• sufficient text and non-text contrast;
• meaningful focus order and visible focus states;
• keyboard and alternative-input operability;
• labels and instructions that do not depend only on colour;
• readable typography and scalable content;
• error prevention and recovery;
• captions, transcripts, and alternatives for media;
• semantic structure represented in handoff notes; and
• testing with assistive technologies where appropriate.

Accessibility standards such as the Web Content Accessibility Guidelines can provide criteria, but conformance is not the same as usability. A colour contrast checker cannot determine whether instructions are understandable or whether a task is operable with a screen reader. Teams should document known limitations and avoid describing an untested prototype as fully accessible.

A component library should include accessibility guidance alongside visual properties. For example, a button component should specify states, label requirements, disabled-state meaning, focus treatment, and minimum interaction considerations—not merely colour and radius.

10. A Professional Governance Framework

The following six-part framework can be applied to most Figma projects:

1. Classify: Identify ownership, sensitivity, intended audience, and project status.
2. Assign: Name the owner, steward, reviewers, approvers, and external parties.
3. Control: Apply least-privilege access, secure storage, and approved tools.
4. Record: Maintain versions, decisions, licences, consent evidence, and known limitations.
5. Review: Conduct design, accessibility, privacy, security, ethical, and legal checks proportionate to risk.
6. Retire: Archive, revoke access, preserve necessary records, and delete data according to policy.

This framework is a governance cycle rather than a linear checklist. A major change in audience, data, platform, or business purpose should return the project to classification and review.

Responsibility matrix

A simple responsibility matrix prevents assumptions. For each activity, identify who is responsible for doing the work, accountable for the outcome, consulted for specialist advice, and informed of the decision.

The labels need not follow one universal methodology; their purpose is to make decision rights explicit.

11. Applied Case: Illustrative Subscription Service

Background

A fictional company, StreamBox, is redesigning its subscription-management flow in Figma. The team includes two designers, a product manager, an engineer, a researcher, and an external marketing agency. The prototype includes account screenshots, pricing experiments, and a new cancellation journey.

Problem

The marketing agency requests an open edit link. The prototype uses screenshots containing real customer names and account balances. The proposed flow places the cancellation option under several menus and presents a large “Keep Premium” button beside a low-contrast cancellation link. A stock photograph has been copied from a search result, and the team labels the latest file Final Final.

Analysis

The project has several governance failures. An open edit link violates least privilege. Real account information creates privacy and security risk. The cancellation flow presents a potential obstruction and therefore requires an ethical review. The photograph may lack a suitable commercial licence. Ambiguous naming weakens version control and makes approval status unclear.

Approach and solution

The design lead first classifies the project as confidential and names the product manager as accountable for release. The team creates a restricted review file and gives the agency comment-only access. Real screenshots are replaced with synthetic data. The workspace administrator enables multi-factor authentication and confirms that no credentials or tokens are present.

The team records the current version as 0.8 Review, creates a changelog, and defines the next approved release as 1.0. The cancellation path is redesigned so that it is visible, understandable, and no harder to complete than continuation. The team adds a clear summary of consequences, a reversible confirmation step, and an accessible focus order.

The researcher documents consent for any participant quotations. The marketing agency replaces the photograph with an asset whose licence permits the intended use. The accessibility reviewer checks labels, contrast, keyboard order, error recovery, and text resizing. Product and legal reviewers approve the release, while the read-me page records remaining prototype limitations.

Outcome

The team produces a controlled prototype with synthetic data, traceable decisions, appropriate permissions, licensed assets, and a transparent cancellation experience. Implementation receives a clearly identified source of truth rather than a collection of conflicting files.

Learning points

1. Governance problems often appear as ordinary workflow shortcuts.
2. Ethical, privacy, accessibility, and security review should occur before publication.
3. A polished interface can still be professionally defective.
4. Clear ownership and version status reduce implementation error.
5. User autonomy must be considered alongside business objectives.

12. Challenges and Limitations

Governance can create friction. Excessive approval layers may slow experimentation, discourage collaboration, and cause teams to bypass official processes. Controls should therefore be risk-based. A confidential healthcare prototype and a low-risk classroom exercise should not require identical review.

Governance also has limits. A permission setting cannot prevent every screenshot or deliberate misuse. A licence register cannot prove that every asset is legally valid in every jurisdiction. An accessibility checklist cannot replace testing with disabled users. A privacy notice cannot make an unjustified data collection practice ethical. Governance improves decision quality, but it does not substitute for professional judgement.

Distributed and remote teams create further challenges. Time zones, contractors, changing project membership, and multiple tools can fragment responsibility. Teams should use a small number of approved systems, document decisions where collaborators can find them, and review access at meaningful milestones.

13. Best-Practice Checklist

Before creating a project:

• confirm ownership, portfolio, and handover terms;
• classify sensitivity and identify the accountable owner;
• choose the approved workspace and naming convention;
• define research-consent and data-handling requirements.

During design:

• use synthetic or minimised data;
• apply least-privilege permissions;
• record important decisions and contributions;
• verify licences before embedding assets;
• design accessible states, not only the ideal state;
• challenge defaults and persuasive patterns.

Before publishing or handing off:

• confirm the source-of-truth version;
• remove secrets and unnecessary personal information;
• check links, permissions, libraries, and prototype settings;
• complete appropriate ethical, privacy, security, legal, and accessibility reviews;
• document limitations and unresolved risks.

After delivery:

• archive superseded work;
• revoke unnecessary access;
• maintain component and licence records;
• preserve required evidence of consent and approval; and
• review the governance process after incidents or major changes.

Chapter Summary

File governance makes UI/UX work controllable, explainable, and responsible. Ownership, authorship, stewardship, and accountability are different concepts and should be clarified contractually and operationally. Access should follow least privilege, while naming, metadata, version history, review gates, and publishing rules establish a reliable source of truth.

Privacy and security require data minimisation, synthetic content, approved tools, careful sharing, and timely access removal. Licensing applies to every embedded font, image, icon, template, plugin, and AI-assisted asset. Consent must be informed and voluntary. Ethical practice requires designers to identify dark patterns and protect transparency, freedom, proportionality, and reversibility. Accessibility belongs in requirements, components, testing, and release governance rather than being treated as a final visual check.

A practical governance cycle is to classify, assign, control, record, review, and retire. Applied proportionately, this cycle supports collaboration without eliminating creativity and helps designers meet professional, organisational, legal, and user responsibilities.

Key Terms

Ownership: Legal or contractual control over a design asset.

Authorship: Recognition of a person’s creative or intellectual contribution.

Stewardship: Ongoing responsibility for maintaining and protecting an asset.

Accountability: Responsibility for the consequences of a decision or release.

Least privilege: Providing only the access necessary for an authorised task.

Source of truth: The designated, authoritative version of a design or component.

Version control: Recording and managing changes across the life of a file.

Changelog: A record describing changes between versions.

Design system: Organised components, patterns, guidance, and standards used across products.

Library publishing: Making shared components, styles, or variables available for reuse.

Privacy: Appropriate control of information relating to identifiable people.

Security: Protection against unauthorised access, alteration, loss, or disclosure.

Data minimisation: Collecting and retaining only data necessary for a defined purpose.

Consent: Voluntary, informed agreement to participation or data use.

Licence: Permission and conditions governing use of an asset.

Dark pattern: A design practice that manipulates or deceives users into an unwanted action.

Accessibility: Designing products so people with diverse abilities can perceive, operate, understand, and use them.

Synthetic data: Artificially generated data that does not represent a real individual.

Handover: The controlled transfer of files, assets, decisions, and responsibilities.

Governance: Policies, roles, controls, and practices that guide responsible management.

Review Questions

Short Answer Questions

1. Distinguish ownership from stewardship in a collaborative Figma project.
2. What is the principle of least privilege, and why is it useful?
3. Give two examples of information that should not be placed in a public prototype.
4. Why does possession of a Figma file not guarantee ownership of every embedded asset?
5. State two characteristics of an ethical alternative to a dark pattern.

Long Answer Questions

1. Explain how naming, version control, review gates, and publishing practices work together to create a reliable source of truth.
2. Discuss the privacy and security risks of using real customer screenshots in a design prototype and propose controls.
3. Explain why accessibility should be governed throughout the design life cycle rather than checked only before release.
4. Describe a practical organisational standard for managing a shared Figma component library.
5. Compare authorship, ownership, attribution, and accountability using an example from a multidisciplinary design project.

Analytical / Application Questions

1. A contractor asks for an unrestricted edit link to a confidential prototype containing interview notes. Analyse the risks and propose a safer collaboration arrangement.
2. A subscription interface makes joining easy but places cancellation behind several confusing screens. Evaluate the design using transparency, freedom, proportionality, and reversibility.
3. Design a six-step governance plan for a mobile-health prototype that contains sensitive participant information and will be reviewed by an external partner.

Multiple Choice Questions with Answers

Question 1

Which concept describes the ongoing responsibility for maintaining and protecting a design asset?

A. Ownership

B. Stewardship

C. Authorship

D. Attribution

Correct Answer: B. Stewardship

Question 2

What does the principle of least privilege require?

A. Giving every stakeholder edit access

B. Giving users the minimum access needed for an authorised task

C. Allowing public links for rapid collaboration

D. Removing all access after the first review

Correct Answer: B. Giving users the minimum access needed for an authorised task

Question 3

Which practice best reduces privacy risk in a prototype?

A. Using real customer records for realism

B. Embedding production credentials in hidden layers

C. Replacing personal information with synthetic data

D. Publishing the file and relying on obscurity

Correct Answer: C. Replacing personal information with synthetic data

Question 4

Why should a design team maintain an asset licence register?

A. To increase the number of pages in a file

B. To document permitted uses and attribution or renewal requirements

C. To replace the need for design review

D. To guarantee that every online image is free to use

Correct Answer: B. To document permitted uses and attribution or renewal requirements

Question 5

Which situation is most clearly a dark-pattern risk?

A. Providing a visible undo action

B. Showing a clear summary before confirmation

C. Making refusal difficult while making acceptance prominent

D. Using descriptive labels for form fields

Correct Answer: C. Making refusal difficult while making acceptance prominent

Question 6

Which statement about accessibility governance is most accurate?

A. Accessibility is only a colour-contrast issue

B. Accessibility should be considered in requirements, components, testing, and release decisions

C. Accessibility is the sole responsibility of the developer

D. A checklist eliminates the need for user testing

Correct Answer: B. Accessibility should be considered in requirements, components, testing, and release decisions

Question 7

What is the primary purpose of a changelog?

A. To hide earlier versions

B. To record changes and their reasons between versions

C. To assign legal ownership automatically

D. To replace access controls

Correct Answer: B. To record changes and their reasons between versions

Question 8

Which action is most appropriate when an external collaborator finishes a project?

A. Keep unrestricted access indefinitely

B. Publish the file publicly

C. Review and revoke unnecessary access

D. Delete all project history immediately

Correct Answer: C. Review and revoke unnecessary access

Question 9

Which question best tests reversibility in an ethical review?

A. Is the interface visually fashionable?

B. Can users undo or change the decision without unreasonable effort?

C. Does the file contain enough frames?

D. Has every layer been renamed?

Correct Answer: B. Can users undo or change the decision without unreasonable effort?

Question 10

Which status most clearly indicates that a file has been cleared for implementation?

A. Exploration

B. Draft

C. In review

D. Approved

Correct Answer: D. Approved