Navigate through each of the actors to see a description for
each user need related to your portal, in order to help the user successfully achieving their goal Help users to understand that they can retrieve documents online via OOTS.
This can be implemented in multiple user journey steps such as discovery, locate and request evidence. Display a short explanation about OOTS in a snippet
Are the documents you need to provide issued by a public authority in another EU Member State?
Then we may be able to retrieve them directly from public authorities in other EU Member States. To access this feature, you will need to login with your government issued digital identity. Learn more
Provide a link to OO Hub so users who want to understand how
the OOTS works or the legal basis for evidence exchange can learn more. Do Ensure both options are prominently displayed so users do not overlook them or make an incorrect selection. Don't Don't hide the European authentication option behind the national scheme. Do National authentication option European authentication option Don't European authentication option Users can only retrieve evidence through the OOTS if they authenticate with electronic identification means that have been issued under an electronic identification scheme that has been notified in accordance with Regulation (EU) 910/2014. If your service allows users to authenticate in other ways, email/password for example, ensure users know that they won’t be able to retrieve evidence online if they choose those options. Make the YourEurope logo a link to the European Commission's Your Europe website. When selecting a country for authentication with a European digital ID, it is recommended to present the list of countries in a searchable format. This will allow users to quickly find and select their country from a comprehensive list. Additionally, for countries where the European digital ID system is not yet available, it is important to clearly state that, ensuring users are aware of the current limitations and reducing potential confusion. Do Country display Selecting country For more information on errors, check the Error guidelines Don't During the cross-border authentication step, include a link to a page where users can learn more about cross-border authentication based on eIDAS. The link can direct users to the relevant page hosted by their Member State or to the one provided by the European Commission. Do During the authentication phase, there are two separate consents for sharing attributes: The first consent occurs when the National Authentication Means (NAM)* requests the user's consent to share the attributes with the National Authentication Service (NAS). The second consent occurs when the National Authentication Service (NAS) requests permission to share the received attributes from the National Authentication Means (NAM)* with the Procedure Portal. It is essential to clearly communicate which attributes are being requested, who is requesting and who will receive these attributes, to ensure transparency and build user trust. *National Authentication Service (NAS) refers to a government-provided service that enables secure, centralised authentication for citizens, residents, or businesses when accessing public and private sector digital services. *National Authentication Means (NAM) refers to a government-recognised tools, methods, or mechanisms used to verify user's identity during the authentication process. Do Example: Don't Help users to understand that they can retrieve documents online via OOTS. This can be implemented in multiple user journey steps such as discovery, locate and request evidence. Display a short explanation about OOTS in a snippet
Are the documents you need to provide issued by a public authority in another EU Member State?
Then we may be able to retrieve them directly from public authorities in other EU Member States. To access this feature, you will need to login with your government issued digital identity. Learn more
Provide a link to OO Hub so users who want to understand how
the OOTS works or the legal basis for evidence exchange can learn more. In case the procedure requires the user to supply the evidence in specific languages, tell users what language the evidence must be in. Although the OOTS does not translate evidences, it is important that the Procedure Portal clearly states which languages are accepted to avoid users from submitting documents in the wrong language. If users initially sign in with their email or any digital identity method that does not support cross-border authentication, offer them the option to re-authenticate using eID login options supported for cross-border authentication once they've chosen to retrieve documents via the OOTS. Do Display a modal with the accepted authentication methods that allow users to retrieve evidence via the OOTS. Don't Display the "Sign-in with email" option as it doesn't allow users to retrieve documents online. Users need clear signals about how to initiate the cross-border evidence retrieval process in their digital journey. The button that starts this process serves as a critical entry point and must effectively communicate what will happen next. Clear labeling builds user confidence in the system and reduces hesitation when transitioning between national platforms. For English interfaces, we recommend using the label "Retrieve online" for the button that initiates the evidence retrieval process. This label effectively communicates the action to users while maintaining appropriate expectations. When implementing the OOTS button in languages other than English: Focus on concept rather than literal translation. The goal is to convey "accessing existing official documents through an online system," not to translate "Retrieve online" word-for-word. Maintain key elements that made the English label successful, following the do's and don't below. Test with native speakers to ensure the local language version: Creates appropriate expectations about where users will be directed Clearly indicates they'll be retrieving official documents online Feels natural and intuitive in the target language Consider cultural context in how government services are typically described in each country, using familiar terminology while maintaining consistent meaning across implementations. Do Use active verbs indicating acquisition of existing documents (e.g., "retrieve"). Include the digital nature of the process ("online"). Keep labels concise (2-3 words) and action-oriented. Don't Use ambiguous navigation terms ("continue," "next") lacking specific meaning. Refer to technical terminology unfamiliar to citizens. Use labels suggesting document creation rather than retrieval. Users will arrive on your intermediary platform after having been re-directed from the Procedure Portal website. Make sure you tell them what they can do on this new website. Retrieve official evidence about you or your company, directly from public authorities across the EU. When users move from the Procedure Portal to the intermediary platform display enough
information so they users understands they are in the right place. Display a summary of the evidence request so users have a recognisable elements across multiple
website, including: the name of the applicant, the procedure, and the name of the requested evidence. Provide support throughout the entire procedure to ensure users receive guidance and help at every step, addressing any issues they might encounter. Do The Intermediary Platform manages connections between evidence requesters and evidence providers across different countries. At this stage, errors can occur during request verification, provider connection, or evidence retrieval processes. Clear error communication is crucial, as users need to understand whether they should retry their request, verify their information, or proceed with manual upload. User-Actionable Errors: Errors caused by incorrect or incomplete user inputs that can be resolved by the user. Examples: Invalid or incomplete evidence request User can verify and resubmit information for the request Incorrect provider selection User can verify and select the correct provider or country for the request System Errors (Alternative Paths Available): Errors caused by system limitations with available workarounds. Examples: Evidence not available to retrieve via the OOTS in selected country User must use manual upload Evidence provider not found User can try different provider or manual upload Provider not supporting online retrieval via the OOTS User can proceed with manual upload System Errors (No Immediate Alternative): Errors caused by system failures or service unavailability with no immediate resolution. Examples: Gateway connection problems General technical issues Provider service unavailability User must wait for system recovery Please note that errors other than those mentioned here can occur depending on each country's flow. For global error handling principles, refer to the Error messages (Global) guidelines.
Prevent errors proactively: Don't Handle errors with clear paths forward: User-Actionable Errors Document details verification error: "We couldn’t verify the details in your [document name]. Please review and update your information in [procedure portal link] or upload the document manually..." System Errors (Alternative Paths Available): Evidence type not available to retrieve online via the OOTS: "Digital retrieval of [document name or type] is not supported in [country name]. You can continue by uploading your document manually through the procedure portal." System Errors (No Immediate Alternative): Technical failure: "We couldn't send your evidence request due to a technical issue on our end. Please try again [resolution time] or upload the evidence manually." When users need to retrieve cross-border evidence through OOTS, they encounter a critical moment in their journey: identifying the correct provider for their evidence. This typically happens after they've initiated a procedure on their national portal and have been directed to the Intermediary Platform to select their evidence. At this stage, users need to select from available evidence providers to pinpoint where their specific documents are held. While the new MS-specific classification system provides a more user-friendly foundation by presenting only relevant providers in familiar categories, users still face important challenges: Behind the scenes, these selections map to member state-defined classifications that present providers in meaningful categories, but users should never need to interact with technical systems directly. Clear provider selection with specific, contextual guidance is essential, as confusion at this step can lead to evidence retrieval failures and procedure abandonment. The system must guide users to the correct provider while providing clear context about which specific situation or time period is relevant for the evidence being requested. The TDD team recommends implementing the MS-specific classification approach for improved user experience, but recognizes that implementations may still utilize the hierarchical administrative system. Both approaches should prioritize clear guidance to help users locate the correct evidence provider. Do Provide specific, contextual guidance about which provider to select as it appears in the Common Services (e.g., "Select the university where you completed your bachelor's degree"). Implement filterable dropdown menus that allow both browsing available options and searching by typing. Show only providers that actually exist and can provide the requested evidence type. Include additional context when provider names might be ambiguous (e.g., multiple campuses, recent mergers, abbreviated vs. full names). Don't Use vague or generic selection prompts that don't specify the relevant context or which documents should be retrieved from where. Force users to guess which provider is correct when multiple similar options exist. Present providers without adequate filtering options when lists are long. The hierarchical jurisdiction system (Country → Region → Municipality) is deprecated but may still be encountered in some implementations. Use these guidelines only for edge cases where the MS-specific classification system is unavailable. For hierarchical navigation: Start with the broadest level necessary (country first, then region/municipality only if needed) Provide clear context about which life event location is relevant Only request the minimum level of detail needed to find evidence Skip levels that don't contain relevant providers Avoid: Forcing users through all hierarchical levels when unnecessary Presenting administrative boundaries without context Showing levels with no available providers There are no recommendations available yet. Using the OOTS is a cross-border experience where multiple website are involved. If you rely on other websites to be consistent with the steps you show the user, you risk confusing the user if they are not applied in the same way. On each step of the evidence retrieval process, use a short, actionable title so users are clear what they need to do. This will lead to a quicker decision-making. Do Don't Clutter the screen with any unnecessary information to reduce users' cognitive load and allow them to concentrate on the step they are taking. Display steps, as they might not match the steps from the procedure and confuse users. When transitioning between platforms, users may feel disoriented. To prevent this, clearly notify users in advance when a redirection will occur, so they know what to expect. If it is technically feasible to send evidence directly from the Preview Space to the Procedure Portal without having to go through the Intermediary Platform: Do If you have to pass by the Intermediary Platform, due to technical reasons, redirect the user from the Preview Space to the Intermediary platform and display only a message informing the user that the document is being sent. Do Don't In the event that the evidence is not available in the language
requested by the evidence requester, and you can detect the mismatch, then: Warn the user before displaying the evidence on the preview space On the page of the preview In the event that the evidence is available in the language
requested by the evidence requester, and you can detect it, then: On the page of the preview In the event that you cannot detect the accepted
language from the Procedure Portal, then: On the page of the preview The Preview Space is where users review their requested evidence before proceeding. When users preview their documents before submission, things can go wrong - like sessions timing out or connection issues with evidence providers. Since users are so close to completing their procedure at this point, they need to know exactly what to do next: try again, go back, or switch to manual upload. User-Actionable Errors: Errors caused by the authentication expiring Examples: Session expiration during preview User can refresh and restart preview session System Errors (Alternative Paths Available): Errors caused during the authentication process Examples: Authentication issues User can re-authenticate and try again System Errors (No Immediate Alternative): Errors caused by system failures or service unavailability with no immediate resolution. Examples: Preview generation failed Connection lost with evidence provider Data transfer interrupted User must wait for system recovery Please note that errors other than those mentioned here can occur depending on each country's flow. For global error handling principles, refer to the Error messages (Global OOTS-Wide) guidelines. Do Don't User-Actionable Errors Session expiration during preview: "Your preview session has expired. You can refresh the page to start previewing again, or return to the procedure portal to continue with manual upload." System Errors (Alternative Paths Available): Evidence provider unavailable: "The evidence provider's service isn't responding right now. You can upload your evidence manually now, or try the preview again when services are operational." Evidence exists but can't be retrieved digitally: "This evidence exists but can't be retrieved electronically at the moment. You can proceed with manual upload or try again when services are operational..." System Errors (No Immediate Alternative) i.e Gateway connection problems: "We couldn't send your evidence request due to a technical issue on our end. Please try again tomorrow or upload the evidence manually." There are no recommendations available yet. There are no recommendations available yet. OOTS (Once-Only Technical System) connects different government platforms across the EU, allowing users to request and share official documents across countries. This complex system can encounter various issues, from technical problems connecting different national systems to variations in document availability between countries and differences in how countries handle certain documents. When users encounter these issues, clear communication is crucial because they are often dealing with important official procedures, and the cross-border nature can make problems more confusing. Users need to understand whether they should wait, try again, or use alternative methods. These guidelines ensure users understand what went wrong, know if they can fix it themselves, can find alternative ways to proceed, and maintain confidence in the system despite encountering errors. For platform specific recommendations, take a look at: Understanding different error types helps determine appropriate messaging and user guidance. Here are some examples: User-Fixable Issues: Errors that users can resolve by taking specific actions Input errors Missing or incorrect information Document upload issues Selection errors Wrong country or provider chosen Authentication issues Expired sessions Invalid credentials Missing permissions System Errors with Alternatives: Technical limitations where alternative paths are available Service limitations Digital retrieval not supported Provider capabilities restricted Regional availability constraints Document availability issues Documents not available digitally Temporary provider outages Format compatibility problems System Errors without Alternatives: Technical problems requiring system recovery, where the user can't do anything but manually complete their procedure Technical failures Gateway errors Service interruptions Data processing issues Connection problems Network timeouts Provider connectivity failures System maintenance periods While some errors may appear in multiple categories depending on the specific platform or country, this classification helps determine appropriate user guidance and resolution paths. These principles ensure error messages are helpful, clear, and guide users toward solutions. Write Clear Messages: Error messages should be immediately understandable and actionable for all users. Make errors visually distinct from other UI elements Use consistent styling, and reserve these patterns for only errors to maintain their significance Position messages prominently in the user interface Follow accessibility standards Ensure sufficient color contrast Include screen reader support Provide text alternatives for error icons Guide Users Forward: Every error should have a clear path to resolution or next steps. Show clear next steps Provide alternatives when available (e.g., retrying, manual upload) Preserve user progress whenever possible Set clear expectations for resolution Be specific about waiting times when known Explain what happens next in the process Avoid These Common Mistakes: These practices can confuse users and reduce trust in the system. Using vague messages like "An error occurred" or "Something went wrong" Hiding or minimizing critical errors that need user attention Blaming users for system errors Making promises about resolution times you can't guarantee Using inconsistent styling for different types of errors Placing error messages where they might be missed While some errors may appear in multiple categories depending on the specific platform or country, this classification helps determine appropriate user guidance and resolution paths. OOTS connects different government platforms across the EU for sharing official documents. Users navigate through multiple platforms during their evidence retrieval journey, from initial request to final submission. Clear, consistent titles and guidance help users understand their current task and maintain context when switching between platforms. These guidelines ensure consistent language patterns and clearly communicate required actions across all OOTS platforms. Do Lead with clear actions that show users what to do next. When users move between platforms, they need to quickly understand what's expected of them. Action verbs like "Select," "Review," or "Confirm" immediately tell users what they need to do. For example: Keep terminology consistent across all platforms. For example: Digital identity should be called a "digital identity" everywhere - not "eID" on one platform and "digital ID" on another. This consistency helps users throughout the whole process. Connect titles to the user's current task and overall procedure. When asking users to select evidence, remind them what it's for, e.g. "Select the country where you completed your bachelor's degree". Ensure page title matches the main call to action The page title should clearly reflect the primary call to action (CTA) to set the right expectations and guide users effectively toward their goal. For example: Aim to only have one header title present on the page. Multiple headers can confuse users about the main purpose of the page or which action they should focus on. Keep supporting information in subheadings or help text rather than competing headers.
Depending on context, this might not be possible. In those cases, pay extra attention to the information hierarchy on the page to properly guide the user. Provide context when users reach a new platform. Give precise and actionable instructions to describe each task the user needs to complete when multiple tasks are required on the same platform. Don't Use technical language that might confuse users. They don't need to know about OOTS payloads or evidence providers. For example: Write passive titles that leave the user guessing what to do next. Users should immediately know what they need to do: Use vague or non-instructive text like "Enter details" or "Continue here." Display steps/progress bars that rely on other platforms, as they might not match the steps from the procedure portal or other MS platforms, creating a confusing experience. Clutter the screen, with unnecessary information that increases users' cognitive load or leaves them guessing about required actions. When handling evidence across borders, language requirements can vary widely. Evidence Requesters might accept single, multiple languages, or any language whatsoever, while Evidence Providers might offer documents in different languages. Users need clear guidance throughout their journey regardless of the scenario they encounter. No Language Requirements For some evidence, language doesn't play a significant role. This includes: Specific Language(s) Requirements Some evidence must be provided in specific languages. In these cases: Single language (e.g., only German accepted); A single link to the preview space will be displayed with the accepted language. Multiple languages (e.g., German or English accepted): The recommended approach is to send separate requests for each language accepted by the requester. List all available evidences in the accepted languages. Each evidence link must clearly indicate the language it represents. Users will select their preferred language from these clearly labeled links and be redirected to preview the evidence in the selected language. In these cases, providers only return evidence links for the specified languages, ensuring users can share their evidence directly. Required language not available If the provider doesn't have evidence in any required language: When the evidence language requirements of the requester are known, the following process applies: The OOTS system currently has some limitations regarding language handling: To bridge this gap between technical limitations and user needs, our recommendations focus on: This approach ensures: (whether requirements state single or multiple languages) Do Present each language version with: Do When required language isn't available, automatically search for other language versions If other language versions are found: If an automatic search is not possible: Don't In scenarios where a user wants to verify the content of an evidence before it gets shared, they might want to do so in a language they're more comfortable with, like their mother language. To accommodate this, the Preview Space should still offer the option of preview any available, official version of the retrieved evidence, regardless of language version the user is sharing with the Requester. Do Don't Do When there are multiple official language version available of an evidence: To accommodate users with different primary or secondary languages, machine-translated options should be made available when previewing documents: Don't When evidence is uploaded or shared through the Procedure Portal, the system must verify if it meets language requirements. This verification step helps avoid situations where users progress through multiple steps only to be rejected later for language non-compliance, creating a more efficient and user-friendly process. Approaches The Evidence Requester should implement a verification process using one or more of these methods: Document Metadata Verification When evidence includes language metadata or labels, the system should check these automatically against requirements. This provides the most reliable verification when metadata is available. Automated Language Detection For documents without clear metadata, automated language detection tools can be used to determine the document's language. This approach works best with text-based documents that contain sufficient content for analysis. User Confirmation Fallback If automated verification isn't possible, the system should: Notify users that language couldn't be automatically verified Prompt them to confirm their document meets requirements Provide clear information about accepted languages Explain potential consequences of submitting in non-accepted languages In these cases, providers only return evidence links for the specified languages, ensuring users can share their evidence directly. Implementation Guidance The verification process should: Users may need to exit procedures at different stages or platforms- whether they realize they've entered some wrong data, encounter technical difficulties, or simply change their mind about proceeding with OOTS for an evidence. When users choose to cancel, they need clear information about what this means for their progress and data as they make a graceful exit from the procedure. The impact varies depending on where users are in their journey. Cancelling from the procedure portal abandons the entire procedure, while cancelling from evidence selection or preview returns users to the intermediary platform where to can pick a different version on the evidence if possible. Clear cancellation flows build user confidence by ensuring they maintain control over their process. Users should understand what gets saved, what gets deleted, and whether they'll need to re-authenticate if they return. Cancellation options should be clearly available at each stage of the user journey, with appropriate messaging about consequences. The type of cancellation and its impact depends on where the user is in the process. This guidelines focuses on the one-by-one pattern of evidence retrieval, some points might not directly apply to other patterns. Do Always show confirmation modals before cancelling. Make cancellation options clearly visible at each stage. Explain consequences in plain language. Include authentication state warnings when relevant. Specify exact turn destinations. Don't Allow cancellation without warning about consequences. Hide or obscure cancellation options. Use vague or technical language about what happens next. Force completion without exit options. Consistent terminology is critical for user comprehension and trust, particularly during cross-border procedures. Creating a cohesive user experience requires not only choosing the right terms but also ensuring they work effectively alongside clear CTAs, informative headers, and trust indicators. While the Single Digital Gateway Regulation (SDGR) and technical documentation (TDD) officially use the term "evidence," our research demonstrates that users rarely use or naturally understand this term in the context of administrative procedures. Users connect more intuitively with the concept of "proof" when referring to information needed to verify eligibility or complete administrative processes. This creates an important distinction between internal/regulatory terminology ("evidence") and user-facing language. "Proof" is the recommended terminology for describing the information exchanged through OOTS in user interfaces. This phrasing clearly communicates the purpose of the information exchange and focuses users on the verification aspect rather than technical details of the exchange. The term effectively encompasses both document-based and data-based exchanges in a user-friendly way. While the regulatory framework will continue to use "evidence" in formal documentation, user-facing interfaces should prioritize clarity and user comprehension by adopting the recommended terminology. Ultimately, each Member State should decide on the correct term in their own languages internally, balancing regulatory alignment with user understanding. As OOTS develops, these guidelines should be periodically reviewed to ensure terminology remains aligned with user expectations and system capabilities. Member states should conduct localized research to determine the most effective terminology in their own languages, following a methodology similar to our approach: Initial benchmarking - Survey existing local and non-local government services and portals to identify currently used terminology for similar concepts. Exploratory research - Conduct user interviews showing examples of official documents and data that would be exchanged through OOTS, asking open-ended questions to identify emergent terminology. Terminology refinement - Test individual terms for clarity and mental model fit with representative users. Context-based validation - Test top candidate terms within complete user flows to evaluate effectiveness in context. Consistent implementation of terminology across platforms, member states, and user touchpoints is essential for creating a cohesive user experience. The following guidance provides specific recommendations for applying the selected terminology in various contexts. The below recommendation is specifically for English interfaces, please refer to the above section for other local languages. The following copy examples demonstrate how to implement the "proof" terminology effectively across different user interface contexts. These examples prioritize clarity, user confidence, and consistent terminology while addressing common user concerns about cross-border information exchange. Primary actions and CTAs Retrieval actions: Selection and consent: Process descriptions: Contextual explanations What is proof messaging: Trust and security messaging: Progressive context examples Initial introduction: Selection screen: Confirmation: To retrieve documents through the OOTS, users will need to navigate through different websites including the procedure portal, authentication platforms, intermediary platform and preview space. These websites are often provided by different Member States, each with their own visual style, language preferences, and interaction patterns. Users need to be confident that each of these websites, regardless of which Member State provides them, is operated by an organisation or entity they can trust with their data. This cross-border journey creates potential confusion, as users may question whether they're still in the correct process flow when transitioning between platforms from different countries. Research has shown that certain visual elements significantly impact users' perception of trustworthiness when navigating government digital services. Government logos consistently rank as the most crucial element for establishing trust, followed by the YourEurope logo which serves as an important secondary trust indicator. When implementing OOTS platforms, visual trust elements should be prioritized in this order: Research findings indicate that naming approaches impact user trust and understanding in specific ways: Across all platforms in the user journey, maintain consistent terminology for key actions and elements. Terms like "requester", "proof", and "preview" should remain unchanged to reinforce continuity. Different implementation approaches are recommended based on each member state's existing digital infrastructure: In all cases, prioritize familiarity over introducing new branding elements. OOTS should be presented as an extension of existing digital government services rather than as a separate entity. The following is a summary of key implementation guidance for member states with recognized government branding systems: Do Don't Do Don't OOTS is a system for cross-border procedures and users will move between different platforms in different countries. Thus, it is important that the language remains consistent throughout the entire process based on the preferred language of the user. Language preferences should persist throughout the entire journey. When a user sets their preferred language on one platform, this choice should carry over when they are redirected to another platform in the system. Without this consistency, users face unnecessary confusion and barriers, particularly when navigating unfamiliar government procedures. When implementing language consistency across OOTS platforms, various scenarios may arise where the preferred language cannot be determined or supported. This section outlines how to handle these situations gracefully. When a user's language preference cannot be determined (no browser settings, no cookies, no session data), platforms should:
Default to English as the primary fallback language. English serves as the most widely understood language across the European Union for cross-border users.
Prominently display the language selector to encourage users to choose their preferred language. Position this selector consistently across all platforms, typically in the header area.
Store any manual language selection immediately in both cookies and session data to maintain consistency in future interactions
When a user's preferred language is not available on a particular platform:
Display a notification message in both the requested language (if possible through tooling) and English, explaining that the requested language is not available.
Automatically switch to the fallback language rather than making an assumption about which alternative language might be preferred.
Present the language selector with available options clearly indicated, allowing users to make a choice about their display language.
Preserve the original language preference in cookies/session data even when using a fallback language. This ensures that if the user returns to a platform that does support their preferred language, their original preference is honored.
When a user manually changes their language preference: Apply the change immediately without requiring page refreshes when possible, using client-side language switching. Update all stored preferences (cookies and session data) to ensure consistency. Ensure that all dynamic content (not just static interface elements) is properly translated when language is switched. Maintain the user's position and context within the application workflow after the language change. Users should not be returned to the homepage or need to restart their process. By using these error handling strategies, OOTS platforms can maintain a consistent user experience even when language preferences cannot be perfectly preserved or communicated, minimizing user confusion and frustration. The language selection process follows several critical decision points:
Preference Persistence Check: When a user accesses any OOTS platform, the system first checks for existing language preferences in cookies or session data. This recognizes returning users and maintains their previously selected preferences, creating a consistent experience across sessions.
Browser Language Detection: Only for new users or when no stored preferences exist does the system fall back to detecting browser language settings. This provides a reasonable starting point for first-time visitors without overriding explicit choices made by returning users.
Fallback Mechanism: If neither stored preferences nor browser settings yield a usable language preference, English serves as the consistent fallback language across all platforms.
Cross-Platform Transitions: When a user moves from one platform to another, their language preference travels with them primarily through stored cookies. The receiving platform follows the same order of operations: checking stored preferences before falling back to detection methods.
User Control: Throughout the process, users retain the ability to manually select their preferred language. These manual selections take precedence over automatically detected preferences, are immediately stored in session data and cookies, and are preserved across platform transitions.
The Technical Design Document (TDD) currently does not include provisions for language parameters in cross-platform redirects, but this feature is under investigation to enable more seamless language consistency across the OOTS flow. Until this feature is implemented, platforms should rely on browser settings and cookies for maintaining language consistency. ISO 639-1 two-letter codes for primary languages (e.g., "en" for English) ISO 639-2 three-letter codes for languages without two-letter codes BCP 47 format for regional variants (e.g., "en-GB" for British English) HTTP Accept-Language headers / browser settings Cookies or session data Clearly inform users that their preferred language is not supported Automatically select an official language of the Union that is broadly understood by the largest possible number of cross-border users Provide a prominent way to select from available languages When cross-border evidence requires processing time or isn't immediately accessible, users need clear information about what to expect and how to proceed. A delayed response can happen for various reasons - whether due to provider-side verification or administrative workflows, or simply when evidence retrieval requires more time than the initial request window allows. Systems must communicate these processing delays transparently and provide mechanisms for users to continue their procedure later without losing progress. The goal is to ensure users understand this is expected behavior, can track progress through status updates, and can resume the procedure smoothly when evidence becomes available. Providing clear expectations about the nature of delays builds trust in the system, even when immediate delivery isn't possible. This type of delay resolves automatically once processing is complete, making it distinct from errors that require user intervention or technical fixes. The delayed response is a specific case of an error message. Find the error message recommendation page here: https://ec.europa.eu/digital-building-blocks/wikis/x/rIk1LQ(opens in a new tab). When users request evidence through OOTS, delays may occur during retrieval for different reasons. The system must handle these delays transparently across multiple platforms while maintaining user trust and providing clear pathways forward. Technical delays occur due to system connectivity issues, server errors, or temporary outages. These are technical problems that the system attempts to resolve automatically through retry mechanisms. Evidence unavailable scenarios occur when evidence definitely exists but requires additional processing by the issuing authority before it can be retrieved. This is a normal part of some evidence workflows where authorities need time to prepare or verify documents. The system must distinguish between technical delays and evidence unavailable scenarios based on provider responses, as these require different user experiences and resolution paths. Technical delays occur when systems encounter connectivity issues, server errors, or temporary outages. The system should attempt automatic recovery before escalating to user communication: Normal search indicator - Standard loading animation during active retrieval. Extended processing with retry - System continues attempting retrieval for up to 2 minutes with message: "We're having some difficulties locating your proof. Please hold on as we continue trying..." As this message gets displayed, be sure to offer the user a way to cancel their request, or skip the automatic recovery. Technical error confirmed - After retry timeout or specific error response, follow error message recommendations for system failures. Evidence unavailable scenarios occur when the provider confirms evidence exists but requires additional processing. This happens in the preview space after user authentication: Provider confirms evidence unavailable - System receives specific status indicating evidence exists but needs processing. User choice presentation - User is presented with decision about requesting evidence. Request confirmation - If user chooses to request evidence, system initiates processing request with authority. When evidence requires additional processing by the provider(described in the TDD as 'evidence unavailable'), users have to explicitly choose to request the evidence. While we assume users want to request this evidence, consider they may instead prefer to skip unavailable evidence if they have alternative documents, are facing tight deadlines, or want to complete their procedure without additional waiting time. Therefore, users must be given clear information about what this means and explicit choice about proceeding. Information hierarchy and decision flow Present information in the order users need to make an informed decision. Users should understand what they're deciding about before being asked to choose. Consider this progression: Help users understand the situation and why additional processing is needed. Show users what specific proof requires processing and who is responsible. Provide clear timeline expectations for the processing. Present the choice with transparent consequences for each option. This approach respects how users naturally process information and reduces decision-making anxiety. User choice interface Present users with a clear decision that emphasizes their control over the process. Frame the choice to reduce anxiety about delays and clarify that both options are valid paths forward. Explain the consequences of each choice without creating false urgency. Users should understand they can continue their application regardless of their decision, and that declining doesn't prevent them from providing the proof through other means.
Present users with a clear decision point that emphasizes user agency:
Follow with explanation that sets expectations and guides the user:
Timeline communication Always provide timeline estimates for evidence unavailable scenarios: Display timeframe prominently in a dedicated section: "Estimated time needed: Up to X working days". Use specific ranges: "2-3 business days" rather than "soon". Include icon or visual cue to emphasize temporal nature. Contact information collection After users choose to request unavailable evidence, they need a way to be notified when it becomes available. Since the procedure portal cannot provide real-time updates about evidence readiness, contact information enables direct notification from the evidence provider. This step occurs immediately after the user confirms their evidence request. Present it as a natural continuation of their choice rather than a separate task: Confirmation of request - Acknowledge what just happened: "We'll prepare your proof". Processing details - Reinforce what they requested and timeline expectations. Notification purpose - Explain why contact details help them. Structure the contact collection as part of the confirmation flow: Confirmation section Positive status indicator: "Request confirmed". Clear confirmation: "Your request has been sent to the issuing authority. You can continue your application while we work on this." Proof details summary with timeline: "Bachelor's degree diploma from [Authority] - Expected within 5 business days". Contact collection section Frame contact collection with clear purpose and benefit:
Frame contact collection with clear purpose and benefit:
Field requirements and layout Design contact collection based on your system's capabilities and requirements. Consider these approaches: Primary contact method: Choose your most reliable notification channel (often email). Secondary options: Provide alternative contact methods where supported (SMS, phone calls). User choice and transparency Always provide users with clear alternatives and honest information about the implications of their choice: Provide skip option: Users should be able to opt out of providing contact details without penalty. Present this as a legitimate choice rather than a discouraged path. Transparent consequences: Clearly explain what users give up by not providing contact information, focusing on the practical impact on their experience. Avoid manipulation: Present the choice neutrally without using fear or urgency to push users toward providing contact details. Setting proper expectations. Be honest about system limitations to help users make informed decisions: Explain that status tracking has limitations compared to direct notifications. Clarify that early availability won't be communicated through status displays. Help users understand they'll need to actively check back rather than being alerted. Status tracking and return journey Users check progress in their procedure portal because this is where they initiated their overall application or service request. Unlike the intermediary platform (which handles the technical evidence retrieval), the procedure portal maintains the full context of their application and shows how evidence retrieval fits into their broader procedure timeline. Status information should include: Current retrieval status - Shows basic status such as "Retrieving..." or "Processing". Timeline estimates - Shows estimated availability date or time without overpromising. Manual alternative options - Clear cancel button, with extra confirmation before cancelling the request. Users may want to do this if they want to opt to manually upload the evidence, or initiate a new evidence request with different parameters.
Users may receive earlier notifications directly from evidence providers when proof becomes available, separate from the timeline estimates shown in the procedure portal.
When evidence retrieval is delayed, users often need to leave their flow and return to the system later. Due to technical constraints, users cannot be directed straight back to the evidence preview when returning - they must always follow the complete procedure flow (Procedure Portal → Intermediary Platform → Preview Space). Dual notification system Users may receive notifications from two sources if both provider and requester have a way of notifying the user: Provider notifications: Real-time updates when evidence becomes available. These notifications should use the available information and metadata to guide the user as best as possible towards completing the evidence request. Requester notifications: Reminder notifications in case the estimated time for the delayed response has passed. Both notification sources should be acknowledged in user communication to prevent confusion. Return methods External notifications: Basic notifications when evidence becomes available, requiring users to return to their procedure portal. Self-service checking: Status updates in procedure portal showing procedure progress and expected availability dates. Notification content examples Provider notification (real-time, limited context): "Your diploma for your business registration application is now available. Please log into your procedure portal to continue retrieving your evidence." Requester notification (more context, may be delayed): "Update on your evidence request: Your diploma from [issuing authority] is now ready for review. Continue with your business registration application in [procedure portal] to access your evidence."
Here is an example of what such an email might look like coming from the evidence provider. Email template example(opens in a new tab)
Actions to implement: Set up automatic reminders if user hasn't taken action after defined timeframe. Provide clear instructions for returning to procedure since direct links to evidence cannot be provided. Include enough context in notifications to help users identify which evidence request is ready. Preserve session context to minimize re-entry of information when users return through the full flow.UX recommendations
Procedure Portal before authentication
Explain the benefits of the OOTS
Sign in recommendations
Display the European eID login option next to the national eID option
Display the country flag for national option next to the authentication system
Tell users which authentication options allow them to use OOTS
Use the YourEurope logo to build trust
National Authentication Service in the Evidence Requester Member State
Country selection
Link to more information about cross-border authentication
Attributes consent
Usage
Procedure Portal after authentication
Explain the benefits of the OOTS
Requested evidence language
Allow Re-authentication
OOTS Entry point button label
Usage
Determining labels in local languages
Intermediary platform
Explain the service the Intermediary platform offers
Procedure summary
Provide support
Error message (IP)
Types of Errors in Intermediary Platform
Usage
Errors examples and snippet copy
Jurisdiction selection
Usage
Administractive/hierarchical navigation
Example of filterable dropdown menu
National Authentication Service in the Evidence Provider Member State
Preview space
Actionable title
Show redirections
Option A
Recommended
Option B
Available evidence languages
Under investigation
You can detect the accepted language
You cannot detect the requested language
Errors (PS)
Identified Types of errors
Usage
Error scenarios with recommended copy
Intermediary platform after preview
Procedure portal after evidence retrieval
Global recommendations
Error messages
Types of Global Errors
General principles
Clear actions and Platform Guidance
Usage
Evidence Language
Language Requirement Scenarios
When requirements are unknown
Current technical context
Future technical innovation opportunities:
Usage
When requirements are known - Language Available
Preview Space
When requirements are unknown
Language verification after sharing
Process cancellation
Usage
Procedure portal
Intermediary platform
Preview space
During authentication
Wording / naming of the evidence
Determining terminology in member state languages
Usage
Primary terminology
Recommended copy
Trustworthiness of the different portals
Usage
Use visual elements that create trust
Use unified naming across platforms
Use and integrate with your governments design system
When an established government visual identity exists
When use of an established government visual identity is not possible
Consistent display language across portals
Implementation Guidance
For all OOTS platforms:
Two possible scenarios:
Error Handling & Fallbacks
Missing language preference
Unsupported language scenarios
Language switching procedures
Key points during language flow
Technical Implementation
For sending platforms (redirecting users to another platform):
For receiving platforms (accepting users from another platform):
Delayed response
Usage
Technical delays
Evidence unavailable
When evidence request needs processing by the provider
"Would you like to request this proof?"
"If you request this proof, you can continue your application while the issuer prepares it. If you skip this proof, you can still upload it manually later if needed."
How should we notify you?
We'll let you know when your proof is ready. Providing your contact details ensures you won't miss the notification.
For evidence unavailable:
"Your proof is being processed by [issuing authority]. Expected completion: [date/timeframe]"
For technical delays:
"We're working to resolve a technical issue with your proof retrieval. We'll notify you when this is resolved."
What happens if the user doesn't request evidence:
"You can cancel this request and upload your proof directly instead, or start a new retrieval with different details"
Managing user return
Example of the button
Snippet copied to clipboard