Safety Norms: UI/UX and Digital Product Design

1Purpose, Scope, and Safety Principles

These norms apply to anyone who researches, plans, designs, prototypes, tests, or reviews digital products, including students, freelancers, in-house teams, and contractors. They cover user research, wireframing, visual design, interaction design, usability testing, design system work, and handoff to developers. They do not replace engineering security reviews, legal review, or accessibility audits performed by qualified specialists.

The core principle is that a design is safe only when it does not foreseeably cause users, participants, or the designer harm. Mandatory rules are marked as must. Recommendations are marked as should. Where a local law, regulator, or platform policy applies, that requirement takes precedence over these norms.

• Must: Do not design interfaces intended to deceive, coerce, or trap users.
• Must: Do not collect or test with personal data beyond what the stated purpose requires.
• Should: Record the reason for each significant design decision in a shared decision log.

2Roles, Competence, and Accountability

Every project needs a named accountable owner, usually the product lead or design lead, who approves the research plan, release scope, and risk acceptance. Individual designers remain responsible for their own work and must raise concerns they cannot resolve. Engineers, content writers, legal reviewers, and accessibility specialists each own their part of the safety review.

Competence matters. Designers should not run research with vulnerable groups, health or financial tools, or children's products unless they have received training or are supervised by a qualified researcher or specialist. Tasks outside a person's authorization must be handed to someone who holds it.

• Must: Assign one accountable owner for each project and record the name in the project brief.
• Must: Route research involving minors, health information, financial data, or vulnerable adults to a trained researcher and an approved ethics or review process.
• Should: Schedule short role briefings so that writers, developers, and designers know who approves which decisions.
• Should: Provide a named contact for concerns that is independent of the reporting line when possible.

3Realistic Activities, Hazards, and Risk Levels

Typical activities include interviews, diary studies, moderated and unmoderated usability tests, card sorting, A/B experiments, analytics review, prototype sharing, and public design critiques. Hazards arise from who is involved, what data is handled, how the interface nudges behavior, and where work is shared. Risk is judged by likelihood and severity, and higher-severity hazards need stronger controls before work begins.

Common hazards include recording participants without clear permission, exposing real personal data in screenshots, using dark patterns that hide costs or cancellation paths, excluding users with disabilities, copying protected images or code, and publishing prototypes that reveal confidential roadmaps. Designers also face psychological hazards from abusive feedback, harassing comments on public posts, and long crunch periods.

• High: Testing with minors, patients, people in crisis, or users of financial or safety-critical tools.
• High: Publishing real customer data, credentials, or unreleased security features.
• Medium: Experiments that change prices, offers, or access for live users.
• Medium: Public sharing of work-in-progress that may generate harassment.
• Low: Internal wireframe reviews with synthetic content and no personal data.

4Preventive Controls and Safe Design Practices

Prevention starts before any screen is drawn. Teams should define the user goal, the harm that could result from a poor design, and the controls that prevent it. Design reviews should include a deliberate check for manipulative patterns, unclear consequences, and missing alternatives. Where a decision could affect money, health, safety, or legal rights, the reviewer should confirm that the user can understand the choice and reverse it.

Safe design practice also means using synthetic or anonymized content in prototypes, labeling test environments clearly, and limiting experiments to safe sample sizes and reversible changes. A dark pattern is any interface element that steers users against their own interests, such as hidden fees, confusing opt-outs, or false urgency. Teams must not ship these even when they are profitable.

• Must: Use synthetic names, addresses, and payment data in all prototypes and screenshots.
• Must: Make cancellation, refund, and data deletion paths at least as easy to find as sign-up paths.
• Must: Show prices, fees, and material conditions before the user commits.
• Must: Stop any experiment that causes a user to lose access to a safety feature or essential service.
• Should: Run a manipulation review checklist before each major release.
• Should: Provide clear error messages that state what went wrong and how to fix it.

5Research Participants, Consent, and Rights

Participants have rights to information, withdrawal, and respectful treatment. Before any session, the researcher must explain the purpose, what will be recorded, who will see the results, how long data is kept, and how to stop at any time. Consent should be specific and recorded. Compensation must not be so large that it pressures participation, and no participant should be penalized for declining or leaving.

Recording requires particular care. Audio, video, and screen capture can capture faces, homes, and bystanders. Researchers should ask bystanders to leave the room or move out of frame, and they should avoid asking participants to share private accounts or messages. Consent rules differ by jurisdiction and by institution, so teams should confirm local requirements with their ethics or privacy office.

• Must: Obtain documented consent before recording any session.
• Must: Tell participants they may stop or skip any question without giving a reason.
• Must: Do not test with real customer accounts unless the account holder has explicitly agreed in writing and the purpose is approved.
• Should: Offer breaks, accessible formats, and support persons where requested.
• Should: Delete raw recordings on the schedule stated in the consent form.

6Privacy, Copyright, Platform Rules, and Truthful Communication

Privacy law and platform policies shape almost every design. Data minimization means collecting only what a feature needs. Designers should specify default settings that protect users, explain data uses in plain language, and avoid hiding consent inside long terms. Privacy-impacting features should be reviewed by a qualified privacy professional before release, and the requirements that apply depend on jurisdiction and business sector.

Copyright and licensing also require discipline. Stock images, icons, fonts, and code snippets may carry license terms that restrict commercial use, modification, or attribution. Designers must keep records of license sources. Marketing claims in interfaces, app store listings, and onboarding copy must be accurate and substantiated, and any claim about security, accessibility conformance, or health outcomes needs evidence reviewed by the responsible owner.

• Must: Use only assets whose license permits the intended use, and keep the license record with the project file.
• Must: Do not claim accessibility conformance, security certification, or regulatory approval unless a qualified assessment supports it.
• Must: Follow the current platform policies for the app store or host where the product will appear.
• Should: Maintain a privacy impact review for features that process personal, location, biometric, or sensitive data.
• Should: Use accessible contrast, text size, and keyboard navigation as baseline design targets, measured against a recognized standard such as WCAG, whose current version should be confirmed with an accessibility specialist.

7Workspace, Wellbeing, and Reputational Safeguards

Designers work at desks, in shared studios, and remotely. Workspace hazards include poor screen setup, prolonged static posture, eye strain, and unmanaged cables. Teams should provide adjustable seating and monitor arms where feasible, schedule breaks away from screens, and allow flexible tools for those with ergonomic needs. Where workplace health and safety rules apply, confirm the local obligations with the employer's safety office.

Public feedback and social media can create serious reputational and personal risk. Designers should not post unreleased work, personal data, or internal discussions. Harassment should be reported rather than answered in public. Organizations must have a clear path for reporting abuse and for removing or moderating threatening content on channels they control.

• Should: Set screens at eye level with a reference distance that suits the user's vision, and review setup on request.
• Should: Take short breaks from screens at intervals set by the team's workplace health rules.
• Must: Do not post confidential designs, customer data, or participant identities in public channels.
• Must: Report threats or harassment to the accountable owner and the platform, and preserve evidence.
• Should: Give designers the right to decline work that conflicts with these norms without retaliation.

8Incidents, Escalation, and Emergency Response

An incident is any event in which a user, participant, designer, or the organization is harmed or exposed to a serious risk. Examples include a data leak in a prototype, a live experiment that blocked access to a payment page, a participant distressed during a session, or a design that was reported as discriminatory. Near misses, such as a screenshot caught before posting, should also be logged because they reveal weaknesses in controls.

Immediate safety comes first. If a participant appears in distress or in danger, the researcher must stop the session and follow the local emergency procedure, which may mean contacting emergency services or a designated support person. Designers must not attempt clinical, legal, or crisis intervention themselves. Data incidents must be escalated to the privacy or security team as soon as they are identified, and the responsible owner must decide on notifications required by law.

• Must: Stop the activity, secure the affected data, and notify the accountable owner immediately.
• Must: Contact emergency services or designated support when a person may be at risk of serious harm.
• Must: Report suspected personal data exposure to the privacy or security function without delay.
• Should: Log near misses with cause, control gap, and corrective action.
• Should: Keep a contact list for legal, privacy, security, and communications contacts.

9Records, Training, Review, and Improvement

Records make safety checkable. Each project should hold a research plan, consent forms, license records, decision logs, privacy reviews, and experiment settings. Training should cover consent, privacy basics, accessibility, manipulation risks, and incident reporting, and it should be refreshed when processes or regulations change. Records should be retained only as long as required by policy or law, and personal data inside records should be minimized.

Review should be scheduled and triggered by events. Teams should review these norms after major incidents, significant platform policy changes, or new product categories. Lessons learned should be shared across teams, and the norms should be revised through a documented approval process.

• Must: Keep signed consent records separate from research notes and store them under restricted access.
• Must: Complete training in consent, privacy, and accessibility before running research or shipping live experiments.
• Should: Hold a short retrospective after each significant project or incident.
• Should: Review this document at planned intervals and after any significant incident, and assign an owner for the revision.

Implementation checklist

• Confirm the accountable owner and the approval path for the project.
• Use synthetic data in every prototype, screenshot, and public share.
• Obtain documented consent before any recording or sensitive session.
• Check the design for dark patterns, hidden costs, and hard-to-find cancellation paths.
• Verify license terms for every image, icon, font, and code asset.
• Confirm accessibility targets with a specialist before claiming conformance.
• Review privacy impact for any feature that handles personal or sensitive data.
• Report incidents, near misses, and harassment to the owner immediately and preserve evidence.
• Verify current laws, standards, and platform policies with qualified professionals before release.