Keep the original need connected to work, release, and participant evaluation.
MenuClose
ACCESSIBILITY PRODUCT OPERATIONS · INDEPENDENT CONCEPT
High-fidelity prototype, not a shipped product.
Elevate
Turning accessibility feedback into accountable product work.
A B2B platform that keeps participant evidence connected to triage, delivery, release, and post-release evaluation.
MY CONTRIBUTIONResearch synthesis · system modeling · information architecture · user flows · interactive prototyping · usability-led iteration
ROLEProduct Designer
CONTEXTAccessibility product concept · research, systems, and testing
SCOPE9 interviews · 6 connected B2B surfaces · 3 usability participants · 4 task scenarios
IMPACT BOUNDARY Research and task-test results describe this prototype only. No production adoption or accessibility-conformance outcome is claimed.
01 · THE PROBLEM
Accessibility feedback often disappears between the report and the release.
The research pointed to three connected breakdowns: people could not see whether feedback became work, product teams lost context as reports moved into delivery, and shipping a fix was treated as closure without checking the lived result.
How might we keep the original barrier, accountable owner, and post-release evaluation visible in one continuous system?
Give leaders a legible view of progress without hiding the underlying evidence.
Support ongoing, consent-aware participation instead of extracting one-time feedback.
02 · KEY DECISIONS
Three decisions turn a feedback tool into an accountable operating model.
DECISION 01
Preserve the barrier after intake.
- Constraint
- Six of nine perspectives emphasized continued feedback, while a one-time report can lose lived context when it becomes delivery work.
- Considered
- A one-time report, a generic support ticket, and a linked history that follows the issue through release and evaluation.
- Choice
- I chose the linked history with a targeted follow-up survey.
- Tradeoff
- This preserves context and closure, but adds follow-up burden. Target prompts, allow opt-out, and avoid surveying every release.
- Evidence
- 6 of 9 perspectives emphasized continued feedback.
DECISION 02
Make progress legible without turning it into compliance theater.
- Constraint
- Leadership needs a fast signal, but a single accessibility score can hide the evidence and encourage score-chasing.
- Considered
- A binary pass or fail badge, a score without explanation, and a score paired with issue drill-down and a roadmap.
- Choice
- I chose the score, drill-down, and roadmap combination, with the score framed as a prioritization aid rather than conformance.
- Tradeoff
- A shared score aids prioritization, but can invite score-chasing. Keep source evidence visible and never present the number as conformance.
- Evidence
- Visible accessibility commitment was described as uncommon.
DECISION 03
Support longitudinal participation without overexposing people.
- Constraint
- Ongoing collaboration can improve continuity, but disclosure and repeated participation carry personal risk.
- Considered
- Anonymous one-time feedback, a closed ambassador cohort, and consent-aware ambassador relationships alongside open reporting.
- Choice
- I chose consent-aware ambassador controls while keeping an open reporting path.
- Tradeoff
- A longitudinal group builds continuity, but may overrepresent a small cohort. Preserve open reporting and scope access by consent.
- Evidence
- Disclosure and participation carry personal risk.
03 · FINAL PRODUCT
Orient, act, and prove—without losing the participant’s evidence.
Understand where attention is needed.
Ticket activity, evidence-backed score changes, and roadmap goals share one overview.
Turn feedback into owned delivery work.
Related tickets move into tasks and sprints without dropping the original participant context.
Evaluate a release instead of assuming success.
A targeted survey returns the released change to relevant participants and can reopen the issue.
04 · TESTING
Four tasks exposed where the system needed clearer state and navigation.
Three participants completed a high-fidelity prototype across four task scenarios. The table reports observed passes and issues—not a satisfaction score.
Find what caused the October score drop.
- IssueOverview unclear
- IssueExpected an interactive graph
- ObservedCompleted
Next iterationMake the score-change overview and graph relationship explicit.
Turn color-contrast tickets into assigned work.
- IssueSelected tickets were hidden
- IssuePre-selection was unclear
- IssueCTA wording needed work
Next iterationKeep selected tickets visible and clarify pre-selection before task creation.
Check progress and leave a comment.
- ObservedCompleted
- ObservedCompleted
- IssueTask location was unclear
Next iterationSurface the destination of an assigned task after creation.
Reply to the haptic-feedback ticket.
- ObservedCompleted
- ObservedCompleted
- ObservedCompleted
Next iterationPreserve the successful reply flow while improving surrounding navigation.
05 · RESULTS + REFLECTION
The prototype makes accountability inspectable; the next step is to validate it with more representative use.
Four professionals and five disabled participants informed the product model.
Testing prioritized hierarchy, selection state, and ticket-to-task navigation.
Test keyboard and screen-reader flows, recruitment bias, participant withdrawal, and whether follow-up burden is acceptable.
PROCESS APPENDIXResearch limits, methods, and accessibility verification plan
Methods and limits
Interviews · synthesis · flows · prototypes · testing. The interview sample is small and directional, the prototype test included three participants, and no shipped product data is available.
Keyboard + focus
Visible-focus intent and large targets are specified in the interface system.
VERIFYComplete every core flow by keyboard; verify order, focus return, and no traps.
Screen reader
Plain-language labels and predictable hierarchy are part of the design intent.
VERIFYTest names, roles, announcements, error associations, and dynamic updates.
Zoom + reflow
Desktop, tablet, and phone layouts are designed as separate responsive states.
VERIFYVerify 200–400% reflow, text spacing, orientation, and target visibility.
Data + status
Status is designed with labels and shape, not color alone.
VERIFYProvide chart text alternatives, table semantics, and contrast checks.
Motion + participation
Reduced motion, consent, fatigue, and withdrawal are documented requirements.
VERIFYTest preferences and participation controls with disabled participants.