vaayaa Inclusive Education
Creative risk assessment

UI/UX and Digital Product Design Risk Assessment: Usability, Scope, Handoff and Ethical Controls

A worked example of how a digital product design team identifies, scores and controls the risks that threaten usable, accessible, private and on-time products, from unclear briefs and scope creep to handoff defects and manipulative patterns.

Updated November 2026 8 hazards assessed Review every 3 months Highest risk: Critical to Medium
See the UI/UX and Digital Product Design course

Executive summary

This assessment shows how a small digital product design team can find, rate and control the risks that matter most to users, clients and the studio. Eight risks were selected because they are plausible in everyday product design work. Unclear briefs, accessibility gaps and usability failures are likely and affect many people, while data exposure carries the highest impact. Each risk is scored before controls and again after existing and added controls. Most risks fall to Medium or Low once the added controls are in place, but data exposure stays High because a single leak is serious. The first actions are a written brief with a change process, a clear test plan with real users, a keyboard and screen reader check and synthetic test data. The studio is a teaching example, so every score illustrates method rather than a real product.

Focus area
UI/UX and digital product design
Setting
Product design team in a small studio delivering a web and mobile application for an external client
Method
Likelihood by impact design risk register

Scope

This assessment covers a small product design team building one web and mobile application for a client, from discovery research and wireframes through prototyping, usability testing, visual design and developer handoff. It considers risks to end users, client data, schedule, budget, intellectual property and reputation. Jurisdiction, client sector, team size, tools and accessibility obligations are assumptions made for teaching and are not specified.

Context

The team has a lead product designer, two UI designers, a researcher who runs interviews and tests, and a project manager who holds the client relationship. Designers work in a shared design tool with a component library, and developers receive specifications through that tool and a ticketing board. Prototypes contain real client data copied from a staging system. The client signs off each stage in writing, and a final review happens before release. Each risk is scored before controls to show its natural level, then again after the existing controls and the additional controls that should be added.

Objectives, assets and stakeholders

The objective is to deliver a product that people can use, can access, trust and finish, on a schedule and budget the client accepted. The assets in scope are the user experience and design system, the research findings, the design files and prototypes, client and user data in test environments, licensed assets and the studio reputation. Stakeholders include end users, including people with disabilities, the client sponsor, developers, researchers, designers, the project manager and the studio owners. Clear roles matter: every risk has one owner role, the project manager keeps the register current, and the lead product designer reports to the client at each stage gate.

Risk matrix: before and after controls

Each cell shows hazard numbers placed by likelihood and impact. Compare the two grids to see how controls move each hazard.

Before controls

Inherent risk

Risk before controls: rows are likelihood from almost certain to rare, columns are impact from insignificant to catastrophic. Cells list hazard numbers.
1
Insignificant		 2
Minor		 3
Moderate		 4
Major		 5
Catastrophic
5 Almost certain
4 Likely Likelihood 4, impact 3, score 12, high: H02 H04 Likelihood 4, impact 4, score 16, high: H01 H07 Likelihood 4, impact 5, score 20, critical: H05
3 Possible Likelihood 3, impact 3, score 9, medium: H06 Likelihood 3, impact 4, score 12, high: H03
2 Unlikely Likelihood 2, impact 5, score 10, high: H08
1 Rare

After controls

Residual risk

Risk after controls: rows are likelihood from almost certain to rare, columns are impact from insignificant to catastrophic. Cells list hazard numbers.
1
Insignificant		 2
Minor		 3
Moderate		 4
Major		 5
Catastrophic
5 Almost certain
4 Likely
3 Possible Likelihood 3, impact 3, score 9, medium: H07
2 Unlikely Likelihood 2, impact 2, score 4, low: H04 H06 Likelihood 2, impact 3, score 6, medium: H01 H02 Likelihood 2, impact 4, score 8, medium: H03 H05 H08
1 Rare
  • Low 1 to 4
  • Medium 5 to 9
  • High 10 to 16
  • Critical 17 to 25

Hazard register

A summary first, then the detail for each hazard.

Summary of hazards with scores before and after controls
No.HazardBeforeAfterOwner
H01 Unclear brief and uncontrolled scope creep 16 High 6 Medium Lead product designer
H02 Usability failures in core user journeys 12 High 6 Medium Lead researcher
H03 Accessibility barriers excluding users 12 High 8 Medium UI design lead
H04 Handoff and version control errors reaching production 12 High 4 Low Design operations lead
H05 Exposure of client data and confidential prototypes 20 Critical 8 Medium Project manager
H06 Unlicensed images, fonts and third party assets 9 Medium 4 Low Lead product designer
H07 Schedule and budget overrun from optimistic plans 16 High 9 Medium Project manager
H08 Dark patterns and culturally insensitive content 10 High 8 Medium Creative director
H01

Unclear brief and uncontrolled scope creep

Strategic Before 16 After 6

The client brief names goals but not users, success measures or limits, so new features are added late without changed budgets or dates, and the design drifts away from the problem it was meant to solve.

Who or what is affected: Design team, project manager and client sponsor

Causes

Vague goals, verbal requests and a sponsor who adds ideas after sign off.

Consequences

Late redesign, overrun budget, a product that misses user needs and strained client trust.

Existing controls

  • A kickoff workshop records the goals and named users.
  • Stage sign off is required in writing from the sponsor.

Control gaps

Changes made in meetings are not recorded, so the cost of extra work is never shown.

Additional controls

  • Prevent: Write a one page brief with success measures, out of scope items and a change request form before design starts.
  • Detect: Log every new request against the backlog and review the total scope at each stage gate.
Likelihood 4 x impact 4 before; 2 x 3 after Owner: Lead product designer Target: Within 30 days Early warning: Two or more requests in a week that are not in the signed brief.
H02

Usability failures in core user journeys

Operational Before 12 After 6

Key tasks such as sign up, checkout or booking are confusing, slow or error prone because testing was thin, used the wrong users or ignored results, so people abandon the product or make costly mistakes.

Who or what is affected: End users, customer support staff and the client

Causes

Tight timelines, internal testers used in place of real users and results left in a slide deck.

Consequences

Lost conversions, support calls, user frustration and rework after launch.

Existing controls

  • Designers review flows against usability heuristics before each review.
  • A small round of user tests runs before visual design is locked.

Control gaps

Findings are not tracked to closure, so the same problems return in later versions.

Additional controls

  • Prevent: Recruit test participants who match the target user profile and write tasks before each session.
  • Respond: Rank test findings by severity and fix the top issues before the next stage gate.
Likelihood 4 x impact 3 before; 2 x 3 after Owner: Lead researcher Target: Within 45 days Early warning: Task completion below the agreed threshold in two consecutive test rounds.
H03

Accessibility barriers excluding users

Legal and compliance Before 12 After 8

Colour contrast, keyboard navigation, focus order, alternative text and form labels are not checked, so people using assistive technology or with low vision or motor limits cannot complete tasks, and the product may fail accessibility expectations.

Who or what is affected: Users with disabilities, the client and the design team

Causes

Accessibility treated as a final check, little training and reliance on visual review alone.

Consequences

Excluded users, complaints, possible legal challenge and rework near launch.

Existing controls

  • A colour contrast checker is used on the main palette.
  • Components in the library include labels for form fields.

Control gaps

No one is named to test with assistive technology, and results are not signed off.

Additional controls

  • Prevent: Add accessibility acceptance criteria to every component and screen before design approval.
  • Detect: Run a keyboard only and screen reader walkthrough of each main journey before release.
Likelihood 3 x impact 4 before; 2 x 4 after Owner: UI design lead Target: Within 30 days Early warning: Any screen that fails a keyboard or contrast check in a design review.
H04

Handoff and version control errors reaching production

Technology and data Before 12 After 4

Developers build from an outdated screen, a superseded component or an unapproved variant, because files are duplicated, names are unclear and approvals are not linked to the version that was released.

Who or what is affected: Developers, QA testers and end users

Causes

Copied files, unclear naming, late changes and no link between sign off and release.

Consequences

Visual and functional defects, rework, delayed release and a confusing record of decisions.

Existing controls

  • Design files are stored in a shared project with named pages.
  • Developers inspect specifications before writing code.

Control gaps

Approval happens in email rather than in the file, so the approved version is hard to prove.

Additional controls

  • Prevent: Use one master library with version numbers and lock approved components against silent edits.
  • Detect: Compare built screens with the approved version at each build and log any mismatch.
Likelihood 4 x impact 3 before; 2 x 2 after Owner: Design operations lead Target: Within 30 days Early warning: Two or more builds in a sprint that differ from the approved component version.
H05

Exposure of client data and confidential prototypes

Technology and data Before 20 After 8

Real customer records copied into prototypes, shared design links or screenshots posted to outside tools expose personal data and unreleased product plans to people who should not see them.

Who or what is affected: End users whose data is shown, the client and the design team

Causes

Convenience, realistic test content, unmanaged sharing and staff who leave with access.

Consequences

Privacy breach, breach of contract, loss of client trust and possible regulator notice.

Existing controls

  • Staging data is used for prototypes and access requires a named account.
  • Staff sign a confidentiality clause at the start of each client project.

Control gaps

Prototype data is not checked before it is shared outside the team.

Additional controls

  • Prevent: Replace real personal data with synthetic records and block public sharing links for client files.
  • Detect: Audit file share settings each month and review access lists for former team members.
  • Respond: Revoke links and report any exposure to the client within the agreed time.
Likelihood 4 x impact 5 before; 2 x 4 after Owner: Project manager Target: Within 14 days Early warning: A design file or prototype link shared outside the named client group.
H06

Unlicensed images, fonts and third party assets

Legal and compliance Before 9 After 4

Icons, photographs, fonts or code snippets are used without a licence that covers the product, commercial use or the client's territory, so the product may infringe rights owned by others.

Who or what is affected: Client, design team and rights holders

Causes

Quick searches for images, fonts copied from websites and unclear client rights.

Consequences

Takedown demands, licence fees, rework and damage to the studio's standing.

Existing controls

  • Stock assets are bought through a named account with a licence record.
  • The lead designer approves any external asset before use.

Control gaps

The register is not updated when assets are swapped late in a project.

Additional controls

  • Prevent: Keep an asset register that records source, licence type, permitted use and expiry for every asset.
  • Detect: Check the register against the final screens before each release and remove anything unlisted.
Likelihood 3 x impact 3 before; 2 x 2 after Owner: Lead product designer Target: Within 45 days Early warning: An asset in a screen that does not appear in the licence register.
H07

Schedule and budget overrun from optimistic plans

Financial Before 16 After 9

Stages are estimated without allowance for testing rounds, client review time or developer questions, so the work runs late and costs more than agreed, and corners are cut in research or accessibility checks.

Who or what is affected: Studio owners, client, design team and staff

Causes

Optimistic estimates, slow client feedback and work started before scope is clear.

Consequences

Budget overrun, unpaid work, staff overtime and cut quality in testing.

Existing controls

  • Each stage has a planned date and a named owner.
  • A weekly status note records progress against the plan.

Control gaps

Forecasts are based on the plan rather than on actual time spent.

Additional controls

  • Prevent: Add contingency time for review rounds and testing to every estimate and agree it with the client.
  • Respond: When a stage is forecast to slip by more than ten percent, re-plan scope with the sponsor before continuing.
Likelihood 4 x impact 4 before; 3 x 3 after Owner: Project manager Target: Within 30 days Early warning: Actual hours on a stage exceed the estimate by more than twenty percent.
H08

Dark patterns and culturally insensitive content

Reputational Before 10 After 8

Designs push users into unwanted choices, hide costs or use imagery, wording or colour that offends some cultures or groups, damaging trust and creating harm even where no rule is clearly broken.

Who or what is affected: End users, particularly vulnerable or cultural groups, and the client

Causes

Commercial pressure for conversions, narrow team backgrounds and no cultural review.

Consequences

Public criticism, user harm, complaints and loss of client and user trust.

Existing controls

  • Designers review copy and imagery in a team critique.
  • The brief lists groups the product is meant to serve.

Control gaps

No one outside the project team reviews the imagery or flows before release.

Additional controls

  • Prevent: Adopt a written ethics checklist covering consent, cost visibility, cancellation and cultural review.
  • Respond: Pause a flow for redesign when a user test or complaint shows a manipulative or offensive pattern.
Likelihood 2 x impact 5 before; 2 x 4 after Owner: Creative director Target: Within 60 days Early warning: A user complaint or test comment that describes a flow as misleading or offensive.

Rating method and evaluation

Each risk is rated on two five-point scales. Likelihood runs from 1, rare, to 5, almost certain, and impact runs from 1, minor, to 5, severe for users, the client or the studio. Multiplying the two gives a score from 1 to 25, which falls into one of four bands: Low from 1 to 4, Medium from 5 to 9, High from 10 to 16 and Critical from 17 to 25. The score guides the order of work and is not a precise measurement. Inherent risk is the score before any controls. Residual risk is the score after the existing and added controls are working. Impact considers harm to users, excluded people, lost money, legal exposure, time to correct and damage to trust. A risk is never rated down only because it has not happened yet. Critical and High risks need a dated plan and senior attention, Medium risks need routine controls and a named owner, and Low risks are accepted and watched. Designers, researchers and client representatives should challenge the ratings at each stage gate, and any rating is reviewed when its early warning indicator reaches the threshold.

Likelihood, impact and rating bands

Likelihood

  • 5 Almost certain: Expected to happen in most circumstances.
  • 4 Likely: Will probably happen in many circumstances.
  • 3 Possible: Could happen at some time.
  • 2 Unlikely: Not expected, but it could happen.
  • 1 Rare: Only in exceptional circumstances.

Impact

  • 1 Insignificant: No lasting effect. Handled within routine work.
  • 2 Minor: Small effect that is quickly corrected.
  • 3 Moderate: Noticeable effect that needs managed effort to correct.
  • 4 Major: Serious effect on people, delivery or reputation.
  • 5 Catastrophic: Severe or lasting effect that threatens the whole activity.

Bands (likelihood x impact)

  • Low (1 to 4): Accept and monitor.
  • Medium (5 to 9): Manage with routine controls.
  • High (10 to 16): Senior attention and a treatment plan.
  • Critical (17 to 25): Act first. Do not proceed until reduced.

Monitoring, escalation and review

Review this assessment every 3 months, and sooner when an indicator below reaches its threshold.

Early-warning indicators and escalation thresholds
Indicator to watchEscalate when
Requests added to scope that are not in the signed brief.Escalate to the lead product designer at once, and to the client sponsor in writing when two or more requests arise in a week.
Screens that fail a keyboard, screen reader or contrast check at review.Escalate to the UI design lead before the stage gate, and hold release if any core journey still fails.
Design files or prototype links shared outside the named client group.Escalate to the project manager immediately, revoke access within the hour and notify the client as the contract requires.
Built screens that differ from the approved component version.Escalate to the design operations lead when two or more mismatches occur in one sprint, and pause the build until corrected.
Actual hours on a stage that exceed the estimate by more than twenty percent.Escalate to the project manager for re-planning with the sponsor, and to the studio owner if the forecast overrun stays above the limit for two weeks.

Contingency arrangements

If a serious event occurs, such as a client data exposure, a failed accessibility review close to launch or a release built from the wrong version, the project manager pauses the release and informs the client sponsor in writing. The lead product designer confirms which version is live and restores the last approved state. Client data is revoked and the privacy contact is notified as the contract requires. A fix plan with a revised date is agreed, and affected users are told plainly what happened and what is being done.

Prioritized action plan

  1. Agree a written brief with success measures, out of scope items and a change request process, owner lead product designer, within 30 days.
  2. Replace real personal data in prototypes and block public share links for client files, owner project manager, within 14 days.
  3. Add accessibility acceptance criteria and a keyboard and screen reader check to each main journey, owner UI design lead, within 30 days.
  4. Lock approved components in a master library with version numbers and link sign off to each release, owner design operations lead, within 30 days.
  5. Schedule usability tests with users who match the target profile and track findings to closure, owner lead researcher, within 45 days.

Conclusion

Good product design depends on a few steady habits: a clear written brief, real user testing with action on the findings, accessibility checked during design rather than after it, locked versions of approved work, synthetic data in prototypes and honest estimates. The highest scores sit with data exposure, accessibility and usability, and each has actions that bring the residual score down. Treat the register as a living record, review it on the stated cycle, and seek qualified legal, accessibility or privacy advice for any real product decision.

Assumptions and limitations

Assumptions

  • The client is a single organization with a named sponsor who can approve scope changes in writing.
  • The team uses a common design tool, a component library and a ticketing board shared with developers.
  • Jurisdiction and accessibility obligations are not specified, so they are described in general terms only.

Limitations

  • The scores are examples for learning and do not describe any real product, client or team.
  • Accessibility, privacy and advertising rules differ by country and change over time, so specialist review is needed.
  • This is educational content and is not legal, accessibility audit or professional design certification advice.

Related frameworks to study

  • Nielsen usability heuristics
  • Hierarchy of controls
  • Three lines model of risk ownership
  • Accessibility guidelines such as WCAG as a general reference

Creative Risk Assessment

China, India, United States, Indonesia, Pakistan, Nigeria, Brazil, Bangladesh, Russia, Japan, Mexico, Philippines, Vietnam, Egypt, Turkey, Germany, United Kingdom, France, Italy, Canada, South Korea, Australia, Spain.

For Learning Reference Only: This assessment demonstrates how risk assessment principles are applied in a practical setting, providing a useful reference for learning and understanding. Actual assessments may be adapted to suit specific site conditions and circumstances.

Keep learning

Study the subject behind this assessment.

UI/UX and Digital Product Design course Read the best practices for this course

More Creative risk assessments

Hourly Active: 35,661 Learners