Make informed decisions before development
Early design decisions influence how people navigate, understand and interact with a service. We review proposed journeys and components so your team can address barriers while the design is still taking shape.
The review can cover website and app prototypes, interaction patterns or a shared design system. We agree the relevant screens and states with your team, including forms, errors and content that changes after an action.
Standards translated into design decisions
We connect WCAG requirements to journeys, components and interaction states. For UAE services, this includes the applicable national accessibility requirements and implementation of the UAE Design System.
WAI-ARIA informs developer guidance for accessible controls. Software accessibility requirements from ISO 9241-171 can be included where relevant. Your team receives recommendations linked to the design, with clear checks for the implemented product.
Look beyond the default screen
Journeys and navigation
Review the sequence of tasks, the structure of information and how people find their way through a service, including paths that cross several screens.
Controls and states
Consider labels, instructions, errors, loading states and confirmation messages. These details help people understand what an interface expects and what has happened.
Visual communication
Assess how contrast, typography, spacing and the use of colour support understanding. Consider how the design adapts when content grows or the viewport changes.
Interaction requirements
Document expected keyboard behaviour, focus movement and information for assistive technology, so developers have guidance beyond the visible layout.
Guidance for the next stage
Design findings
Clear feedback on barriers in layout, content, controls and interaction, with recommendations linked to the proposed design.
Implementation guidance
Accessibility requirements for developers, including component behaviour and information that visual designs alone may not communicate.
Continue into delivery
We work with your designers to explain findings and review relevant changes. This helps teams apply accessibility consistently across repeated patterns.
A design review addresses what can be evaluated before implementation. Testing the working product remains important: code, keyboard behaviour and assistive technology support need evaluation in the delivered service.
Make the review useful to your team
Share the design files, key journeys and any existing component guidance. We discuss the design stage and the decisions that can still change, then focus the review on recommendations your team can use in its next iteration.
For a bilingual service, both language versions belong in that conversation. We can review how the same interaction is expressed in Arabic and English, including mixed-language content and mirrored layouts.
Before a design review
When should a review take place?
When a journey or component is developed enough to explain its behaviour, while the team still has room to respond to findings. A review can support early prototypes or an established design system.
Can the review support developer handover?
Yes. We can include interaction requirements and accessibility annotations within the agreed outputs. A subsequent audit of the implemented service checks how those decisions work in practice.
Bring accessibility into your next design review
Tell us about the journeys, prototypes or design system your team is developing.
Discuss a design review